Open topic with navigation

Replication sets

A replication set defines the data on a source machine that Double-Take Availability protects. Replication sets are defined by volumes, directories, files, or wild card combinations. Creating multiple replication sets allows you to customize sets of data that need to be protected. When working with data workloads, you need to define the replication set data yourself. If you are protecting full-server, application, virtual, or cluster workloads, the replication set is automatically defined for you.

When a replication set is created, a series of rules are defined that identify the volumes, directories, files, and/or wild card combinations that will be replicated to the target. Each rule includes:

• Path—The path including volume, drive, directory, file, and/or wild card
• Include—If the specified path is to be included in the files sent to the target
• Exclude—If the specified path is not to be included in the files sent to the target
• Recursive—If the rule should automatically be applied to the subdirectories of the specified path

For example, a replication set rule might be volume\directory\* inc, rec

This specifies that all files contained in the volume\directory path are included in the replication set. Because recursion is set, all files and subdirectories under volume\directory are also included. A complete replication set becomes a list of replication set rules.

Replication sets offer flexibility tailoring Double-Take Availability to your environment. For example, multiple replication sets can be created and saved for a source to define a unique network configuration. There may be three replication sets - Critical Data, User Data, and Offsite Data. Critical Data could be configured to replicate, in real-time, to an onsite high-availability server. Offsite Data is replicated across a WAN and, therefore, is configured to queue changes until a sufficient amount of data is changed to justify transmission. At that point, the connection is made and stays active until all the data is transmitted. User Data is not replicated throughout the day, but a nightly changed file mirror copies only blocks of data that are different between the source and target server prior to a nightly tape backup operation being run on the target server. Each of these replication sets can be automated to transmit as needed, thus protecting your entire environment.

• Creating a replication set
• Creating or modifying replication rules manually
• Modifying a replication set
• Renaming and copying a replication set
• Calculating replication set size
• Deleting a replication set

Keep in mind the following notes when creating and working with replication sets and connections.

• Limitations
• Replication set rules are limited in length meaning that the entire volume\directory\filename including slashes, spaces, periods, extensions, cannot exceed 259 characters.
• Double-Take Availability can mirror, replicate, verify, and restore paths up to 32760 characters, although each individual component (file or directory name) is limited to 259 characters. Paths longer than 32760 characters will be skipped and logged.
• Do not name replication sets or select a target location using illegal characters. Illegal characters include the following.
• period .
• question mark ?
• forward or backward angle bracket < >
• colon :
• quotation mark "
• forward or backward slash \ /
• asterisk *
• pipe or vertical bar |
• Error checking and avoidance
• Do not connect more than one replication set to the same location on a target. You could overwrite or corrupt your data.
• Replication sets contain error checking to avoid inadvertent overwrites of the replication set rules. When replication sets are modified, a generation number is associated with the modifications. The generation number is incremented anytime the modifications are saved, but the save is not allowed if there is a mismatch between the generation number on the source and the Replication Console. You will be notified that the replication set could not be saved. This error checking safeguards the replication set data in the event that more than one client machine is accessing the source’s replication sets.
• Double-Take Availability will not replicate the same data from two different replication sets on your source. The data will only be replicated from one of the replication sets. If you need to replicate the same data more than once, connect the same replication set to multiple targets.
• If you rename the root folder of a connected replication set, Double-Take Availability interprets this operation as a move from inside the replication set to outside the replication set. Therefore, since all of the files under that directory have been moved outside the replication set and are no longer a part of the replication set, those files will be deleted from the target copy of the replication set. This, in essence, will delete all of your replicated data from the target. If you have to rename the root directory of your replication set, make sure that the replication set is not connected.
• When creating replication sets, keep in mind that when recursive rules have the same type (include or exclude) and have the same root path, the top level recursive rule will take precedence over lower level non-recursive rules. For example, if you have /data included recursively and /data/old included nonrecursively, the top level rule, /data/, will take precedence and the rule /data/old will be discarded. If the rules are different types (for example, /data is included and /data/old is excluded), both rules will be applied as specified.
• Including and excluding files 
• Do not exclude Microsoft Office temporary files from your replication set. When a user opens a Microsoft Office file, a temporary copy of the file is opened. When the user closes the file, the temporary file is renamed to the original file and the original file is deleted. Double-Take Availability needs to replicate both the rename and the delete. If you have excluded the temporary files from your replication set, the rename operation will not be replicated, but the delete operation will be replicated. Therefore, you will have missing files on your target.
• When Microsoft SQL Server databases are being replicated, you should always include the tempdb files, unless you can determine that they are not being used by any application. Some applications, such as PeopleSoft and BizTalk, write data to the tempdb file. You can, most likely, exclude temporary databases for other database applications, but you should consult the product documentation or other support resources before doing so.
• Some applications create temporary files that are used to store information that may not be necessary to replicate. If user profiles and home directories are stored on a server and replicated, this could result in a significant amount of unnecessary data replication on large file servers. Additionally, the \Local Settings\Temporary Internet Files directory can easily reach a few thousand files and dozens of megabytes. When this is multiplied by a hundred users it can quickly add up to several gigabytes of data that do not need to be replicated.
• Creating replication sets that only contain one file may cause unexpected results. If you need to replicate just one file, add a second file to the replication set to ensure the data is replicated to the correct location. (The second file can be a zero byte file if desired.)
• Backups
• Double-Take Availability does not replicate the last access time if it is the only thing that has changed. Therefore, if you are performing incremental or differential backups on your target machine, you need to make sure that your backup software is using an appropriate flag to identify what files have been updated since the last backup. You may want to use the last modified date on the file rather than the date of the last backup.
• Virus protection
• Virus protection software on the target should not scan replicated data. If the data is protected on the source, operations that clean, delete, or quarantine infected files will be replicated to the target by Double-Take Availability. If the replicated data on the target must be scanned for viruses, configure the virus protection software on both the source and target to delete or quarantine infected files to a different directory that is not in the replication set. If the virus software denies access to the file because it is infected, Double-Take Availability will continually attempt to commit operations to that file until it is successful, and will not commit any other data until it can write to that file.

Related Topics