This solution requires only one migration target. It is most appropriate to use this solution when the single migration target is an external cloud entity provided by a third-party cloud provider.
At any time, there is only one 'correct' view of the data - the replication source live file system. Migrated and non-migrated data in other locations may be inconsistent with that view. This is because the migrated data is modified immediately, but the non-migrated data is modified only when the replication has taken place. This is of concern when migrated files are deleted or reverse-migrated (either explicitly or as a result of being auto-recalled). When the Transfer XVLs as links during object replication option is not enabled, the deletion or reverse migration of a migrated file would result in the data for that file on the migrated target being deleted.
As the data that has been deleted is now removed from the single migration target, the link to that data from the replication target(s) is now broken. To prevent this, two new CLI command options are available:
set delete-target-on-unlink-even-if-xvl-as-links
set delete-target-on-reverse-migration-even-if-xvl-as-links
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.
When the Transfer XVLs as links during object replication option is enabled for a filesystem and the above options are set to false, a deletion or reverse migration does not cause the migrated data to be deleted (or a retention policy to be set on HCP if configured), and the access to the migrated data at the replication target(s) is not broken.
After protected reverse migration
These settings preserve access to data at replication targets, but the data for reverse migrated or deleted files is preserved forever on the migration target unless the deleted files are manually removed from it.
After protected reverse migration and subsequent replication
As a consequence, with this setting, even when all files have been reverse migrated, the migration path is reported as in use.
If there is a requirement to promptly delete data for storage or regulatory reasons, the options should be set to true, but with the expectation that access to the migrated data from replication targets is imperfect until it is manually cleaned up.
For non-cloud externally migrated data, a list of migrated files for a filesystem can be generated using the Report Migrated Files migration type in the schedule configuration. This can then be compared to the data on the migration target to determine which files can be safely removed. This option does not exist for Data Migrator to Cloud.