Understanding snapshot rules
By default, replications automatically create and delete the snapshots they require to complete consistent copies. That being the case, snapshot rules are not usually required. However, there are cases where the snapshots must be taken or used by external software. In these cases, snapshot rules are used so that the external software and the replication can be sure they are using the same snapshot.
Specific instances where snapshot rules may be used include:
- Replications which copy databases or iSCSI LUNs. A snapshot taken automatically at the start of a replication will not capture a consistent image of a database or an iSCSI LUN that is actively in use. In order to capture a consistent image, the database/iSCSI LUN needs to be brought into a quiescent state before the snapshot is taken. These actions are normally be executed by a script, which then takes a snapshot within the snapshot rule so that the replication can identify which snapshot to copy.
The script could be invoked as part of a pre-replication script. Alternatively the script could be independently scheduled. If scheduled independently, however, the schedule must allow the script to complete before the replication starts.
- Linked, two-stage replications, which copy a file system from server A to server B and then copy on from server B to server C. These types of replications can use snapshot rules to synchronize the copies.
The replication from server B to server C may start while a copy from server A to server B is running. If a snapshot was taken at this point, an inconsistent file system state would be captured. One way to avoid this is to use a specific snapshot rule as both the destination snapshot rule of the server A to server B copy and the source snapshot rule of the copy from B to C. Then the B to C copy will always copy a snapshot taken at the end of the last complete copy from A to B.
Two kinds of rules define snapshot use during replication:
- Source Snapshot Rules determine which snapshot to use as the replication source.
For Replication Policies configured to use a source snapshot rule, the most recent snapshot associated with the rule becomes the replication source.
Source snapshot rules are particularly useful when the replication includes a database or other system that must be stopped in order to capture a consistent copy. Based on an external command (perhaps issued by a pre-replication script), the data management engine expects that a snapshot will be taken.
To perform incremental replications, the data management engine requires that the snapshot used during the previous successful replication still exist when a new replication is made. If you are using the snapshot rule queue length to control the deletion of snapshots, you must take this requirement into account and set the queue length long enough to allow for keeping the snapshot used during the previous successful replication. Also, you must take into account the possibility of intermediate failed replications, which may also create snapshots.
The following actions are taken if the required snapshots do not exist:
- If no snapshot exists in the rule, then the data management engine issues a warning message and performs a full replication, using an automatically created snapshot that it deletes immediately after the copy.
- If the snapshot taken during the previous replication has been deleted, the data management engine cannot take an incremental snapshot and therefore performs a full copy.
- Destination Snapshot Rules govern the snapshot taken after a successful replication operation.