Optimize your replication plan in NetApp Disaster Recovery
Suggest changes
PDFs
The replication plan is an essential piece of your disaster recovery strategy, defining snapshot frequency, boot order, network mapping, and other key details of failover and failback. Before creating a replication plan in NetApp Disaster Recovery, ensure you understand how replication plans work and the best practices.
About replication plans
You can protect multiple VMs, datastores, or namespaces with a single replication plan. Disaster Recovery creates ONTAP consistency groups for all ONTAP volumes that host protected data resources.
Resource planning
Organize your VMs or namespaces before assigning resources to a replication plan to minimize sprawl. Place resources that need protection on a subset of datastores and place resources that are not going to be protected on a different subset of datastores. To organize resource groups before creating the replication plan, see Create a resource group.
Test failover
When you create the replication plan, you have the option to configure unique test failover mappings.
If you plan to perform test failovers as part of your replication plan, you should provide a set of test failover mappings to ensure that VMs started during the failover test don't interfere with production VMs. You can accomplish this by either providing test VMs with different IP addresses, or by mapping the virtual NICs of the test VMs to a different network that is isolated from production yet has the same IP configuration (referred to as a bubble or test network).
Snapshots
Disaster Recovery maintains the same number of snapshots on the source and destination clusters. By default, the service performs a snapshot reconciliation process every 24 hours to ensure that the number of snapshots on the source and destination clusters is the same.
The following situations can cause the number of snapshots to differ between the source and destination clusters:
-
Some situations can cause ONTAP operations outside of Disaster Recovery to add or remove snapshots from the volume:
-
If there are missing snapshots on the source site, the corresponding snapshots on the destination site might be deleted, depending on the default SnapMirror policy for the relationship.
-
If there are missing snapshots on the destination site, the service might delete the corresponding snapshots on the source site during the next scheduled snapshot reconciliation process, depending on the default SnapMirror policy for the relationship.
-
-
A reduction of the replication plan's snapshot retention count can cause the service to delete the oldest snapshots on both the source and destination sites to meet the newly reduced retention number.
In these cases, Disaster Recovery removes older snapshots from the source and destination clusters upon the next consistency check. Or, the administrator can perform an immediate snapshot cleanup by selecting the Actions 
icon on the replication plan and selecting Clean up snapshots.
Disaster Recovery performs snapshot symmetry checks every 24 hours.
Platform-managed backups
If you plan to use platform-managed backups (that is, ONTAP-managed snapshots), it's recommended you use the MirrorAll replication policy. Review the table to understand the impact of different SnapMirror replication policies and why MirrorAll is the recommended option.
Policy |
Recommendation |
Notes |
MirrorAll |
Recommended |
Do not use SnapMirror transfer snapshots for failover or failback operations. |
MirrorVault |
Alternative recommendation |
Ensure that the snapshots selected during failover or failback are present on both the source and destination volumes. Failure to do so will result in the error: "Transition to 'snapmirrored' state failed. Reason: No common snapshot found." |
Asynchronous |
||
MirrorLatest |
NOT recommended |
This policy results in the destination having effectively only one common snapshot for failover, which is suboptimal for disaster recovery scenarios. |
Disaster Recovery-managed backups
When using Disaster Recovery managed backups, the following guidelines apply to SnapMirror relationships created outside of NetApp Disaster Recovery:
-
SnapMirror relationships can support the MirrorAll, MirrorVault, MirrorLatest, and Asynchronous replication policies.
-
Do not schedule updates for these relationships as they will be managed by the Disaster Recovery service.
Application-consistent replicas
Many VMs host database servers such as Oracle or Microsoft SQL Server. These database servers require application-consistent snapshots to ensure that the database is in a consistent state when the snapshot is taken.
Application-consistent snapshots ensure that the database is in a consistent state when the snapshot is taken. This is important because it ensures that the database can be restored to a consistent state after a failover or failback operation.
The data managed by the database server might be on the same datastore as the VM that hosts the database server, or it might be on a different datastore. The following table shows the supported configurations for application-consistent snapshots in NetApp Disaster Recovery:
| Data location | Supported | Notes |
|---|---|---|
Within the same vCenter datastore as the VM |
Yes |
Because the database server and database both reside on the same datastore, both the server and the data will be in sync upon failover. |
Within a different vCenter datastore from the VM |
No |
Disaster Recovery can't identify when a database server's data is on a different vCenter datastore. The service can't replicate the data, but can replicate the database server VM. While the database data cannot be replicated, the service ensures that the database server performs all necessary steps to ensure that the database is quiesced at the time of the VM backup. |
Within an external data source |
No |
If the data resides on a guest-mounted LUN or NFS share, Disaster Recovery can't replicate the data, but can replicate the database server VM. While the database data cannot be replicated, the service ensures that the database server performs all necessary steps to ensure that the database is quiesced at the time of the VM backup. |
During a scheduled backup, Disaster Recovery quiesces the database server and then takes a snapshot of the VM hosting the database server. This ensures that the database is in a consistent state when the snapshot is taken.
-
For Windows VMs, the service uses the Microsoft Volume Shadow Copy Service (VSS) to coordinate with either database server type.
-
For Linux VMs, the service uses a set of scripts to place the Oracle server in backup mode.