As storage administrator who runs a company in today’s world, you know how important a disaster recovery (DR) plan is for your business. Failover and failback operations are crucial to the success of your DR plan, and NetApp® SnapMirror® Synchronous (SM-S) replication technology gives you simple and effective failover and failback.
Fail Over to Your Secondary Site During a Disaster
When disaster strikes, failover is the process of shifting your mission-critical workloads from your primary storage system to your secondary storage system at your DR site. A failover typically quiesces and breaks the SnapMirror relationship, which suspends ongoing data mirroring from your primary to your secondary storage system. It then halts I/O to the primary system and serves enterprise application I/O from your remote storage system. (You can find more details about the failover process in my previous blog post.)
As part of the failover process, the Relationship State of the SnapMirror relationship is Broken Off, as the following screenshot of the NetApp ONTAP® System Manager (formerly OnCommand® System Manager) Volume Relationships dialog box shows in destination cluster.
After you have failed over mission-critical workloads to your DR site, you should evaluate the state of your environment. When ONTAP System Manager indicates that the consequential damage has been remedied at your primary site, you should be ready to resume operations.
Failback to Your Primary Site After a Disaster
This blog post covers the failback procedure in the DR process. Failback is the process of resynchronizing the data back to your primary storage system from your secondary storage system, halting application I/O once again and cutting back over to the original location. All the changes that were made while your system was serving data from your DR site are tracked. Your original storage system at your primary site can be resynchronized and restored to service just by replicating the data back to your primary storage system when the system comes back up.
For easy failback with SM-S, follow these steps:
1. Be sure that SnapMirror Synchronous is licensed on the destination (which has now become the source).
- Note: This step is not necessary for ONTAP 9.6 or later; it’s required only for ONTAP 9.5 storage systems.
2. In ONTAP System Manager on destination cluster in DR site, confirm that for the cluster, Protection > Volume Relationships > Relationship State for the SnapMirror Synchronous relationship shows as Broken Off.
3. Highlight the relationship and select Operations > Reverse Resync. This option resynchronizes your system without the baseline transfer.
4. In the dialog box, select the checkbox for OK to Reverse Resync the Relationship. Then click Reverse Resync.
5. The Reverse Resync operation resynchronizes the changes in stored data from your secondary to your primary storage system. The protection relationship will now appear on source cluster with source and destination volumes interchanged as follows:
6. You need to then configure the volume for data access. NAS clients and SAN hosts can access the data from the reactivated source volume on your primary storage system as follows:
- NAS environment:
- Mount the NAS volume to the namespace by using the same junction path as for the source volume in the source storage virtual machine (SVM).
- Redirect clients back to the source volume.
- Remount the NFS shares on the clients.
- SAN environment:
- Map the logical unit numbers (LUNs) in the volume back to the appropriate initiator group.
- For iSCSI, create iSCSI sessions from the SAN host initiators to the SAN logical interfaces (LIFs).
- On the SAN client, rescan disks to detect the connected LUNs.
- Attach the database files so that you can use them.
Now that you know how easy and effective failover and failback operations are with SnapMirror Synchronous, get started today. To learn more about SnapMirror Synchronous, watch videos from the SnapMirror Synchronous (SM-S) playlist and read our technical report SnapMirror Synchronous for ONTAP 9.6.
You can also read previous blog posts about SnapMirror Synchronous: