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.
From the Microsoft perspective, there are 3 core rules to backup and recovery of Exchange servers:
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.
Rule 2: Verify Before You Rely
SureBackup Recovery Verification
- Great flexibility (supports custom scripts)
- Choose method of verification that is sufficient for you: remote run eseutil or isinteg on test VM (no stress on production), log on to test mailbox via HTTPS and query test email message
Keep in mind DC dependency!
- Exchange must see DC to be able to properly boot in the isolated environment. SureBackup Application Groups take care of this for you.
Rule 3: VSS Aware Restore
Restores to original location must be done exclusively with the Exchange VSS Writer, and in correct sequence:
- Boot up Exchange VM with mailbox stores dismounted
- Tell Exchange VSS Writer to perform restore from VSS snapshot
- Mount mailbox stores
Veeam implements these Microsoft requirements
- Most image-level backup vendors do not do this, they just boot VM normally like there is no Exchange present
- Perform a test restore to check your current solution and look for these events on the restored Exchange server, if they don’t exist your vendor is not following Rule 3:
| Event Type: Information | Event Type: Information |
| Event Source: MSExchangeIS | Event Source: MSExchangeIS |
| Event Category: Exchange VSS Writer | Event Category: Exchange VSS Writer |
| Event ID: 9620 | Event ID: 9618 |
| User: N/A | User: N/A |
| Computer: ServerName.contoso.com | Computer: ServerName.contoso.com |
| General: Exchange VSS Writer (instance GUID) has processed pre-restore events successfully. | General: Exchange VSS Writer (instance GUID) has processed post-restore events successfully. |
Transaction Logs
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!
See also
Microsoft 365 Security & Compliance Guide | Veeam