Today Veeam hosted a webinar titled “Running Exchange on VMware”. Most of the focus of course was on backup and recovery of Exchange once it’s been virtualized. As I was preparing for the webinar (with a lot of help from Anton) I realized that the information would also make a good blog post. Below are the main points of backup and recovery for Microsoft Exchange and how Veeam Backup & Replication v5 addresses them.
In order to be compliant with Exchange Server, VSS based backup applications must follow three basic requirements to ensure the integrity and recoverability of shadow copy backups. If these requirements are not followed, Microsoft ... will not be able to troubleshoot backup and restore issues.
Rule 1: Exchange must be backed up exclusively through the Exchange VSS Writer.
Rule 2: Backup should not be relied on until the backup application has completed integrity verification.
Rule 3: Restores to original location must be done exclusively with the Exchange VSS Writer.
Rule 1: VSS Aware Backup
Veeam implements proprietary Microsoft VSS integration, instead of relying on VMware Tools VSS integration components.
Fully automated and transparent (no agents to deploy/configure/update/monitor)
Supported directly by Veeam, not VMware (no finger pointing)
No limitations of VMware Tools VSS: supports transaction logs processing, all ESX(i) and Windows versions, dynamic disks, IDE disks, VM without UUID, etc.
If transaction log files are not pruned after backup, the log files accumulate until they fill all the available disk space. The Exchange VSS Writer implements transaction log pruning capabilities, however VMware Tools VSS is NOT a backup application and cannot know if backup was completed successfully. Thus, it cannot process transaction logs by design.
Any application “riding” on VMware Tools VSS instead of providing proprietary VSS integration will not truncate logs.
Some solutions do provide transaction log pruning, but perform log pruning right after the snapshot is taken.
This approach is actually worse than no pruning at all: if backup does not complete successfully, you will not have a good backup, and your transaction logs will be gone. You will not be able to restore in case of disaster.
To check your current image-level solution, perform test a backup to check (on a test Exchange server, not production)
Perform backup, wait for the job to complete successfully, ensure transaction logs are actually pruned.
Perform another backup, but this time reset the backup server while the job is running (after virtual disk copy starts). Transaction logs should NOT be pruned.
Veeam prunes logs on successful backup by default and v5 provides advanced transaction log handling options as seen in this screen shot:
Granular Recovery Challenges
Typically granular recovery from an image-level backup was difficult, you had to restore entire Active Directory and Exchange servers to an isolated environment before your could restore any items. The process is time and personnel resource intensive. There are some 3rd party tools that mount the Exchange data store but these still require data stores to be extracted first (time and disk space) and there’s an additional licensing cost associated (usually per mailbox)
Agent-based solutions have existed for years that can back up the Exchange data, but that’s not the most efficient way to backup Exchange in a virtual environment. Additionally, if you combine agent based with image based, you are backing up the same data twice, taking additional resources and storage media.
Granular Recovery with vPower™
Veeam’s patent-pending approach fully utilizes the existing virtual infrastructure. The Veeam application group and virtual lab features automatically create an isolated environment and with vPower, you simply run the AD and Exchange servers directly from the backup files, no extraction necessary.
Veeam’s Exchange AIR (Application Item Recovery) Wizard utilizes Microsoft Exchange APIs and connects to both the production and isolated environments providing you with Exchange item-level recovery in minutes, not hours!