Filter
Top Products
Dell recommends that you 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 configured.
• Cluster A and Cluster B have the same NAS appliance count. For example, if Cluster A has two NAS
appliances, Cluster B must have two NAS appliances.
• Cluster A and Cluster B are at the same FluidFS version.
• Cluster B has different 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 Replication Partnership Between Source Cluster A And Backup Cluster B
1. Log on to cluster A.
2. Set up replication partnership between source cluster A and backup cluster B.
For more information on setting up replication partners, see Adding a Replication Partnership.
3. Create a replication policy for all the source volumes in cluster A to target volumes in cluster B.
NOTE: Replication policy is 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)
…………………………
Source volume An (cluster A) to target volume Bn (cluster B)
NOTE: FluidFS v2 supports auto generate target volume during addition of the replication
policy. For FluidFS 1.0, you must create the target volumes in cluster B and make sure that the
volume size is big enough to accommodate the corresponding source volume data in cluster A.
4. Start the replication scheduler to ensure that at least one successful replication has occurred for all
the source volumes in cluster A.
If the replication fails, fix the problems encountered and restart the replication process. This ensures
that all source volumes in cluster A have at least one successful replication copy in cluster B. Set up a
regular replication schedule, so the target volumes in cluster B always have most up to date
replication copy for cluster A.
CAUTION: Replication restore is not a complete BMR restore, settings such as network
configuration (client, SAN, and IC) cannot be backed up and restored using the replication
method. Note all cluster A settings (for use when restoring cluster A) including network
configuration, cluster wide settings such as volume 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.
147