Complete the following procedure for each compliance SmartLock directory that you want to recover.
About this task
- On the secondary cluster, click .
- In the
SyncIQ Local Targets table, for the replication policy, enable writes to the target directory of the policy.
- If the last replication job completed successfully and a replication job is not currently running, select Allow Writes.
- If a replication job is currently running, wait until the replication job completes, and then select Allow Writes.
- If the primary cluster became unavailable while a replication job was running, select Break Association. Note that you should only break the association if the primary cluster has been taken offline permanently.
- If you clicked
Break Association, recover any files that are left in an inconsistent state.
- Delete all files that are not committed to a WORM state from the target directory.
- Copy all files from the failover snapshot to the target directory.
Failover snapshots are named according to the following naming pattern:
Snapshots are stored in the /ifs/.snapshot directory.
- If any SmartLock directory configuration settings, such as an autocommit time period, were specified for the source directory of the replication policy, apply those settings to the target directory.
Because autocommit information is not transferred to the target cluster, files that were scheduled to be committed to a WORM state on the original source cluster would not be scheduled to be committed at the same time on the target cluster. To make sure that all files are retained for the appropriate time period, you can commit all files in target SmartLock directories to a WORM state.For example, the following command automatically commits all files in /ifs/data/smartlock to a WORM state after one minute:
isi worm domains modify /ifs/data/smartlock --autocommit-offset 1m
Redirect clients to begin accessing the target cluster.