Attix5 Pro can be configured to support the backup and restoration of Exchange 2010 Database Availability Groups (DAGs).
Some additional configuration steps are required:
- In a DAG, data is replicated between members. Transaction log truncation is dependent on this replication.
If the configuration steps are not followed, the Exchange logs may not truncate when a backup completes.
- Note that only Active databases are backed up. Passive copies are ignored for backup.
- If you have active databases on more than one DAG member, an SE client should be installed on each DAG member where an active database is located.
Note: When installing the Backup Client, you must have administrator privileges. If you don't, the installation will fail with errors.
To back up or restore Exchange 2010 DAGs using Attix5 Pro, you will need:
- SE Backup Client
- System State plug-in
- VSS plug-in
- Install the SE Backup Client and configure System State backup on the appropriate Domain Controller as this will be required in a Disaster Recovery scenario.
- On each Exchange Server, disable the Exchange Replica Writer (VSS writer) and restart the Exchange Replication service as detailed in this article: http://exchangeserverpro.com/event-id-2137-windows-server-backup-completed-warnings-exchange-2010-mailbox-server.
- Using the Registry Editor, go to: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\V14\Replay\Parameters and add a DWORD entry of "EnableVSSWriter" with a value of 0 (zero).
- Using PowerShell, restart the Exchange Replication service as follows: [PS] C:\>Restart-Service MSExchangeRepl
- Install an SE Backup Client and VSS plug-in on each Exchange DAG member.
On each Exchange DAG member, open the SE Backup Client and include the Exchange Writer node for backup.
When backups run, only mounted databases (i.e. the active ones) will be backed up, and the logs transacted. Any healthy (i.e. standby) databases will be ignored. After the logs are transacted, native DAG replication will replicate the transaction to the other members. If a server has no active databases, only the Exchange writer details will be backed up. Typically, this backup would be less than 2 KB in size. If a database is promoted to "mounted" status, it will be included in the selection and added. If a database is demoted to "healthy" status, it will be deselected and removed.
Note: As databases are promoted or demoted, they will be added or removed from the backup selection on each Backup Client. This means that they will be added as full files when promoted, which will impact data transmission.
If the database status does not change, the active databases will patch as normal. The display status within the Backup Client's GUI may not refresh within a timely fashion, although the databases do back up successfully (the status may refresh after the backup runs, with demoted databases disappearing from the writer).
In a DR scenario the Active Directory environment should first be restored and the Exchange databases reinstalled. Thereafter, they should be reconnected to the DAG via Active Directory exactly as with a conventional Exchange restore. Databases can be restored to mounted (i.e. active) copies, rather than to the healthy copies which remain invisible to VSS. It is recommended to restore these to the last active peer from which they backed up.
Note: Restores operate through the normal VSS method, with the normal settings recommendations applying for older database copies and so on.
After restoring, in a non-DR scenario, it may be necessary to force the standby copy to synchronise. If the standby copy database shows as healthy it should first be suspended, and then resumed or updated.
If updating, the database will be replicated in full from the active database, whilst the resume might only be successful if the copy has been deliberately suspended and the database remains in sync.
Note: Updating is effectively reseeding, which Microsoft warns can take several hours, but may be the only successful method.
If the standby "healthy" copy is not fully synchronised the restored mounted database (ie the active one) will not truncate logs on subsequent backups, and may fill up the disk. You are advised to monitor these for a short period after the restore and ensure that synchronisation is operating correctly.