SmartLock replication limitations

Be aware of the limitations of replicating and failing back SmartLock directories with SyncIQ.

If the source directory or target directory of a SyncIQ policy is a SmartLock directory, replication and failback might not be allowed. For more information, see the following table:

Source directory type
Target directory type
Replication Allowed
Failback allowed
Non-SmartLock
Non-SmartLock
Yes
Yes
Non-SmartLock
SmartLock enterprise
Yes
Yes, unless files are committed to a WORM state on the target cluster
Non-SmartLock
SmartLock compliance
No
No
SmartLock enterprise
Non-SmartLock
Yes; however, retention dates and commit status of files will be lost.
Yes; however the files will not have WORM status
SmartLock enterprise
SmartLock enterprise
Yes
Yes; any newly committed WORM files will be included
SmartLock enterprise
SmartLock compliance
No
No
SmartLock compliance
Non-SmartLock
No
No
SmartLock compliance
SmartLock enterprise
No
No
SmartLock compliance
SmartLock compliance
Yes
Yes; any newly committed WORM files will be included

If you are replicating a SmartLock directory to another SmartLock directory, you must create the target SmartLock directory prior to running the replication policy. Although OneFS will create a target directory automatically if a target directory does not already exist, OneFS will not create a target SmartLock directory automatically. If you attempt to replicate an enterprise directory before the target directory has been created, OneFS will create a non-SmartLock target directory and the replication job will succeed. If you replicate a compliance directory before the target directory has been created, the replication job will fail.

If you replicate SmartLock directories to another Isilon cluster with SyncIQ, the WORM state of files is replicated. However, SmartLock directory configuration settings are not transferred to the target directory.

For example, if you replicate a directory that contains a committed file that is set to expire on March 4th, the file is still set to expire on March 4th on the target cluster. However, if the directory on the source cluster is set to prevent files from being committed for more than a year, the target directory is not automatically set to the same restriction.