Skip to main content
Sign Out

Welcome to Dell

My Account
  • Place orders quickly and easily
  • View orders and track your shipping status
  • Enjoy members-only rewards and discounts
  • Create and access a list of your products
  • Manage your Dell EMC sites, products, and product-level contacts using Company Administration.
Sign In Create an Account Dell Financial Services Premier Sign In Partner Program Sign In
Contact Us

Your Dell.com Carts

PowerScale OneFS 9.8.0.0 Web Administration Guide

PDF

Fail back data to a primary cluster

After you fail over to a secondary cluster, you can fail back to the primary cluster.

CAUTION:Before you begin, we recommend that you run SyncIQ's resync-prep job as soon as possible before the fail back. The resync-prep job sets the dataset on the primary cluster to read-only, which will prevent any possible writes from occurring. Only run the resync-prep job if the allow-writes are not going to be reverted. Note that if writes have occurred on the primary cluster, then resync-prep will revert those changes. Creating a temporary snapshot is a safeguard to reduce risk of data loss if a failover-failback is performed incorrectly. You must take a snapshot on the SyncIQ source path prior to resync-prep if that data needs to be preserved. This is to prevent situations in which both clusters are in a writable state during fail over, when clients could potentially be writing to both clusters.
Before you can fail back to the primary cluster, you must already have failed over to the secondary cluster. Also, you must ensure that your primary cluster is back online.
NOTE:Data failback is supported for SmartLock compliance and enterprise directories. If clients committed new SmartLock files while the secondary cluster was in operation, these SmartLock files are replicated to the primary cluster during failback.
  1. On the primary cluster, click Data Protection > SyncIQ > Policies.
  2. In the SyncIQ Policies list, for a replication policy, click More > Resync-prep.

    This action causes SyncIQ to create a mirror policy for the replication policy on the primary cluster and secondary cluster. The mirror policy is placed under Data Protection > SyncIQ > Local Targets on the primary cluster. On the secondary cluster, the mirror policy is placed under Data Protection > SyncIQ > Policies.

    SyncIQ names mirror policies according to the following pattern: 
    <replication-policy-name>_mirror
  3. Before beginning the failback process, prevent clients from accessing the secondary cluster.
    This action ensures that SyncIQ fails back the latest data set, including all changes that users made to data on the secondary cluster while the primary cluster was out of service. We recommend that you wait until client activity is low before preventing access to the secondary cluster.
  4. On the secondary cluster, click Data Protection > SyncIQ > Policies.
  5. In the SyncIQ Policies list, for the mirror policy, click More > Start Job.
    Alternatively, you can edit the mirror policy on the secondary cluster, and specify a schedule for the policy to run.
  6. On the primary cluster, click Data Protection > SyncIQ > Local Targets.
  7. On the primary cluster, in the SyncIQ Local Targets list, for the mirror policy, select More > Allow Writes.
  8. On the secondary cluster, click Data Protection > SyncIQ > Policies.
  9. On the secondary cluster, in the SyncIQ Policies list, click More > Resync-prep for the mirror policy.
    This puts the secondary cluster back into read-only mode and ensures that the data sets are consistent on both the primary and secondary clusters.
Redirect clients to begin accessing their data on the primary cluster. Although not required, it is safe to remove a mirror policy after failback has completed successfully.

Rate this content

Accurate
Useful
Easy to understand
Was this article helpful?
0/3000 characters
  Please provide ratings (1-5 stars).
  Please provide ratings (1-5 stars).
  Please provide ratings (1-5 stars).
  Please select whether the article was helpful or not.
  Comments cannot contain these special characters: <>()\