Double Take FAQ

When first deployed, it is necessary for Double-Take to create an initial copy of the data from the source onto the target. This is necessary to then allow replication to update it with just the changes. Synchronization is sometimes referred to as "mirroring", where a mirror copy of the entire data set is created. The only other time it is necessary to resynchronize is after the connection between the source and target is broken, either due to a server shutdown, network disconnect, etc. Should this occur, Double-Take will perform a resynchronization once the connection is reestablished. Resynchronization doesn't copy all of the source data, it copies just the differences between the source and target. Resynchronization has a few options to determine what is different on the target. It can either check file attributes such as size, modification date, etc. and copy differences based on this information or it can do a block-level checksum compare. This is configurable within the user interface.

No. Unlike other replication products that replicate entire files or whole blocks when only small changes are made, Double-Take replicates just the bytes that are changed. This allows Double-Take to provide efficient use of network resources and minimize latency between the source and target servers.

Double-Take is a driver-level application that captures changes at the file-system level as they are made on the source server. If configured appropriately, and the network bandwidth is available, these changes will be immediately replicated to the target server(s). Most often this is the case, however there are times when your business may require changes to be transmitted at a lower priority than other tasks currently occurring. In this case, Double-Take offers numerous configuration options that allow transmissions to be controlled to best suit your needs.

Yes. Double-Take does not by default lock the data on the target server. This allows read and write access on the target data. This is very useful for data distribution to remote branch offices, testing, etc.

Yes. Double-Take supports all Unicode files for replication, including non-English alphabet characters (Japanese, etc.). The Double-Take Management Console also supports Unicode characters for configuring replication sets, etc.

Yes. All ACL's are copied to the target replica during the initial synchronization and are also maintained during replication. Unlike other replication products, if an ACL is changed on a source file, this change WILL be replicated to the target. This is critical in maintaining file and data security in your environment.

Yes. Any source file or folder that has a share defined for it will have it?

Yes. All encrypted files will be copied during the initial synchronization and will continue to be replicated during the real-time replication process. Encryption remains enabled on the target replica to ensure proper security is maintained.

Yes. During a synchronization, Double-Take can also perform real-time replication. This ensures that any changes taking place during the synchronization process are also captured and replicated. Once the synchronization is complete the target replica is an exact copy of the source at that point.

Yes. Double-Take is able to replicate data from clustered servers to another cluster or to a standalone server. Double-Take also allows for failover from the cluster to the target server, even if the target is not a cluster. This greatly enhances the protection and availability of the cluster. For an even greater level of availability and protection of your MSCS environment, NSI offers GeoCluster. For more information on GeoCluster please visit our website at www.nsisoftware.com.

Yes. Double-Take has numerous settings to allow customized control of how and when it runs and how much bandwidth it can use.

Yes. You will be required to reboot your servers just once during the initial installation of Double-Take. Once running, Double-Take requires no additional reboots of the server for any reason, including new files, applications, write-locks, start/stop of applications, etc.

The Double-Take Users Guide which can be found on the installation CD contains a list and explanation of error codes.

Because Double-Take works at the file-system level, any application that utilizes the NTFS file system is fully supported by Double-Take. Whether it be Microsoft Exchange, SQL ServerTM, Oracle ®, or any other third-party or home-grown application, Double-Take will ensure that it?

While Double-Take does require some CPU cycles to run, it is typical that it will consume an average of 5%, sometimes more when necessary and when available, and sometimes less. This may vary depending on your particular environment, size of your systems, amount of data being changed, etc. However unlike synchronous replication solutions, Double-Take does not prevent the applications from processing data while Double-Take replicates it. Double-Take will capture the data and write it to cache until it can be transmitted to the target, however the applications will continue to process and write data.

While snapshots are useful in providing for rapid recovery of files from different points in time, they typically do not allow for creation on a separate disk or server and are not full data images, they typically capture just the changed data. As such they are not able to provide recovery in the event a server or disk were to fail or become unavailable. Double-Take on the other hand provides local and remote replication and creates a complete image of the production data that can be used for rebuilding, restoring, and failover.

Double-Take provides asynchronous replication. Although your particular environment will yield different results, Double-Take provides very fast and efficient replication of data resulting in a very small latency between the source and target data. This also allows Double-Take to run without impacting production applications, as synchronous solutions require that the target data be written before the application can continue.

Array-based solutions are much more expensive than Double-Take and are not heterogeneous, meaning that they support only that one type and/or vendors hardware. Configuration is often more difficult as well requiring a greater learning curve and longer time to deployment. With Double-Take, you can replicated any hardware to any hardware, between vendors, SAN, LAN, NAS, and even between Windows ® OS. This allows for much greater flexibility in making new purchases, when you make them, and the vendor and products you select. With it?

No. Tape backup is still required for archival copies of data in case you need to recover data from past dates. Double-Take augments tape backup by providing a real-time online version of data that can be used for immediate recovery or failover, should an outage occur. Double-Take can also greatly enhance and simplify your current backup strategy by allowing backups to be moved from the production servers to offline servers by backing up a replica of the data. This allows your application servers to dedicate all resources on the applications and not on backup. For branch office support, instead of providing backup hardware and software to each remote location, you can centralize all backup operations by utilizing Double-Take to copy the remote locations data to your main data center where backups can be processed by trained personnel and archived along with all other backup media.

Yes. It provides two levels of real-time, open-file backup. First, it supports real-time transaction- based replication of open files to one or more disks or servers located anywhere on a network. Users do not have to be taken offline or close files in order for the files to be replicated by Double-Take.

Second, it allows third-party tape systems (installed on the secondary server) to concurrently backup the replicated data to tape media while files remain open - allowing users to implement a real-time, fault tolerant server and tape-based backup system

Because Double-Take is a software-based replication system, it does not require identical hardware or dedicated server links. Working with another disk or server located on a LAN or WAN, Double-Take only requires that the secondary server(s) have adequate disk capacity to hold the data being replicated from the primary server. This flexibility provides for solutions such as migrations from one storage media to another, from DAS to a NAS or SAN, from one OS to an upgraded OS, etc.

Yes. Double-Take can be configured to replicate to one or more servers and can also replicate from many servers to a single server. One-to-many replication enables additional data protection and allows for data distribution; the ability to push production data to remote locations. Manyto-one replication allows for the consolidation of many servers replicated data onto a single server. This is very useful when doing centralized or serverless backups.

Yes. Double-Take supports WAN-based replication as well as LAN. As such, Double-Take can be used to replicated data between cities, states, and even countries.

Typical disk mirroring, or duplexing, includes one server or storage array with two identical hard disks; each disk is a mirror image of the other. In this situation, the actual mirroring occurs on a block or track basis - at the disk level. As a result, only whole partitions can be mirrored or duplexed. Mirroring usually requires more data to be transmitted as every change may require an entire disk block to be re-mirrored. With Double-Take, files, directories, and server volumes can be selected for replication to any other Windows server and disk/volume; no need for identical hardware. As Double-Take replicates at the byte-level, transferring only the actual bytes that change, network utilization and impact is minimized as is latency between fully synchronized servers.

Yes. If the primary server fails, users can easily login to the secondary server and continue operations with minimal downtime and data loss. In fact, Double-Take can either automatically or manually have users redirected to the target server the instance the production server fails. Users do not need to make any changes and are likely to not even know there was a failure.

Yes. The failover module runs on the target server and continuously monitors the source servers. Whenever a source server fails, the failover module tells the target server to pick up the failed server?

Yes. Double-Take requires that a small and inconspicuous set of files be installed on each server acting as a source or a target.

No. Windows 2000 and Server 2003 include technologies that can be confused with Double-Take.

Intellimirror ?