This solution requires a different migration target for each replication target filesystem.
It also requires a method of copying the migrated data between the migration targets. As there is more than one copy of the migrated data, this arrangement is suitable for use in a disaster recovery or backup scenario and is appropriate for internally provided cloud targets such as HCP. As there is no risk of deleting the link targets relied upon by the replication target filesystems, there is no requirement to protect the link targets from deletion or reverse migration.
If the replication has been configured in this way then the following CLI command options should be set to true to avoid having to manually remove the non-deleted link targets:
set delete-target-on-unlink-even-if-xvl-as-links true
set delete-target-on-reverse-migration-even-if-xvl-as-links true
These settings apply on the cluster hosting the replication source filesystem, but they can be set on all clusters hosting replication target filesystems in anticipation of one of the replication targets being promoted to read/write at a future date. The default value for these settings is false.
A time window still exists when the replication target and its migration target may be inconsistent, when one or other of the replications (either the NAS object replication or the copy of data between migration targets) has completed and the other has not. Scheduling of the replications should be configured to reduce this window to a minimum and minimize the opportunity for client access during the window.