Double-Take DR requirements

Each type of server must meet certain requirements. Additionally, verify the machine where you are running the console meets the Double-Take Console requirements, and review the Mirroring and replication capabilities to understand the type of data that Double-Take protects.

• Source server—The source server can be a physical or virtual server running any of the following operating systems.

• Windows Server 2003 or 2003 R2 Datacenter, Enterprise (i386, x64), Standard (i386, x64), Web Server, Small Business Server, or Storage Server Edition. Each of the Windows 2003 operating systems require Service Pack 2 or later. (Windows 2003 Itanium-based editions are not supported.)

• Windows Server 2008 or 2008 R2 Datacenter, Enterprise (i386, x64), Standard (i386, x64), Essential Business Server, Web Server, Foundation Server, Small Business Server (including SBS 2011), or Storage Server Edition

• Windows 2012 or 2012 R2 Datacenter, Standard, Essentials, or Foundation Edition

• Server Core is supported with the following caveats.

  • Server Core 2008 R2 SP1, Server Core 2012, and Server Core 2012 R2 are supported. However, Server Core 2008 and Server Core 2008 R2 with no service packs are not supported.
  • If you are recovering a full server image of a Server Core server, your recovery server must be the same Server Core version.
  • DNS updates are not supported for Server Core servers.

• Target repository server—The target server can be any physical or virtual Windows 2008 R2, 2012, or 2012 R2 operating system.

• Recovery server—The recovery server for a data protection job can be any operating system from the source server list above. The recovery server for a full server protection job can also be any operating system from the source server list above, however, keep in mind that a recovery server may be in that list but may not be suitable to stand-in for a source in the event of a source failure. See Recovery server compatibility for additional information regarding an appropriate recovery server for a full server protection job.

• File system—Double-Take supports the NTFS and ReFS file system. FAT and FAT32 are not supported. For detailed information on other file system capabilities, see Mirroring and replication capabilities.

• System memory—The minimum system memory on each server should be 1 GB. The recommended amount for each server is 2 GB.

• Disk space for program files—This is the amount of disk space needed for the Double-Take program files. The amount depends on your operating system version and your architecture (32-bit or 64-bit) and ranges from 350-500 MB.

  The program files can be installed to any volume while the Microsoft Windows Installer files are automatically installed to the operating system boot volume.

  Make sure you have additional disk space for Double-Take queuing, logging, and so on.

   

• Server name—Double-Take includes Unicode file system support, but your server name must still be in ASCII format. If you have the need to use a server's fully-qualified domain name, your server cannot start with a numeric character because that will be interpreted as an IP address. Additionally, all Double-Take servers must have a unique server name.

  If you need to rename a server that already has a Double-Take license applied to it, you should deactivate that license before changing the server name. That includes rebuilding a server or changing the case (capitalization) of the server name (upper or lower case or any combination of case). If you have already rebuilt the server or changed the server name or case, you will have to perform a host-transfer to continue using that license. See the Double-Take Installation, Licensing, and Activation document for complete details.

   

• Time—The clock on your Double-Take servers must be within a few minutes of each other, relative to UTC. Large time skews will cause Double-Take errors.

• Protocols and networking—Your servers must meet the following protocol and networking requirements.

  • Your servers must have TCP/IP with static IP addressing.

  • IPv4 only configurations are supported, IPv4 and IPv6 are supported in combination, however IPv6 only configurations are not supported

  • By default, Double-Take is configured for IPv6 and IPv4 environments, but the Double-Take service will automatically check the server at service startup and modify the appropriate setting if the server is only configured for IPv4.
  • IPv6 is only supported for Windows 2008 and 2012 servers.
  • If you are using IPv6 on your servers, your clients must be run from an IPv6 capable machine.
  • In order to properly resolve IPv6 addresses to a hostname, a reverse lookup entry should be made in DNS.
  • If you are using Double-Take over a WAN and do not have DNS name resolution, you will need to add the host names to the local host file on each server running Double-Take.

• Reverse lookup zone—If you are using a DNS reverse lookup zone, then it must be Active Directory integrated. Double-Take is unable to determine if this integration exists and therefore cannot warn you during job creation if it doesn't exist.

• DNS updates—Full server protection jobs allow you to failover Microsoft DNS records so the source server name resolves to the recovery server IP addresses at failover time. To be able to set up and failover Microsoft DNS records, your environment must meet the following requirements.

  • The source and recovery servers must be in the same domain.
  • The recovery server must have WMI/DCOM connectivity to any DNS server that you have configured to be updated.
  • Each server's network adapter must have the DNS suffix defined, and the primary DNS suffix must be the same on the source and recovery server. You can set the DNS suffix in the network adapters advanced TCP/IP settings or you can set the DNS suffix on the computer name. See the documentation for your specific operating system for details on configuring the DNS suffix.
  • If you are using a DNS reverse lookup zone , then the forward zone must be Active Directory integrated. Double-Take is unable to determine if this integration exists and therefore cannot warn you during job creation if it doesn't exist. The zone should be set for secure only updates to allow for DNS record locking.

  DNS updates are not supported for Server Core servers or NAT environments.

• Microsoft .NET Framework—Microsoft .NET Framework version 4.0 Update 3 or later is required. (The full .NET 4.0.3 is required, not just the Client Profile.)

• Windows firewall—If you have Windows firewall enabled on your servers, there are two requirements for the Windows firewall configuration.

  • The Double-Take installation program will automatically attempt to configure ports 6320, 6325, and 6326 for Double-Take. If you cancel this step, you will have to configure the ports manually.
  • If you are using the Double-Take Console to push installations out to your servers you will have to open firewall ports for WMI (Windows Management Instrumentation), which uses RPC (Remote Procedure Call). By default, RPC will use ports at random above 1024, and these ports must be open on your firewall. RPC ports can be configured to a specific range by specific registry changes and a reboot. See the Microsoft Knowledge Base article 154596 for instructions. Additionally, you will need to open firewall ports for SMB (server message block) communications which uses ports 135-139 and port 445, and you will need to open File and Printer Sharing. As an alternative, you can disable the Windows firewall temporarily until the push installations are complete.

  See Firewalls for instructions on handling firewalls in your environment.

• NAT support—Protection and recovery jobs can support NAT environments in an IP-forwarding configuration with one to one port mappings. Port-forwarding is not supported. Additionally, only IPv4 is supported for NAT environments. Make sure you have added your servers to the Double-Take Console using the correct IP address. Review the NAT configuration table in the Adding servers section before you start the job creation process.

• Clusters—Cluster configurations are not supported on the source or target. Your servers must be in a standalone to standalone configuration.

• Snapshots—You can take and failover to Double-Take snapshots with protection and recovery jobs.

  Double-Take uses the Microsoft Volume Shadow Copy service (VSS) for snapshot capabilities. To use this functionality, your servers must meet the following requirements.

  • Snapshot location—Snapshots are taken and stored inside the image of the source on the target, so be sure that you select a volume that has enough space for the image of the source with its snapshots, as well as any other source images and their snapshots.
  • Double-Take installation location—In order to enable Double-Take snapshots, Double-Take must be installed on the system drive. If Double-Take is not installed on the system drive, snapshots will be disabled when enabling protection.
  • Server IP address—If you have specified an IP address as the source server name, but that IP address is not the server's primary IP address, you will have issues with snapshot functionality. If you need to use snapshots, use the source's primary IP address or its name.

  • Snapshot limitations—Sometimes taking a snapshot may not be possible. For example, there may not be enough disk space to create and store the snapshot, or maybe the target is too low on memory. If a snapshot fails, an Event message and a Double-Take log message are both created and logged.

    There are also limitations imposed by Microsoft Volume Shadow Copy that impact Double-Take snapshots. For example, different Double-Take job types create different snapshot types, either client-accessible or non-client-accessible. VSS only maintains 64 client-accessible snapshots, while it maintains 512 non-client-accessible snapshots. If the maximum number of snapshots exists and another one is taken, the oldest snapshot is deleted to make room for the new one.

    Another example is that Double-Take snapshots must be created within one minute because Volume Shadow Copy snapshots must be created within one minute. If it takes longer than one minute to create the snapshot, the snapshot will be considered a failure.

    Additionally, Volume Shadow Copy will not revert snapshots of a volume with operating system files, therefore Double-Take is also unable to revert a volume with operating system files.

    You must also keep in mind that if you are using extended functionality provided by Volume Shadow Copy, you need to be aware of the impacts that functionality may have on Double-Take. For example, if you change the location where the shadow copies are stored and an error occurs, it may appear to be a Double-Take error when it is in fact a Volume Shadow Copy error. Be sure and review any events created by the VolSnap driver and check your Volume Shadow Copy documentation for details.

    You can use Volume Shadow Copy for other uses outside Double-Take, for example Microsoft Backup uses it. Keep in mind though that the driver for Volume Shadow Copy is started before the driver for Double-Take. Therefore, if you use snapshots on your source and you revert any files on the source that are protected by your job, Double-Take will not be aware of the revert and the file change will not be replicated to the target. The file change will be mirrored to the target during the next mirroring process.

    Volume Shadow Copy snapshots are associated with the volume they belong to. Since Double-Take mirrors and replicates the data on the volume and not the volume itself, snapshots taken on the source cannot be used on the target's volume. Therefore, snapshots taken on the source are not replicated to the target.

Recovery server compatibility

• Operating system version—The source and recovery server must have the same operating system. For example, you cannot have Windows 2008 on the source and Windows 2012 on the recovery server. The two servers do not have to have the same level of service pack or hotfix. Windows 2003 and 2003 R2 are considered the same operating system, however the Windows 2008 and 2012 and their R2 releases are considered different operating systems. Therefore, you can have Windows 2003 on the source and Windows 2003 R2 on the recovery server, , but you cannot have Windows 2008 or 2012 on the source and the corresponding R2 version on the recovery server. . The Windows edition (Standard, Enterprise, and so on) does not have to be the same.

• Operating system language—Your servers must be running the same Windows localized version. For example, if your source is running an English language version of Windows, your recovery server must also be running an English language version of Windows. If your source is running a Japanese language version of Windows, your recovery server must also be running a Japanese language version of Windows. This applies to all localized languages.

• Source and recovery server preparation—Uninstall any applications or operating system features that are not needed from both your source and recovery server. For example, unused language packs will slow down failover since there are thousands of extra files that need to be examined. Ideally, your recovery server should be as clean and simple a configuration as possible.

  During recovery, Double-Take cannot add protocol stacks and specific installations to a target that does not already have them. For example, VPN stacks, communication stacks, and services such as Microsoft's RRAS (Routing and Remote Access Service) must be pre-installed on the target.

   

• Storage Server Edition—If you are using Windows Storage Server Edition, you will need to check with your NAS vendor to verify if there are technical or license restrictions on failing over an image of a server to different hardware.

• Server role—The recovery server cannot be a domain controller. Ideally, the recovery server should not host any functionality (file server, application server, and so on) because the functionality will be removed when failover occurs.

  If your source is a domain controller, it will start in a non-authoritative restore mode after failover. This means that if the source was communicating with other domain controllers before failover, it will require one of those domain controllers to be reachable after failover so it can request updates. If this communication is not available, the domain controller will not function after failover. If the source is the only domain controller, this is not an issue.

• Architecture—The source and the recovery server must have the same architecture. For example, you cannot failover a 32-bit server to a 64-bit server.
• Processors—There are no limits on the number or speed of the processors, but the source and the recovery server should have at least the same number of processors. If the recovery server has fewer processors or slower speeds than the source, there will be performance impacts for the users after failover.
• Memory—The recovery server memory should be within 25% (plus or minus) of the source. If the recovery server has much less memory than the source, there will be performance impacts for the users after failover.
• Network adapters—You must map at least one NIC from the source to one NIC on the recovery server. If you have NICs on the source that are not being used, it is best to disable them. If the source has more NICs than the recovery server, some of the source NICs will not be mapped to the recovery server. Therefore, the IP addresses associated with those NICs will not be available after failover. If there are more NICs on the recovery server than the source, the additional NICs will still be available after failover and will retain their pre-failover network settings.
• File system format—The source and the recovery server must have the same NTFS or ReFS file system format on each server. FAT and FAT32 are no longer supported.
• Logical volumes—There are no limits to the number of logical volumes, although you are bound by operating system limits. For each volume you are protecting on the source, the recovery server must have a matching volume. For example, if you are protecting drives C: and D: on the source, the recovery server cannot have drives D: and E:. In this case, the recovery server must also have drives C: and D:. Additional recovery server volumes are preserved and available after failover, with all data still accessible.
• System path—The source and the recovery server must have the same system path. The system path includes the location of the Windows files, Program Files, and Documents and Settings.
• Double-Take path—Double-Take must be installed on the same path (volume and full directory path) on the source and the recovery server.

• Disk space—The recovery server must have enough space to store the data from the source. This amount of disk space will depend on the applications and data files you are protecting. The more data you are protecting, the more disk space you will need. The recovery server must also have enough space to store, process, and apply the source's system state data. The size of the system state will depend on the operating system and architecture.

  A copy of the source system state data will be staged on the recovery server boot volume in a folder called Staging-SSM. You can predict (approximately) how much space you will need in this staging folder by calculating the size of the following folders on your source boot volume.

  • Documents and Settings
  • Program Files
  • Program Files (x86)
  • Program Data
  • Windows
  • Users
  • Any other folders you manually select for staging

  If the recovery server's boot volume does not have enough space to accommodate the source data and the staging folder, the job will become stuck in a retrying state and will be unable to complete synchronization. You should also have approximately 2-3 GB or more additional space on the recovery server boot volume (beyond your calculation above) to ensure there is enough space for failover processing.

  The following are rough estimates for the free space needed for the staging folder for different operating systems.

  • Windows 2003—at least 2-3 GB
  • Windows 2008—at least 7-9 GB
  • Windows 2008 R2—at least 10 GB
  • Windows 2012—at least 14 GB
  • Windows 2012 R2—at least 15 GB

  These minimums are for a clean operating system installation. Operating system customizations, installed applications, and user data will increase the disk space requirement.