Administrator Guide

Maintain a table to track which DNS entries are used to access each NAS volume. This helps when performing failover and setting up
group policies.
Setting Up and Performing Disaster Recovery
This section contains a high-level overview of setting up and performing disaster recovery. In these instructions, Cluster A is the source
FluidFS cluster containing the data that must be backed up and Cluster B is the target FluidFS cluster, which backs up the data from
source cluster A.
Prerequisites
Cluster B is installed, but has no NAS volumes congured.
Cluster A and Cluster B are at the same FluidFS version.
Cluster B has dierent network settings (client, SAN, internal, and so on) than source Cluster A, however, Cluster A and Cluster B must
be able to communicate with each other so that replication operations can occur.
Cluster B has enough space to replicate all data from Cluster A.
Phase 1 — Build up the replication partnership between Cluster A and Cluster B
Set up replication between Cluster A and Cluster B.
1 From Cluster A, set up a replication partnership between Cluster A and Cluster B.
2 Create a regular replication schedule so that the target volumes in Cluster B always have an up-to-date replication copy for Cluster A.
The replication policy must be a one-to-one match on a volume basis, for example:
Source volume A1 (Cluster A) to target volume B1 (Cluster B)
Source volume A2 (Cluster A) to target volume B2 (Cluster B)
NOTE
: If NFS exports are used, the NAS volume names of the source and target should be the same, as the export path
name includes the NAS volume name. This is not relevant for SMB shares.
Source volume An (Cluster A) to target volume Bn (Cluster B)
3 Ensure that at least one successful replication has occurred for all the source volumes in Cluster A.
If the replication fails, x the problems encountered and restart the replication process.
4 Record all Cluster A settings for future use. Replication restore is not a complete BMR (bare metal restore). Settings such as network
conguration (client, SAN, and internal) cannot be backed up and restored using the replication method. Note all Cluster A settings
(for use when restoring Cluster A) including network conguration, cluster wide settings such as cluster name, alert settings, and so
on for future use. If the system restore operation fails to restore these settings, you can manually restore the Cluster A settings back
to their original values.
Phase 2 — Cluster A fails and clients request failover to target Cluster B
If Cluster A stops responding because of an unexpected failure, fail over to Cluster B.
1 From Cluster B, promote the target volumes in Cluster B. This transforms the original target volumes (B1, B2, .. Bn) to standalone NAS
volumes and makes them writable.
2 Delete the replication policies for the original source volumes (A1, A2, .., An).
3 Apply the source volume conguration from the original source volumes in Cluster A to the target volumes in Cluster B.
4 Restore the users and groups conguration from Cluster A. This restores the Cluster B users and groups to Cluster A settings.
5 Ensure that Cluster B is used to temporarily serve client requests during the failover time.
a Choose one of the following options:
IP address-based failovers: Change the IP addresses for Cluster B to match the IP addresses used by Cluster A. Existing
client connections might break and might need to be re-established.
DNS-based failovers: Point the DNS names from your DNS server to Cluster B instead of Cluster A.
470
FluidFS Administration