Recovering from a disaster

About recovering from a disaster

There are several types of disasters you might encounter:

Failure of the cluster interconnect between the two sites
Failure of access to the partner's storage
Complete loss of communication between the two sites

In any of these situations, you should immediately restrict access to the disaster site's node to prevent possible data corruption by the filer at the site recovering automatically by reestablishing contact with its partner. See the Data Protection Guide for detailed information about these types of disasters.

Recovering from a disaster

To recover from a disaster, complete the following steps.

Note
These procedures work for mirrored clusters and MetroClusters, as described in Chapter 7, Cabling a MetroCluster.

Step	Action
1	Isolate the partner node (filer at disaster site) by powering it off. If you cannot physically turn off that filer, isolate it by manually fencing it, as describe in the Data Protection Guide or the Data ONTAP 6.2 Release Notes.
2	Determine accessibility to the partner node and disks, as described in the Data Protection Guide or the Data ONTAP 6.2 Release Notes.
3	If...	Then...
	The local and partner nodes can access their local data, but cannot access or communicate with each other or their remote storage	Restore access by replacing or reconnecting the damaged or missing cables. Note Do not force a takeover of the partner. Confirm access to the remote storage by entering the following command: `sysconfig -v` Confirm connection between the local and partner node, by entering the following command: `cf monitor`
	The remote node and storage are physically damaged or failed	Force the takeover of the partner node by entering the following command: `cf forcetakeover -d` Complete the disaster recovery procedures, as described in the Data Protection Guide or the Data ONTAP 6.2 Release Notes.