Doubletake Replication Review

Doubletake has two versions, one that works at the guest operating system level and one that works at the VM host level.  The VM host level version is a new product and something that Doubletake have recently ventured into, the operating system level version of Doubletake is a mature product and sits within the host guest operating system and copies every single file that is written to disk, this is  placed into a queue that is then replicated to a different machine. 

Traditionally this product was used on physical servers where there was a one-to-one ratio of the production server to DR server that would be put in the data centre.  In recent times they have adapted this product to allow for either a physical server or virtual server (it makes no difference as this is an OS aware back-up strategy) to then replicate to a single guest called a virtual recovery assistant that is located on a different host VM in a data centre.  This has a significant advantage as it requires less licensing costs. 

Traditionally, Doubletake would require a licence for both the production server  and the DR server.  With VRA a  licence is required for each source server but only one licences is required for the VRA and if your source servers are virtual then you can buy packs of 5 license. 

 The  virtual recovery assistant works by attaching multiple virtual hard discs for each source server that is being backed up.   if we have two source servers, either  physical or virtual, and each has two hard discs, the virtual recovery assistant will have one operating system, but will have all four hard disks attached to it.  As files are changed on the source server they are placed into a queue on the source server, that then get replicated to the virtual recovery assistant which knows which source server they came from and applies them in the correct order to the associated hard discs.  In the event that we require bringing up a failed server, the virtual recovery assistant will detach the hard discs from the VRA and attach them to the newly created virtual server. 

One of the great advantages about using this technology, is that we are able to actually see the physical files that have been replicated on the VRA as these are mount points to yhr VHD, the disadvantage with this is that in a disaster, we need to have the virtual recovery assistant fully functional as we need to run the proper Doubletake scripts to detach the mount points from the VRA, build the appropriate server and attach the hard discs.  This should not be done as a manual task as this will generally cause the virtual machine to fail. 

One of the great advantages about this product is that it does not require the host (source) to require snapshots.  As the agent works within the guest operating system, it takes advantage of the natural fault tolerance that is designed within many applications.  Furthermore, if we had decided to use snapshotting technologies, we would not have been able to use these during the day as it is not advisable to snapshot on high I/O loads and we would not be utilising the bandwidth we have available during the day and placing all the load on that bandwidth at night.  By being able to replicate to a DR site during the day, this spreads the load across our line over a twenty-four hours period and makes best usage of the available bandwidth without us having to increase it for night usage.  One of the disadvantages of this technology is it is not designed as a back-up technology, purely as a replication. In newer releases, it is expected that there will be a snapshotting technology that can be used on the target server and we will be able to take a minimal number of snapshot.  The disadvantage of this technology is it is  expensive compared to Veeam but it may not be necessary to use it on all production servers.  On servers that have very little change, we would be able to use a different technology  to replicate these in the evening.

The biggest disadvantage with Doubletake, as it is working at the guest level, in the event that a guest server is rebooted, the Doubletake agent is stopped and at this point loses track of any changes that are being made to the server during the reboot.  Because of this, when the server is brought back up, a re-mirror is required.  A re-mirror does not necessarily mean the whole data has to be retransmitted to the replication site as a check sum is taken against each individual file, but if a servers that have a significant amount of data, this re-mirror can take a significant amount of time, sometimes up to a week if you have a lot of small files.  This is not necessarily a problem because while the remirror is taking place, the data is still being replicated. 

http://www.visionsolutions.com/products/vision-products-overview.aspx