Understanding SnapManager backups with SnapMirror updates

SnapMirror can be used to replicate SnapManager backups of your SQL Server database to mirrored volumes on a remote storage system. This is described in the following topics:

What SnapMirror does

SnapMirror creates replicas of storage system volumes that host LUNs. SnapMirror can asynchronously mirror a Snapshot copy of data on a source volume to one or more volumes configured as destinations of the source volume. The data stored in a mirror on a destination volume can be accessed through SnapDrive.

Note
Because a mirror is volume wide, it includes Snapshot copies of any other data sets contained on the source volume.

SnapMirror updates the destination volume(s) to reflect incremental changes on the source volume. As a result, a destination volume is an online, read-only copy of the source volume at the time of the most recent replication. This data can be used for disaster recovery, offloading tape backup, read-only data distribution, testing on nonproduction storage systems, or online data migration.

A SnapMirror destination volume can reside on the same storage system as the source volume or a different storage system. For disaster recovery purposes, the destination volume generally resides on a different storage system that is also geographically remote from the storage system containing the source volume. For other purposes, the source and destination volumes might exist on the same storage system.

How SnapManager uses SnapMirror

SnapManager backs up your SQL Server data by creating Snapshot copies of the databases and transaction logs. SnapMirror can be used to replicate the volumes that host the Snapshot copies to mirrored volumes on a remote storage system.

SnapMirror replication for SnapManager is volume replication

When you use SnapMirror to replicate SnapManager backups, you can replicate only volumes, not qtrees. SnapManager does not support SnapMirror qtree replication.

Backup Snapshot can trigger SnapMirror updates

SnapManager Backup uses Snapshot copy functionality to back up your SQL Server data to a storage system volume managed by SnapDrive. If the volume has been configured as a SnapMirror source volume with one or more appropriately configured destination volumes, then--upon successful completion of a Snapshot copy backup operation--SnapManager can send a request to SnapDrive to initiate a SnapMirror update of each destination volume.

All three types of SnapManager Backup operations can be configured to trigger SnapMirror updates:

Full database backup, with or without transaction log backup or database verification
Transaction log backup only
Database verification only
Note
The result of the database verification operation (the database integrity status) is written to the backup set, in the SnapInfo directory. By replicating the backup set to the mirrored volume, this status information is kept current on the mirrored volume.

SnapMirror replication for SnapManager is asynchronous

When it is configured directly on the storage system, SnapMirror can be used to perform synchronous replication or asynchronous replication.

When you use SnapMirror to replicate SnapManager backups, however, the replication is performed asynchronously. That is, changes made to the databases between SnapManager backups are not replicated in the SnapMirror destination volume. Therefore, any restore from the destination volume would restore the databases to their state at the time of the last SnapManager backup; subsequent changes to the database that occurred on the source volume after the most recent SnapMirror replication update will not be available if a catastrophic failure occurs before the next update of the SnapMirror destination volume.

A subsequent section, Minimizing your exposure to loss of data, discusses ways to minimize this exposure to data loss.

SnapMirror scheduling

When it is configured directly on the storage system, SnapMirror uses its own replication schedule as configured by a Data ONTAP administrator.

When SnapMirror is used by SnapManager, however, the SnapMirror replication schedule must be disabled on the storage system; SnapMirror updates are instead initiated by SnapDrive upon the completion of a SnapManager backup operation.

A subsequent section, Scheduling SnapManager backups with SnapMirror replication, describes how to do this plus other steps in the process.

Process overview

If your SQL Server databases reside on a storage system volume that is configured as a SnapMirror source volume, then the SnapMirror destination volume is optionally updated after the SnapManager backup operation finishes.

The following sequence provides an overview of how SnapMirror destination replication works:

A SnapManager backup is initiated.
SnapManager completes all Snapshot copies required for the backup, then requests a SnapMirror volume update through SnapDrive.
If any volume whose data is captured in the backup is a SnapMirror source volume, SnapDrive requests information about all SnapMirror destination volumes of that source volume.
SnapDrive sends a SnapMirror destination update request to all the related destination volumes.
SnapMirror updates the destination volumes to reflect incremental changes to the source volume.

In SnapManager 1.0 for Microsoft SQL Server, a SnapMirror update is initiated for each Snapshot copy as it was taken, resulting in redundant mirror updates. With SnapManager 1.5, SnapManager 2.0 for Microsoft SQL Server, and SnapManager 2.1 for Microsoft SQL Server, the SnapMirror update is delayed until SnapManager explicitly requests it of SnapDrive, after the SnapManager backup is complete.