If Exchange data backed up by SnapManager resides in a volume that is configured as a SnapMirror source volume with one or more appropriately configured destination volumes, a SnapManager backup of an Exchange database stored on that volume causes SnapDrive to request a SnapMirror update for that volume. The schedule you define for backups sets the schedule for mirror replication.
When you use SnapMirror to replicate SnapManager backups, SnapMirror replication is asynchronous. This means that changes made between SnapManager backups are not reflected in the SnapMirror target volume, and any restore from the target volume would restore the databases to their state at the time of the last SnapManager backup. However, you can use SnapDrive to minimize the time between SnapMirror replications.
For more information about scheduling your SnapMirror replications, see Scheduling SnapMirror replication for SnapManager backups.
When you use SnapMirror to replicate SnapManager backups, you can replicate only volumes, not qtrees. SnapMirror qtree replication is not supported by SnapManager.
In previous releases of SnapManager for Microsoft Exchange, the SnapMirror mirror update was always initiated for each Snapshot copy as it was taken. This approach resulted in redundant mirror updates. With SnapManager 3.0 for Microsoft Exchange and later, the mirror update request is delayed until SnapManager explicitly requests it, after the SnapManager backup is complete.
Note
If you do not want the SnapMirror destination volume to be updated after a backup is taken, you can override the update using the Backup Wizard or the Backup tab.
The following table provides an overview of how SnapMirror destination replication works.
Copyright © 1994-2006, Network Appliance, Inc. All rights
reserved.
Part No. 215-01873_A0
File: mirror4.htm
Last updated: 28-Mar-2006 11:31:04