Some say it’s possible to recover servers into the cloud so quickly – and perform in the cloud so well – no one will even notice that a recovery happened. But one should definitely not assume this will be the case with all disaster recovery as a service (DRaaS) vendors. Let’s take a look at the recovery speed and performance speed of DRaaS.
A disaster recovery needs to perform several operations, only one of which is restoring the data. The VM in the cloud needs to believe it is the server it is taking the place for, and computers connecting to it need to believe that as well. Clients connecting to the recovered VM will do so via its hostname, which means DNS records will need updating. In addition, you may need to create a VPN between those using the recovered server and the cloud in which it is running. Each of these things takes time, but IT can prepare for all of them in advance.
The time it takes to restore the server and its data will vary greatly depending on the technology the DRaaS vendor uses. For example, some vendors may store their backups in backup format, and need to perform a restore of the VM as the first step in a recovery. This takes much longer than an instant recovery from live data or recovery on the backup storage itself. It the provider needs to move data from one storage system to another then the size of the data the system is recovering matters.
Instant recovery uses a ready-to-go VM image when a disaster strikes. The most common way to do this is to store data in its native format, so the recovered VM can run directly from the backups. The disadvantage of this method is data in backup format typically does not have the same performance as a native volume.
Another instant recovery method is to have two sets of images: the backup image and its associated history, and a ready-to-go VM that is continually updated from the backup image. This method has performance advantages, because the performance of the recovered VM can be exactly the same as any other VM in the cloud. The disadvantage is that it requires extra storage.
One way to get around this limitation is to store the backup in object storage, and then continually update a VM image that sits on block storage. That way the cost penalty of having two copies is minimized by having one of them on much less expensive object storage.
The DRaaS vendor must also prepare for the other recovery tasks. They should anticipate any changes in DNS and any VPNs that need to exist, and automate the process of making those changes. Waiting until the disaster to make those changes would make things take much longer.
If the VMs have the proper size, and the connection is of sufficient bandwidth and latency, users may indeed detect very little difference between the performance of their original system and the performance of the recovered system. DRaaS vendors may – at the request of the customer – use flash-based storage for the recovery VM. They can also opt for a dedicated server for performance reasons. Each of these decisions will come at a cost, but will provide the customer much better performance during a recovery.
There are a number of architectural decisions that DRaaS vendors can make that will drastically impact the speed of a disaster recovery. The only way to do it seamlessly is to make sure there is a VM image ready to go in the event of a disaster. As mentioned in this article, that VM image may be mounted directly from the backup, or may be an image that is continually updated from the backup. Either method will provide a quick enough recovery, but the latter method will definitely provide better performance once the recovery has been initiated. In addition, VMs and cloud storage comes in many performance levels, and decisions made up front can make significant differences in performance once the recovery is initiated.
Sponsored by Quorum