You are here: Double-Take Backup requirements > Replication capabilities

Replication capabilities

Double-Take Backup replicates file and directory data stored on any Windows file system (FAT, FAT32, NTFS4, and NTFS5). Replicated items also include Macintosh files, compressed files, NTFS attributes and ACLs (access control list), dynamic volumes, files with alternate data streams, sparse files, and encrypted files. Files can be replicated across mount points, even though mount points are not created on the repository server. Some reparse points are replicated, including CommVault Data Migrator and BridgeHead Software HT FileStore.

Typically, Double-Take Backup does not replicate items that are not stored on the file system, such as physical volume data and registry based data. Nor does it replicate NTFS extended attributes, registry hive files, Windows or any system or driver pagefile, system metadata files ($LogFile, $Mft, $BitMap, $Extend\\$UsnJrnl, $Extend\\$Quota, $Extend\\$ObjId, and $Extend\\$Reparse), hard links, or the Double-Take Backup disk-based queue logs. However, if you are protecting a full-server, Double-Take Backup will automatically gather and replicate all necessary system state data, including files for the operating system and applications.

Note the following replication caveats.

If you have mixed file systems, keep in the mind the following.

If, on your source, you have a FAT volume mounted on a directory which resides on an NTFS volume, these files will not be mirrored, regardless of the target file system. Replication will work correctly. To work around this issue, make sure both volumes are NTFS.
If you are mirroring/replicating from an NTFS source to a FAT target, you may see additional error messages in your Double-Take Backup log file because the target file system cannot handle the NTFS attributes or file permissions. For example, if your protection job contains files with alternate data streams, you will see messages indicating that there are unfinished operations because the FAT file system cannot store the alternate data stream information.
If you select a compressed file or folder from an NTFS partition and replicate it to a FAT target, the attributes are lost, but the data is maintained.

If any directory or file contained in your protection job that specifically denies permission to the system account or the account running the Double-Take service, the attributes of the file on the target will not be updated because of the lack of access. This also includes denying permission to the Everyone group because this group contains the system account.
If you select a dynamic volume and you increase the size of the volume, the target must be able to compensate for an increase in the size of the dynamic volume.
If you select files with alternate data streams, keep in mind the following.

Alternate data streams are not included in the protection job size calculation. Therefore, you may see the mirror process at 100% complete while mirroring continues.
The number of files and directories reported to be mirrored will be incorrect. It will be off by the number of alternate streams contained in the files and directories because the alternate streams are not counted. This is a reporting issue only. The streams will be mirrored correctly.
Use the checksum option when performing a difference mirror or verification to ensure that all alternate data streams are compared correctly.
If your alternate streams are read-only, the times may be flagged as different if you are creating a verification report only. Initiating a remirror with the verification will correct this issue.

If you select encrypted files, keep in mind the following.

Only the data, not the attributes or security/ownership, is replicated. However, the encryption key is included. This means that only the person who created the encrypted file on the source will have access to it on the target.
Only data changes cause replication to occur; changing security/ownership or attributes does not.
Replication will not occur until the Windows Cache Manager has released the file. This may take awhile, but replication will occur when Double-Take Backup can access the file.
When remirroring, the entire file is transmitted every time, regardless of the remirror settings.
Empty encrypted files will be mirrored to the target, but if you copy or create an empty encrypted file within the protection job after mirroring is complete, the empty file will not be created on the target. As data is added to the empty file on the source, it will then be replicated to the target.
When you are replicating encrypted files, a temporary file is created on both the source and target servers. The temporary file is automatically created in the same directory as the Double-Take Backup disk queues. If there is not enough room to create the temporary file, an out of disk space message will be logged. This message may be misleading and indicate that the drive where the encrypted file is located is out of space, when it actually may be the location where the temporary file is trying to be created that is out of disk space.

If you are using mount points, keep in mind the following.

By default, the mount point data will be stored in a directory on the target. You can create a mount point on the target to store the data or maintain the replicated data in a directory. If you use a directory, it must be able to handle the amount of data contained in the mount point.
Recursive mount points are not supported. If you select data stored on a recursive mount point, mirroring will never finish.

Double-Take Backup supports transactional NTFS (TxF) write operations, with the exception of TxF SavePoints (intermediate rollback points).

With transactional NTFS and Double-Take Backup mirroring, data that is in a pending transaction is in what is called a transacted view. If the pending transaction is committed, it is written to disk. If the pending transaction is aborted (rolled back), it is not written to disk.

During a Double-Take Backup mirror, the transacted view of the data on the source is used. This means the data on the target will be the same as the transacted view of the data on the source. If there are pending transactions, Double-Take Backup will indicate this state. As the pending transactions are committed or aborted, Double-Take Backup mirrors any necessary changes to the target. Once all pending transactions are completed, the state will be updated.

If you see the pending transactions state, you can check the Double-Take Backup log file for a list of files with pending transactions. As transactions are committed or aborted, the list is updated until all transactions are complete.

During replication, transactional operations will be processed on the target identically as they are on the source. If a transaction is committed on the source, it will be committed on the target. If a transaction is aborted on the source, it will be aborted on the target.
When recovery occurs any pending transactions on the target will be aborted before the source identity is assigned to the target.

Double-Take Backup supports Windows 2008 symbolic links and junction points. A symbolic link is a link (pointer) to a file. Junction points are also links, but to folders and volumes.

If the link and the file/folder/volume are both in your source protection job, both the link and the file/folder/volume are mirrored and replicated to the target.
If the link is in the source protection job, but the file/folder/volume it points to is not, only the link is mirrored and replicated to the target. The file/folder/volume that the link points to is not mirrored or replicated to the target. A message is logged to the Double-Take Backup log identifying this situation.
If the file/folder/volume is in the source protection job, but the link pointing to it is not, only the file/folder/volume is mirrored and replicated to the target. The link pointing to the file/folder/volume is not mirrored or replicated to the target.

Short file names are not supported on FAT file systems.