It's amazing when a product doesn't have the bare minimum features required for a given market, but it happens....
This tip is a brief attempt to determine table stakes in the nascent disaster recovery as a service market.
In the traditional sense, one might think of what off-site tape vaulting companies do as disaster recovery as a service (DRaaS), but that is definitely not the case. Disaster recovery as a service providers must do much more than supply your data when it is needed after a disaster; they must supply your applications in such a way that they can be used immediately by your employees. This is accomplished with a backup that stores your data in the DRaaS vendor's cloud, which may be the vendor's own cloud or its service running in a public cloud. One quick way to lower the number of vendors you need to evaluate is to make sure they support all of the virtual and physical platforms that you use in your environment.
'R' is for recovery
An important question to ask is how the backup vendor stores your data. Is it stored in a traditional backup format, which requires your data to be restored to a VM before it can be used? Or is it stored in a native format that allows the backup to be mounted as your production site in the case of disaster? There are plenty of disaster recovery as a service providers that offer the latter service.
Choosing a backup format that requires a restore will only add downtime to a very difficult situation if you actually have to declare a disaster. Make sure that the vendor's ability to bring your environment online meets your recovery time objective (RTO). Also make sure that they are backing up frequently enough to meet your recovery point objectives (RPOs).
Speaking of which, it's one thing for disaster recovery as a service providers to be able to spin up a VM in a disaster. It's more challenging to spin up dozens or hundreds of VMs. You need to make sure your vendor is capable of concurrently running the number of VMs you plan to use. You should also subdivide your environment into different recovery groups that are recovered together, and some servers/VMs should be able to exist in multiple recovery groups. If that is not possible, you will have to put some servers (e.g. Active Directory) in their own recovery group that is always started following any disaster.
One reason for having multiple recovery groups is to allow you to recover parts of your infrastructure without having to recover the entire thing. Another reason for this is to ensure, through frequent testing, that a given recovery group has everything it needs to be brought online in a disaster. For example, you can't bring your Exchange server online without your Active Directory server. If there is a VM that provides file sharing services to other VMs, it must also be online prior to any recovery.
Making the decision
The best DRaaS products allow you to define a recovery group and bring that entire group online with a single command or the press of a button. This allows for frequent testing, as the recovery process itself is quite simple. Some DRaaS companies even allow for automated testing, where certain recovery groups can automatically be brought online and tested as often as you would like.
Use this checklist of must-haves to evaluate disaster recovery as a service providers:
- They support the types of servers and applications you use.
- They can recover your environment fast enough (RTO) and you won't lose more data than you find acceptable (RPO).
- They allow you to group parts of your environment together into recovery groups and it is easy to bring such groups online in a single step -- without necessarily bringing anything else online.
- They allow you to test all of this on a regular, automated basis.
If you can do all of these things, you picked the right vendor.
A guide explores the rise of DRaaS
Hyper-converged customers can use DRaaS-like services
Choosing between large and small providers for DRaaS