Veeam Exchange issues forced to use backupexec need advice

[ZacTech]

I know this topic has been discussed extensively but I am curious if Veeam has put any pressure on VMware to fix the dropped packets problem. Essentially I cannot use Veeam during business hours due to the VMware issue of dropping packets during the snapshot process. I have tried everything possible and regardless of setup, iscsi or Das, switch types, etc it still happens. VMware actually drops packets on the virtual NIC of the virtual machine. I am forced to incorporate backup exec with it. My strategy is to have a Veeam backup occur, then a Backupexec FULL immediately after, so I can have it do transaction log based backups throughout the day.
My main question: Should I configure Veeam so it DOES not truncate logs? If did that, should I then be able to do a weekly full +daily differential + transaction logs in BackupExec? My thinking is if let Veeam clear the logs I have to do a Full BackupExec job immediately after vs a differential.


Thanks

[tsightler]

So just so I understand, the reason you are using BE is just so you can backup transaction logs more than once per day? Why not just use a script to copy the transaction logs at your preferred intervals to another location? Is it because of space? Just trying to understand the issue.

[ZacTech]

Maybe I am using the wrong terminology. What I want is the ability to restore exchange to nearly any point in time, within 30 mins. When I configure veeam to backup every 30 mins, it backups fast and test restores are great, but users have outlook issues all day because of it. So prior to even having Veeam we used BackupExec with this strategy: Weekly Full, nighly differential, and "transaction" backups every 30 mins during business hours. I could then restore to those points in time. Are you indicating I could do a nightly veeam, and then copy my transaction logs from the exchange server to my backup server every 30 mins? What would be the restore process? (I am a Small/Med shop so I know a little about ALOT, so I am far from an exchange expert).

[tsightler]

Honestly, I haven't manually replayed Exchange logs in quite a while (probably since Exchange 2003 days), but I'm pretty sure it's still possible with eseutil. I think you'd just restore the latest Veeam backup, startup in "safe mode", run eseutil /R to against the database to apply the logs from wherever they currently exist, and then reboot. I'll admit not quite as easy as having a GUI based backup with restore option, but I don't think it's super difficult either, at least if you only have a few mailbox databases. Let me run a few tests in my lab with some backups and I'll get back to you.

The reality is, until VMware changes their snapshot technology (there's multiple things they could do here, integrate with SAN hardware, redesign snapshots into the VMFS filesyste, or the virtual block layer, etc), it will always require a small stun to commit the snapshot. This should only take a few seconds, but Outlook is quite sensitive. One other option is to create a passive Exchange DAG node and simply back that up instead of the active node. Then it won't interfere with the active clients.

[ZacTech]

Thanks for your fast responses. I will do anything to avoid backupexec (2012 version made me look at veeam, shudder). Both options sounds great, and the cost of backupexec vs another exchange license is great for me to get approval.

[ZacTech]

Trying to research how I could use the transaction log method, but it appears there may be an issue with figuring out which logs to replay. I may be confused from all the articles I have read. Does anyone else use this method? Can anyone share their methods for Exchange?

[tsightler]

For the simplest recovery using transaction logs all you really have to do is the following:

1. Restore the VM from the most recent backup
2. Power on VM and boot into "Safe Mode", then disable the "Microsoft Exchange Information Store" service
3. Reboot the server into "normal" mode.
4. Copy/Restore any log files from their backup location back to the server
5. Re-enable the "Microsoft Exchange Information Store" service and start it

When the "Microsoft Exchange Information Store" service starts it will look in the log directory for any transaction logs that are required to bring the database consistent and automatically apply the logs required.

It's generally quite easy to identify the logs you need to copy simply by looking at the filename and modified date. If your full backup was created at 10PM, and you want the database to be recovered with logs until 10AM, you'll need to copy all logs between those dates back before starting the Information Store service. You can use Event viewer to see the log replay events when the service starts. You will see an entry for each log that is replayed.

It really is that simple. You can easily test this in your own environment with vLabs. If you setup a vLab you can restore your Exchange environment into the lab and practice with some log restores from your live environment. I just did all of this in my lab and it worked great. I'll try to do a video and post a link.