Open topic with navigation

Creating a files and folders job

Use these instructions to create a files and folders job.

Note the following information concerning cluster scenarios.

• For cluster to standalone jobs, the source cluster name and the standalone target must be added to the Manage Servers page. Double-Take will query the source cluster name and get a list of cluster groups that contain a file share resource and then present those groups for protection. Double-Take will failover the name, IP addresses, SPNs, and shares for the clustered file server to the standalone target.
• For cluster to cluster jobs, the source and target cluster names must be added to the Manage Servers page. Double-Take will query the source cluster name and get a list of cluster groups that contain a file share resource and then present those groups for protection. Double-Take will not failover the name, IP addresses, SPNs, or shares. Failover will be DNS failover. Groups will be brought online on the target, therefore they need to be pre-staged using step 1 or 2 below, depending on your operating system.
• For standalone to cluster jobs, the standalone source and the target cluster name must be added to the Manage Servers page. Double-Take will query the target cluster name and determine which cluster group contains the disk resource where data will be sent. Failover is not supported for standalone to cluster files and folders jobs. Jobs in this configuration can only be used for data protection or migration, not high availability.

1. If you are using a cluster to cluster configuration and you are using Windows 2003, follow these instructions to configure the target cluster before you create your Double-Take files and folders job.
   1. Take the source file server Network Name offline.
   2. Create the same Network Name on the target cluster in the file server group.
   3. Create identical file shares in the target file server group and make them dependent on the Network Name that was just created.
   4. Take the target Network Name resource offline.
   5. Bring the source Network Name resource online.
   6. If it is not already, DNS registration must be enabled for a source cluster name for DNS failover to function properly. You should not allow the source cluster name to come online if your source fails over.
2. If you are using a cluster to cluster configuration and you are using Windows 2008, follow these instructions to configure the target cluster before you create your Double-Take files and folders job.
   1. You may want to lower the TTL (time to live) value of your DNS records to avoid caching during this configuration.

   2. Give the target cluster account full control over the source file server account in Active Directory and over the source file server DNS record.

      If control of the DNS record is not added, the Client Access Point will fail name resolution and you will not be able to create the target shares unless the record is manually updated.

       

   3. Take the source file server Client Access Point offline, including IP address, and then flush DNS on the target.
   4. Create the Client Access Point with the same name on the target and provide a unique IP address.
   5. While the target Client Access Point is online, create identical shares to the source file server.
   6. Take the target Client Access Point and IP address offline. Take the target file share resources offline.
   7. Bring the source Client Access Point online. DNS registration will change the IP address back to the source IP address.
   8. If desired, reset your TTL value back to its original value.
   9. If it is not already, DNS registration must be enabled for a source cluster name for DNS failover to function properly. You should not allow the source cluster name to come online if your source fails over.

3. Click Get Started from the toolbar.

4. Select Double-Take Availability and click Next.

5. Select Protect files and folders, an application, or an entire Windows server and click Next.

6. Choose your source server. This is the server that contains the files and folders that you want to protect. If your source is a cluster, select the source cluster name, not the file server or node name.

   

   • Current Servers—This list contains the servers currently available in your console session. Servers that are not licensed for the workflow you have selected will be filtered out of the list. Select your source server from the list.
   • Find a New Server—If the server you need is not in the Current Servers list, click the Find a New Server heading. From here, you can specify a server along with credentials for logging in to the server. If necessary, you can click Browse to select a server from a network drill-down list.

   If you enter the source server's fully-qualified domain name, the Double-Take Console will resolve the entry to the server short name. If that short name resides in two different domains, this could result in name resolution issues. In this case, enter the IP address of the server.

   When specifying credentials for a new server, specify a user that is a member of the local Double-Take Admin and local administrator security groups. Ideally, you should use a local account rather than a domain account because the domain account will fail to authenticate while failed over if the NETBIOS name and/or SPNs are failed over. If you want Double-Take to update DNS during failover, the account must be a member of the Domain Admins group. If your security policies do not allow use of this group, see DNS and use the instructions under the Double-Take DFO utility to use a non-Domain Admins account.

   To best prepare for a potential failover, restore, and failback scenario, you may want to use a source server that has been inserted into the console by a private IP address. In this scenario, your source must have at least two IP addresses, one for public communication and one for private. If you insert your source in the console using the private IP address, then that private IP address can more easily be used after a failure to restore the data that changed during failover from the target back to the source. If your source server has already been inserted into the console by name, you can remove it and reinsert it by private IP address on the Manage Servers page.

    

7. Click Next to continue.

8. Choose the type of workload that you want to protect. Under Server Workloads, in the Workload types pane, select Files and Folders. In the Workload items pane, you will see the volumes and shares (if any) for your source, or if you are protecting a cluster, you will see your cluster groups. Select the volumes, shares, or cluster groups that you want to protect.

   If the workload you are looking for is not displayed, enable Show all workload types. The workload types in gray text are not available for the source server you have selected. Hover your mouse over an unavailable workload type to see a reason why this workload type is unavailable for the selected source.

9. To select your files and folders in more detail, click the Replication Rules heading and expand the volumes under Folders.

   

   Volumes and folders with a green highlight are included in their entirety in the protection. Volumes and folders highlighted in light yellow have individual files included in the protection. If there is no highlight, no part of the volume or folder is included in the protection. To modify the items selected, highlight a volume, folder, or file and click Add Rule. You can also enter a rule, including a wildcard specification, manually. Specify if you want to Include or Exclude the item. Also, specify if you want the rule to be recursive, which indicates the rule should automatically be applied to the subdirectories of the specified path. If you do not select Recursive, the rule will not be applied to subdirectories.

   If you need to remove a rule, highlight it in the list at the bottom and click Remove Rule. Be careful when removing rules. Double-Take may create multiple rules when you are adding directories. For example, if you add E:\Data to be included in protection, then E:\ will be excluded. If you remove the E:\ exclusion rule, then the E:\Data rule will be removed also.

   If you return to this page using the Back button in the job creation workflow, your Workload Types selection will be rebuilt, potentially overwriting any manual replication rules that you specified. If you do return to this page, confirm your Workload Types and Replication Rules are set to your desired settings before proceeding forward again.

    

10. Click Next to continue.

11. Choose your target server. This is the server that will store the replica data from the source.If your target is a cluster, select the target cluster name, not the file server or node name.

    

    • Current Servers—This list contains the servers currently available in your console session. Servers that are not licensed for the workflow you have selected and those not applicable to the workload type you have selected will be filtered out of the list. Select your target server from the list.
    • Find a New Server—If the server you need is not in the Current Servers list, click the Find a New Server heading. From here, you can specify a server along with credentials for logging in to the server. If necessary, you can click Browse to select a server from a network drill-down list.

    If you enter the target server's fully-qualified domain name, the Double-Take Console will resolve the entry to the server short name. If that short name resides in two different domains, this could result in name resolution issues. In this case, enter the IP address of the server.

    When specifying credentials for a new server, specify a user that is a member of the local Double-Take Admin and local administrator security groups. Ideally, you should use a local account rather than a domain account because the domain account will fail to authenticate while failed over if the NETBIOS name and/or SPNs are failed over. If you want Double-Take to update DNS during failover, the account must be a member of the Domain Admins group. If your security policies do not allow use of this group, see DNS and use the instructions under the Double-Take DFO utility to use a non-Domain Admins account.

     

12. Click Next to continue.

13. You have many options available for your files and folders job. However, not all of the options will be applicable to clustered environments. Configure those options that are applicable to your environment.

    Click a link below to see the options available for that section of the Set Options page.

    General

    

    For the Job name, specify a unique name for your job.

    Failover Monitor

    

    • Total time to failure—Specify, in hours:minutes:seconds, how long the target will keep trying to contact the source before the source is considered failed. This time is precise. If the total time has expired without a successful response from the source, this will be considered a failure.

      Consider a shorter amount of time for servers, such as a web server or order processing database, which must remain available and responsive at all times. Shorter times should be used where redundant interfaces and high-speed, reliable network links are available to prevent the false detection of failure. If the hardware does not support reliable communications, shorter times can lead to premature failover. Consider a longer amount of time for machines on slower networks or on a server that is not transaction critical. For example, failover would not be necessary in the case of a server restart.

    • Consecutive failures—Specify how many attempts the target will make to contact the source before the source is considered failed. For example, if you have this option set to 20, and your source fails to respond to the target 20 times in a row , this will be considered a failure.

    • Monitor on this interval—Specify, in hours:minutes:seconds, how long to wait between attempts to contact the source to confirm it is online. This means that after a response (success or failure) is received from the source, Double-Take will wait the specified interval time before contacting the source again. If you set the interval to 00:00:00, then a new check will be initiated immediately after the response is received.

      If you choose Total time to failure, do not specify a longer interval than failure time or your server will be considered failed during the interval period.

      If you choose Consecutive failures, your failure time is calculated by the length of time it takes your source to respond plus the interval time between each response, times the number of consecutive failures that can be allowed. That would be (response time + interval) * failure number. Keep in mind that timeouts from a failed check are included in the reponse time, so your failure time will not be precise.

    • Network monitoring—With this option, the target will monitor the source using a network ping. Disable this option if you are using a standalone to cluster configuration, because failover is not supported.

      • Monitor these addresses—Select each Source IP Address that you want the target to monitor.

        If you are protecting a cluster, you are limited to the IP addresses in the cluster group that you are protecting.

         

      • Monitoring method—This option determines the type of network ping used for failover monitoring.
        • Network service—Source availability will be tested by an ICMP ping to confirm the route is active.
        • Replication service—Source availability will be tested by a UDP ping to confirm the Double-Take service is active.
        • Network and replication services—Source availability will be tested by both an ICMP ping to confirm the route is active and a UDP ping to confirm the Double-Take service is active. Both pings must fail in order to trigger a failover.
      • Failover trigger—If you are monitoring multiple IP addresses, specify when you want a failover condition to be triggered.
        • One monitored IP address fails—A failover condition will be triggered when any one of the monitored IP addresses fails. If each IP address is on a different subnet, you may want to trigger failover after one fails.
        • All monitored IP addresses fail—A failover condition will be triggered when all monitored IP addresses fail. If there are multiple, redundant paths to a server, losing one probably means an isolated network problem and you should wait for all IP addresses to fail.
    Failover Options

    If you are using a standalone to cluster configuration, you can skip this section because failover is not supported.

     

    

    • Wait for user to initiate failover—By default, the failover process will wait for you to initiate it, allowing you to control when failover occurs. When a failure occurs, the job will wait in Failover Condition Met for you to manually initiate the failover process. Disable this option only if you want failover to occur immediately when a failure occurs.

    • Failover shares—By default, shares will be failed over to the target. If you do not want to failover shares, disable this option.

      Automatic share failover only occurs for standard Windows file system shares. Other shares must be configured for failover through the failover scripts or created manually on the target. See Macintosh shares or NFS Shares for more information.

      If you are failing over Windows shares but your source and target do not have the same drive letters, you must use the All to One selection under Path Mapping when establishing your job. Otherwise, the shares will not be created on the target during failover.

      If your target is a standalone server, Windows share information is automatically updated on the target once an hour. If your target is a cluster, you will need to manually update shares on the target. For Windows 2003, you can create the file share resources while the source is running but keep the resource offline. For Windows 2008, you will need to repeat the initial cluster configuration steps, although you can skip giving the target cluster account full control and creating the target Client Access Point, because those steps were already completed during the initial cluster configuration.

      Shares are not applicable to environments where the target is a cluster.

       

    • Failover host name—If desired, you can failover the source server's host name. This will automatically remove the host SPN (Service Principle Name) from Active Directory on the source and add it to Active Directory on the target. If you are using Active Directory, enable this option or you may experience problems with failover.
    • Failback host name—This option returns the host SPN on the source and target back to their original settings on failback. If you are using Active Directory, enable this option or you may experience problems with failback.
    • Active Directory Credentials—If you are failing over and/or failing back the host name, you need to specify a user that has update privileges within Active Directory. Click Active Directory Credentials and identify a user and the associated password that has privileges to create and delete SPNs. The username must be in the format fully_qualified_domain\user,, and the account password cannot be blank.

    • Scripts—You can customize failover and failback by running scripts on the source and target. Scripts may contain any valid Windows command, executable, or batch file. The scripts are processed using the same account running the Double-Take service, unless you have identified a specific account through the server's properties. See Script credentials. Examples of functions specified in scripts include stopping services on the target before failover because they may not be necessary while the target is standing in for the source, stopping services on the target that need to be restarted with the source’s machine name and/or IP address, starting services or loading applications that are in an idle, standby mode waiting for failover to occur, notifying the administrator before and after failover or failback occurs, stopping services on the target after failback because they are no longer needed, stopping services on the target that need to be restarted with the target machine’s original name and/or IP address, and so on. There are four types of failover and failback scripts.

      • Pre-failover script—This script runs on the target at the beginning of the failover process. Specify the full path and name of the script file.
      • Post-failover script—This script runs on the target at the end of the failover process. Specify the full path and name of the script file.
      • Pre-failback script —This script runs on the target at the beginning of the failback process. Specify the full path and name of the script file.
      • Post-failback script—This script runs on the target at the end of the failback process. Specify the full path and name of the script file.
      • Arguments—Specify a comma-separated list of valid arguments required to execute the script.
      • Delay until script completes—Enable this option if you want to delay the failover or failback process until the associated script has completed. If you select this option, make sure your script handles errors, otherwise the failover or failback process may never complete if the process is waiting on a script that cannot complete.

      Scripts will run but will not be displayed on the screen if the Double-Take service is not set to interact with the desktop. Enable this option through the Windows Services applet.

    Failover Identity

    

    • Apply source network configuration to the target—If you select this option, you can configure the source IP addresses to failover to the target. If your target is on the same subnet as the source (typical of a LAN environment), you should select this option.

      If you are applying the source network configuration to the target in a WAN environement, do not failover your IP addresses unless you have a VPN infrastructure so that the source and target can be on the same subnet, in which case IP address failover will work the same as a LAN configuration. If you do not have a VPN, you can automatically reconfigure the routers via a failover script (by moving the source's subnet from the source's physical network to the target's physical network). There are a number of issues to consider when designing a solution that requires router configuration to achieve IP address failover. Since the route to the source's subnet will be changed at failover, the source server must be the only system on that subnet, which in turn requires all server communications to pass through a router. Additionally, it may take several minutes or even hours for routing tables on other routers throughout the network to converge.

       

      • Failover server name—Select this option to failover the server name to the target. Double-Take checks the hosts file and uses the first name there. If there is no hosts file, Double-Take will use the first name in DNS. (Keep in mind, the first name in DNS may not always be the same each time the DNS server is rebooted.) Lastly, if there is no DNS server, Double-Take will use the failover monitor name created by the Double-Take Console. You will need to failover the server name for file shares to function properly after failover. If you do not want to failover the server name, disable this option.

      • Add these addresses to the selected target adapter after failover—Select which IP addresses you want to failover and select the Target Network Adapter that will assume the IP address during failover.

        If you have inserted your source server into the console using a private IP address, do not select the private IP address for failover.

        If you configured failover to be triggered when all monitored IP addresses fail and are failing over more IP addresses than you are monitoring, you may have IP address conflicts after failover. For example, if you monitor two out of three addresses, and those two addresses fail but the third one does not, and you failover all three IP addresses, the third address that did not fail may exist on both the source and the target, depending on the cause of the failure. Therefore, when a source is failing over more IP addresses than are being monitored, there is a risk of an IP address conflict.

        If you are protecting a cluster, you are limited to the IP addresses in the cluster group that you are protecting.

         

    • Retain target network configuration—If you select this option, the target will retain all of its original IP addresses. If your target is on a different subnet (typical of a WAN environment), you should select this option.

      If you choose to retain the target network configuration, but have also selected to failover shares under the Failover Options sections, the source NetBIOS name will automatically be failed over so that the shares can be accessed after failover.

       

      • Update DNS server—Specify if you want Double-Take to update your DNS server on failover. If DNS updates are made, the DNS records will be locked during failover.

        Expand the DNS Options section to configure how the updates will be made. The source's domain, the current DNS credentials, and the DNS servers from the source's domain controller will be discovered and displayed.

        • Change—If necessary, click this button and specify a user that has privileges to access and modify DNS records. The account must be a member of the DnsAdmins group for the domain, and must have full control permissions on the source's A (host) and PTR (reverse lookup) records. These permissions are not included by default in the DnsAdmins group. You can enter a user name for a different domain by entering a fully qualified user name. The fully qualified user name must be in the format domain\username or username@domain. If you enter a non-qualified name, the selected domain will be used.
        • Remove—If there are any DNS servers in the list that you do not want to update, highlight them and click Remove.
        • Update these source DNS entries with the corresponding target IP address—For each IP address on the source, specify what address you want DNS to use after failover. For clusters, be sure and select the clustered IP address.
        • Update TTL—Specify the length of time, in seconds, for the time to live value for all modified DNS A records. Ideally, you should specify 300 seconds (5 minutes) or less.

      If you select Retain your target network configuration but do not enable Update DNS server, you will need to specify failover scripts that update your DNS server during failover, or you can update the DNS server manually after failover. This would also apply to non--Microsoft Active Directory Integrated DNS servers. You will want to keep your target network configuration but do not update DNS. In this case, you will need to specify failover scripts that update your DNS server during failover, or you can update the DNS server manually after failover.

       

    Mirror, Verify & Orphaned Files

    

    • Mirror all files—All protected files will be mirrored from the source to the target.
    • Mirror different files—Only those protected files that are different based on date and time, size, or attributes will be mirrored from the source to the target.

    • Mirror only if the file on the source is newer than the copy on the target—Only those protected files that are newer on the source are mirrored to the target.

      If you are using a database application or are protecting a domain controller, do not use this option unless you know for certain that you need it. With database applications and because domain controllers store their data in a database, it is critical that all files, not just some of the files that might be newer, get mirrored.

       

    • Use block checksum for comparisons—For those files flagged as different, the mirroring process can perform a block checksum comparison and send only those blocks that are different.

    • Enable scheduled verification—Verification is the process of confirming that the source replica data on the target is identical to the original data on the source. Verification creates a log file detailing what was verified as well as which files are not synchronized. If the data is not the same, can automatically initiate a remirror, if configured. The remirror ensures data integrity between the source and target. When this option is enabled, Double-Take will verify the source replica data on the target and generate a verification log.

      Because of the way the Windows Cache Manager handles memory, machines that are doing minimal or light processing may have file operations that remain in the cache until additional operations flush them out. This may make Double-Take files on the target appear as if they are not synchronized. When the Windows Cache Manager releases the operations in the cache on the source and target, the files will be updated on the target.

       

    • Verify on this interval—Specify the interval between verification processes.
    • Begin immediately—Select this option if you want to start the verification schedule immediately after the job is established.
    • Begin at this time—Select this option if you want to start the verification at the specified date and time.
    • Mirror files to the target server when verifying—When this option is enabled, in addition to verifying the data and generating a log, Double-Take will also mirror to the target any protected files that are different on the source.

    • Mirror only if the file on the source is newer than the copy on the target—Only those protected files that are newer on the source are mirrored to the target.

      If you are using a database application or are protecting a domain controller, do not use this option unless you know for certain that you need it. With database applications and because domain controllers store their data in a database, it is critical that all files, not just some of the files that might be newer, get mirrored.

       

    • Use block checksum for comparisons—For those files flagged as different, the mirroring process can perform a block checksum comparison and send only those blocks that are different.

    • Calculate size of protected data before mirroring—Specify if you want Double-Take to determine the mirroring percentage calculation based on the amount of data being protected. If the calculation is enabled, it is completed before the job starts mirroring, which can take a significant amount of time depending on the number of files and system performance. If your job contains a large number of files, for example, 250,000 or more, you may want to disable the calculation so that data will start being mirrored sooner. Disabling calculation will result in the mirror status not showing the percentage complete or the number of bytes remaining to be mirrored.

      The calculated amount of protected data may be slightly off if your data set contains compressed or sparse files.

       

    • Delete orphaned files—An orphaned file is a file that exists in the replica data on the target, but does not exist in the protected data on the source. This option specifies if orphaned files should be deleted on the target during a mirror, verification, or restoration.

      Orphaned file configuration is a per target configuration. All jobs to the same target will have the same orphaned file configuration.

      The orphaned file feature does not delete alternate data streams. To do this, use a full mirror, which will delete the additional stream(s) when the file is re-created.

      If delete orphaned files is enabled, carefully review any replication rules that use wildcard definitions. If you have specified wildcards to be excluded from protection, files matching those wildcards will also be excluded from orphaned file processing and will not be deleted from the target. However, if you have specified wildcards to be included in your protection, those files that fall outside the wildcard inclusion rule will be considered orphaned files and will be deleted from the target.

      If you want to move orphaned files rather than delete them, you can configure this option along with the move deleted files feature to move your orphaned files to the specified deleted files directory. See Target server properties for more information.

      During a full mirror, orphaned file processing success messages will be logged to a separate orphaned file log. This keeps the Double-Take log from being overrun with orphaned file success processing messages. Orphaned files processing statistics and any errors in orphaned file processing will still be logged to the Double-Take log, and during difference mirrors, verifications, and restorations, all orphaned file processing messages are logged to the Double-Take log. The orphaned file log is located in the Logging folder specified for the source. See Log file properties for details on the location of that folder. The orphaned log file is overwritten during each orphaned file processing during a full mirror, and the log file will be a maximum of 50 MB.

       

    Network Route

    

    This section is not applicable if your target is a cluster.

     

    • Send data to the target server using this route—By default, Double-Take will select a target route for transmissions. If desired, specify an alternate route on the target that the data will be transmitted through. This allows you to select a different route for Double-Take traffic. For example, you can separate regular network traffic and Double-Take traffic on a machine with multiple IP addresses.

      The IP address used on the source will be determined through the Windows route table.

       

    • Block target paths upon connection—You can block writing to the replica source data located on the target. This keeps the data from being changed outside of Double-Take processing. Any target paths that are blocked will be unblocked automatically during the failover process so that users can modify data after failover. During restoration, the paths are automatically blocked again. If you failover and failback without performing a restoration, the target paths will remain unblocked.
    Path Mapping

    

    For the Mappings, specify the location on the target where the replica of the source data will be stored. By default, the replica source data will be stored in the same directory structure on the target, in a one to one configuration. Make sure you update this location if you are protecting multiple sources or jobs to the same target. Double-Take offers two pre-defined locations as well as a custom option that allows you to set your path.

    • All To One—Click this button to set the mapping so that the replica source data will be stored on a single volume on the target. The pre-defined path is \source_name\volume_name. If you are protecting multiple volumes on the source, each volume would be stored on the same volume on the target. For example, C:\data and D:\files for the source Alpha would be stored in D:\alpha\C and D:\alpha\D, respectively.
    • One To One—Click this button to set the mapping so that the replica source data will be stored in the same directory structure on the target. For example, C:\data and D:\files on the source will be stored in C:\data and D:\files, respectively, on the target.
    • Custom Location—If the pre-defined options do not store the data in a location that is appropriate for your network operations, you can specify your own custom location where the replica source data will be stored. Click the Target Path and edit it, selecting the appropriate location.

    If you are protecting dynamic volumes or mount points, your location on the target must be able to accommodate the amount of data that may be stored on the source.

    If you are protecting multiple mount points, your directory mapping must not create a cycle or loop. For example, if you have the C: volume mounted at D:\C and the D: volume mounted at C:\D, this is a circular configuration. If you establish a job for either C:\D or D:\C, there will be a circular configuration and Double-Take mirroring will never complete.

    If you are protecting sparse files and your location on the target is a non-NTFS 5 volume, the amount of disk space available must be equal to or greater than the entire size of the sparse file. If the target location is an NTFS 5 volume, the amount of disk space available must be equal to or greater than the on-disk size of the sparse file.

     

    Failover Services

    

    This section is not applicable to clustered environments.

     

    Services to stop on source and start on target during failover and start on source and stop on target during failback—If necessary, you can start and stop services during failover and failback. Click Add to insert a service into the list or Remove to remove a service from the list. The services will be started in the order they appear and stopped in the reverse order. Highlight a service and click Move Up or Move Down to arrange the services in the desired order.

    Snapshots

    

    This section is not applicable to clustered environments.

     

    A snapshot is an image of the source replica data on the target taken at a single point in time. You can view the snapshots in VSS and recover any files or folders desired. However, you cannot failover to a snapshot.

    Turn on Enable scheduled snapshots if you want Double-Take to take snapshots automatically at set intervals.

    • Take snapshots on this interval—Specify the interval (in days, hours, or minutes) for taking snapshots.
    • Begin immediately—Select this option if you want to start taking snapshots immediately after the protection job is established.
    • Begin at this time—Select this option if you want to start taking snapshots starting at a later date and time. Specify the date and time parameters to indicate when you want to start.

    See Managing snapshots for details on taking manual snapshots and deleting snapshots.

    You may want to set the size limit on how much space snapshots can use. See your VSS documentation for more details.

     

    Compression

    

    To help reduce the amount of bandwidth needed to transmit Double-Take data, compression allows you to compress data prior to transmitting it across the network. In a WAN environment this provides optimal use of your network resources. If compression is enabled, the data is compressed before it is transmitted from the source. When the target receives the compressed data, it decompresses it and then writes it to disk. You can set the level from Minimum to Maximum to suit your needs.

    Keep in mind that the process of compressing data impacts processor usage on the source. If you notice an impact on performance while compression is enabled in your environment, either adjust to a lower level of compression, or leave compression disabled. Use the following guidelines to determine whether you should enable compression.

    • If data is being queued on the source at any time, consider enabling compression.
    • If the server CPU utilization is averaging over 85%, be cautious about enabling compression.
    • The higher the level of compression, the higher the CPU utilization will be.
    • Do not enable compression if most of the data is inherently compressed. Many image (.jpg, .gif) and media (.wmv, .mp3, .mpg) files, for example, are already compressed. Some images files, such as .bmp and .tif, are decompressed, so enabling compression would be beneficial for those types.
    • Compression may improve performance even in high-bandwidth environments.
    • Do not enable compression in conjunction with a WAN Accelerator. Use one or the other to compress Double-Take data.

    All jobs from a single source connected to the same IP address on a target will share the same compression configuration.

     

    Bandwidth

    

    Bandwidth limitations are available to restrict the amount of network bandwidth used for Double-Take data transmissions. When a bandwidth limit is specified, Double-Take never exceeds that allotted amount. The bandwidth not in use by Double-Take is available for all other network traffic.

    All jobs from a single source connected to the same IP address on a target will share the same bandwidth configuration.

     

    • Do not limit bandwidth—Double-Take will transmit data using 100% bandwidth availability.
    • Use a fixed limit—Double-Take will transmit data using a limited, fixed bandwidth. Select a Preset bandwidth limit rate from the common bandwidth limit values. The Bandwidth field will automatically update to the bytes per second value for your selected bandwidth. This is the maximum amount of data that will be transmitted per second. If desired, modify the bandwidth using a bytes per second value. The minimum limit should be 3500 bytes per second.
    • Use scheduled limits—Double-Take will transmit data using a dynamic bandwidth based on the schedule you configure. Bandwidth will not be limited during unscheduled times.
    • New—Click New to create a new scheduled bandwidth limit. Specify the following information.
    • Daytime entry—Select this option if the start and end times of the bandwidth window occur in the same day (between 12:01 AM and midnight). The start time must occur before the end time.
    • Overnight entry—Select this option if the bandwidth window begins on one day and continues past midnight into the next day. The start time must be later than the end time, for example 6 PM to 6 AM.
    • Day—Enter the day on which the bandwidth limiting should occur. You can pick a specific day of the week, Weekdays to have the limiting occur Monday through Friday, Weekends to have the limiting occur Saturday and Sunday, or Every day to have the limiting repeat on all days of the week.
    • Start time—Enter the time to begin bandwidth limiting.
    • End time—Enter the time to end bandwidth limiting.
    • Preset bandwidth—Select a bandwidth limit rate from the common bandwidth limit values. The Bandwidth field will automatically update to the bytes per second value for your select bandwidth.
    • Bandwidth—If desired, modify the bandwidth using a bytes per second value. The minimum limit should be 3500 bytes per second.
    • Edit—Click Edit to modify an existing scheduled bandwidth limit.
    • Delete—Click Delete to remove a scheduled bandwidth limit.

    If you change your job option from Use scheduled limits to Do not limit bandwidth or Use a fixed limit, any schedule that you created will be preserved. That schedule will be reused if you change your job option back to Use scheduled limits.

    You can manually override a schedule after a job is established by selecting Other Job Options, Set Bandwidth. If you select No bandwidth limit or Fixed bandwidth limit, that manual override will be used until you go back to your schedule by selecting Other Job Options, Set Bandwidth, Scheduled bandwidth limit. For example, if your job is configured to use a daytime limit, you would be limited during the day, but not at night. But if you override that, your override setting will continue both day and night, until you go back to your schedule. See the Managing and controlling jobs section for your job type for more information on the Other Job Options.

     

    Scripts

    

    You can customize mirroring by running scripts on the target at pre-defined points in the mirroring process. Scripts may contain any valid Windows command, executable, or batch file. The scripts are processed using the same account running the Double-Take service, unless you have identified a specific account through the server's properties. See Script credentials. There are three types of mirroring scripts.

    • Mirror Start—This script starts when the target receives the first mirror operation. In the case of a difference mirror, this may be a long time after the mirror is started because the script does not start until the first different data is received on the target. If the data is synchronized and a difference mirror finds nothing to mirror, the script will not be executed. Specify the full path and name of the Script file.
    • Mirror Complete—This script starts when a mirror is completed. Because the mirror statistics may indicate a mirror is at 99-100% when it is actually still processing (for example, if files were added after the job size was calculated, if there are alternate data streams, and so on), the script will not start until all of the mirror data has been completely processed on the target. Specify the full path and name of the Script file.
    • Mirror Stop—This script starts when a mirror is stopped, which may be caused by an auto-disconnect occurring while a mirror is running, the service is shutdown while a mirror is running, or if you stop a mirror manually. Specify the full path and name of the Script file.
    • Arguments—Specify a comma-separated list of valid arguments required to execute the script.
    • Allow script to interact with desktop—Enable this option if you want the script processing to be displayed on the screen. Otherwise, the script will execute silently in the background.
    • Delay until script completes—Enable this option if you want to delay the mirroring process until the associated script has completed. If you select this option, make sure your script handles errors, otherwise the mirroring process may never complete if the process is waiting on a script that cannot complete.
    • Test—You can test your script manually by clicking Test. Your script will be executed if you test it. If necessary, manually undo any changes that you do not want on your target after testing the script.

    Mirror scripts are dependent on the target and the Target Path Mappings specified under the Network Route & Folder Selection section. If you establish mirroring scripts for one job and then establish additional jobs to the same target using the same target path mapping, the mirroring scripts will automatically be applied to those subsequent jobs. If you select a different target path mapping, the mirroring scripts will have to be reconfigured for the new job(s).

     

14. Click Next to continue.

15. Double-Take validates that your source and target are compatible. The Summary page displays your options and validation items.

    Errors are designated by a white X inside a red circle. Warnings are designated by a black exclamation point (!) inside a yellow triangle. A successful validation is designated by a white checkmark inside a green circle. You can sort the list by the icon to see errors, warnings, or successful validations together. Click on any of the validation items to see details. You must correct any errors before you can enable protection. Depending on the error, you may be able to click Fix or Fix All and let Double-Take correct the problem for you. For those errors that Double-Take cannot correct automatically, you will need to modify the source or target to correct the error, or you can select a different target. You must revalidate the selected servers, by clicking Recheck, until the validation check passes without errors.

    Before a job is created, the results of the validation checks are logged to the Double-Take Management Service log on the target.

16. Once your servers have passed validation and you are ready to establish protection, click Finish, and you will automatically be taken to the Manage Jobs page.

If your target is a cluster, a cluster resource named DTTargetRes_FilesAndFolders_GUID will be created in the target cluster group that contains the disk where data is being replicated from the source. If the target cluster group that contains the DTTargetRes_FilesAndFolders_GUID resource is moved to a different node, an auto-disconnect and reconnect will occur, and a re-mirror will be initiated.

If you are using a standalone to cluster configuration, the Failover button on the Manage Jobs page will be enabled once a mirror is complete. Do not failover as unexpected results may occur. Failover is not supported for standalone to cluster configurations.

Related Topics