Open topic with navigation

Replication capabilities

Double-Take Availability replicates all file and directory data in the supported Linux file systems. Double-Take Availability does not replicate items that are not stored on the file system, such as pseudo-file systems like /proc and /sys. In addition, note the following.

• Data that will be replicated must reside on a Double-Take Availability partition, which is specially mounted with the Double-Take Availability file system (DTFS) driver. DTFS is a virtual file system that monitors the storage file system so that data changes can be captured. DTFS is a transparent file system. Existing mount points may be available for replication, but the data on those mount points can only be replicated if they are DTFS mount points. The DTSetup utility allows you to specify which mount points should be DTFS mount points.
• DTFS mount points are identified in the Replication Console by dtfs in the mount point name.
• Double-Take Availability is compatible with NFS and Samba services as long as they are mounted on top of Double-Take Availability. Double-Take Availability should be mounted just above the storage file system. Additionally, NFS and Samba should be started after the Double-Take daemon.
• Do not select the root as a replication mount point.
• If you have a single drive system, mount DTFS to any of the subdirectories directly under root that you want to replicate.
• If you select data stored on a recursive mount point for replication, a mirror will never finish. Double-Take Availability does not check for data stored on recursive mount points.
• If any directory or file contained in your replication set specifically denies permission to the account running the Double-Take daemon, the attributes of the file on the target will not be updated because of the lack of access.
• If you are using soft links, keep in mind the following.
• If a soft link to a directory is part of a replication set rule’s path above the entry point to the replication set data, that link will be created on the target as a regular directory if it must be created as part of the target path.
• If a soft link exists in a replication set (or is moved into a replication set) and points to a file or directory inside the replication set, Double-Take Availability will remap the path contained in that link based on the Double-Take Availability target path when the option RemapLink is set to the default value (1). If RemapLink is set to zero (0), the path contained in the link will retain its original mapping.
• If a soft link exists in a replication set (or is moved into a replication set) and points to a file or directory outside the replication set, the path contained in that link will retain its original mapping and is not affected by the RemapLink option.
• If a soft link is moved out of or deleted from a replication set on the source, that link will be deleted from the target.
• If a soft link to a file is copied into a replication set on the source and the operating system copies the file that the link pointed to rather than the link itself, then Double-Take Availability replicates the file copied by the operating system to the target. If the operating system does not follow the link, only the link is copied.
• If a soft link to a directory is copied into a replication set on the source and the operating system copies the directory and all of its contents that the link pointed to rather than the link itself, then Double-Take Availability replicates the directory and its contents copied by the operating system to the target. If the operating system does not follow the link, only the link is copied.
• If any operating system commands, such as chmod or chown, is directed at a soft link on the source and the operating system redirects the action to the file or directory which the link references, then if the file or directory referenced by the link is in a replication set, the operation will be replicated for that file to the target.
• The operating system redirects all writes to soft links to the file referenced by the link. Therefore, if the file referenced by the symbolic link is in a replication set, the write operation will be replicated to the target.
• If you are using hard links, keep in mind the following.
• If a hard link exists (or is created) only inside the replication set on the source, having no locations outside the replication set, the linked file will be mirrored to the target for all locations and those locations will be linked if all link locations on the target exist on the same partition.
• If a hard link crosses the boundaries of a replication set on the source, having locations both inside and outside the replication set, the linked file will be mirrored to the target for only those locations inside the replication set on the source, and those locations will be linked on the target if all link locations exist on the same partition.
• If a hard link is created on the source linking a file outside the replication set to a location inside the replication set, the linked file will be created on the target in the location defined by the link inside the replication set and will be linked to any other locations for that file which exist inside the replication set.
• If any hard link location is moved from outside the replication set into the replication set on the source, the link will not be replicated to the target even if other link locations already exist inside the replication set, but the linked file will be created on the target in the location defined by the link.
• If any hard link location existing inside the replication set is moved within the replication set on the source, the move will be replicated to the target and the link will be maintained if the new link location does not cross partitions in the target path.
• If any hard link location existing inside the replication set is moved out of the replication set, that file or linked location will be deleted on the target.
• If a hard linked file is copied from any location inside or outside the replication set to a location inside the replication set on the source, the copy will be replicated to the target.
• If a hard linked file has a location in the replication set and any of the operating system commands, such as chmod or chown, are directed at that file from a location inside the replication set, the modification to the file will be replicated to the target. Operations on hard links outside of the replication set are not replicated.
• If a hard linked file has a location in the replication set and a write operation is directed at that file from inside the replication set, the write operation will be replicated to the target. Operations on hard links outside of the replication set are not replicated.
• If any hard link location existing inside the replication set is deleted on the source, that file or linked location will be deleted from the target.
• If a hard link location is created on the same volume but outside of the path where DTFS is mounted, the hard link operation will fail because the operating system regards the DTFS mount as a separate volume.

• If you are using nested mount points, keep in mind that DTFS does not traverse mount point boundaries, so DTFS must be mounted to each volume in the hierarchy in the proper order. You must manage the sequence of the combined native and DTFS mount operations either manually or by modifying /etc/fstab to mount the file systems in the correct order. For example, the following entries in /etc/fstab ensure the native volumes and their respective DTFS mounts will occur in the proper sequence for this configuration.

  /dev/sda1	/level1	ext3	noatime	0	0
  dtfs	/level1	dtfs	norepatime	0	0
  /dev/sda2	/level1/level2	ext3	noatime	0	0
  dtfs	/level1/level2	dtfs	norepatime	0	0
  /dev/sda3	/level1/level2/level3	ext3	noatime	0	0
  dtfs	/level1/level2/level3	dtfs	norepatime	0	0

  If you want to make sure all DTFS mount points are accounted for, view the list from the start and stop daemon menu in DTSetup or by doing a cat of /etc/DT/dtfs_mounts.

  When managing these mount points manually, the lower or subordinate native mount points must not be mounted until DTFS is mounted for the parent mount. Using the same example and starting with all native volumes mounted, the following steps would be required.

  1. umount /level1/level2/level3
  2. umount /level1/level2/
  3. mount dtfs –t dtfs –o norepatime /level1
  4. mount /dev/sda2 –t ext3 –o noatime /level1/level2
  5. mount dtfs –t dtfs –o norepatime /level1/level2
  6. mount /dev/sda3 –t ext3 –o noatime /level1/level2/level3
  7. mount dtfs –t dtfs –o norepatime /level1/level2/level3

Related Topics