SyncIQ provides two types of replications policies: synchronization and copy. Data replicated with a synchronization policy is maintained on the target cluster precisely as it is on the source – files deleted on the source are deleted next time the policy runs. A copy policy produces essentially an archived version of the data – files deleted on the source cluster will not be deleted from the target cluster. However, there are some specific behaviors in certain cases, explained below.

If a directory is deleted and replaced by an identically named directory, SyncIQ recognizes the re-created directory as a “new” directory, and the “old” directory and its contents will be removed.

Example: If an administrator deletes “/ifs/old/dir” and all of its contents on the source with a copy policy, “/ifs/old/dir” still exists on the target. Then, a new directory is created, named “/ifs/old/dir” in its place, the old “dir” and its contents on the target will be removed, and only the new directory’s contents will be replicated.

SyncIQ keeps track of file moves and maintains hard link relationships at the target level. SyncIQ also removes links during repeated replication operations if it points to the file or directory in the current replication pass.

Example: If a single linked file is moved within the replication set, SyncIQ removes the old link and adds a new link. Assume the following:

• The SyncIQ policy root directory is set to /ifs/data/cluster1.
• /ifs/data/cluster1/user1/foo is hard linked to /ifs/data/cluster1/user2/bar.
• /ifs/data/cluster1/user2/bar is moved to /ifs/data/cluster1/user3/bar.
• With copy replication, on the target cluster, /ifs/data/cluster1/user1/foo will remain, and ifs/data/cluster1/user2/bar will be moved to /ifs/data/cluster1/user3/bar.

If a single hard link to a multiply linked file is removed, SyncIQ removes the destination link.

Note: See Hard links and SyncIQ to understand how SyncIQ interacts with hard links.

Example: Using the example above, if /ifs/data/cluster1/user2/bar is deleted from the source, copy replication also removes /ifs/data/cluster1/user2/bar from the target.

If the last remaining link to a file is removed on the source, SyncIQ does not remove the file on the target unless another source file or directory with the same filename is created in the same directory (or unless a deleted ancestor is replaced with a conflicting file or directory name).

Example: Continuing with the same example, assume that /ifs/data/cluster1/user2/bar has been removed, which makes /ifs/data/cluster1/user1/foo the last remaining link. If /ifs/data/cluster1/user1/foo is deleted on the source cluster, with a copy replication, SyncIQ does not delete /ifs/data/cluster1/user1/foo from the target cluster unless a new file or directory was created on the source cluster that was named /ifs/data/cluster1/user1/foo. After SyncIQ creates the new file or directory with this name, the old file on the target cluster is removed and re-created upon copy replication.

If a file or directory is renamed or moved on the source cluster and still falls within the SyncIQ policy's root path when copied, SyncIQ will rename that file on the target; it does not delete and re-create the file. However, if the file is moved outside of the SyncIQ policy root path, then with copy replication, SyncIQ will leave that file on the target but will no longer associate it with the file on the source. If that file is moved back to the original source location or even to another directory within the SyncIQ policy root path, with copy replication, SyncIQ creates a new file on the target since it no longer associates it with the original target file.

Example: Consider a copy policy rooted at /ifs/data/cluster1/user. If /ifs/data/cluster1/user1/foo is moved to /ifs/data/cluster1/user2/foo, SyncIQ simply renames the file on the target on the next replication. However, if /ifs/data/cluster1/user1/foo is moved to /ifs/data/cluster1/home/foo, which is outside the SyncIQ policy root path, with copy replication, SyncIQ does not delete /ifs/data/cluster1/user1/foo on the target, but it does disassociate, or orphan it, from the source file, that now resides at /ifs/data/cluster1/home/foo. If, on the source cluster, the file is moved back to /ifs/data/cluster1/user1/foo, an incremental copy writes that entire file to the target cluster because the association with the original file has been broken.