In this blog post, I’ll approach some issues pertaining to Data Protection | Rapid Recovery virtual standby machines. It is a subject that requires some groundwork to be properly approached. So, without further ado, let’s begin!
Rapid Recovery is a solution that backs up volumes at the block level, meaning the backup results are volume images. These images can be mounted as physical disks for file restore on the Core (backup server) or on any other computer when using the Local Mount Utility application for Rapid Recovery.
Recovering full volumes is more interesting. Data volumes can be restored on spare volumes or raw disks attached to any machine that has the Rapid Recovery agent installed. If the system drive of a crashed protected server needs to be recovered, a bare-metal recovery (BMR) operation is needed. This means the machine needs to first boot from a boot disk, which behaves like an already protected agent, and the system drive is restored the same as a collection of data volumes.
In order to allow the restored machine to boot from the newly created system drive, some changes need to be made at both the driver and partition levels. In most cases, the system drive contains several volumes needed for the boot-up process. For clarification, a modern Windows server system disk hosts at least three dedicated partitions: Unified Extensible Firmware Interface (UEFI), which is kind of a BIOS replacement; System Reserved, which contains essential boot information; and System Volume, aka the C: drive. Taking into consideration that any GUID partition table (GPT) contains a hidden partition (the Microsoft Reserved Partition), you can see that system drives are pretty complex, and restoring such a drive, especially on hardware different from the original one, may be a complex task as well.
Now, what happens if you need to have a server running, but it crashes due to faulty hardware and you don’t have a spare physical server ready for deployment (but you could squeeze in some storage and computing capacity)? That is simple: Export the desired recovery point to a virtual machine (VM). In practice, the process is similar to a BMR or even a data volume restore. The API for the hypervisor creates the VM, Rapid Recovery restores the system volume and any data volumes that may be needed, and then the process is finished by modifying the newly created virtual system drive to allow the VM to boot. Rapid Recovery makes the process simpler by supporting quite a few hypervisors: VMware ESX(i)/vCenter, VMware Workstation, Microsoft Hyper-V and Oracle VirtualBox.
The next logical step is to have a few critical protected servers exported in such a way that, if they fail, a VM (already created as shown above) is prepared to replace them. That is a virtual standby. To accomplish this, a new export is performed after each backup. If the newest backup snapshot was an incremental, meaning that only the data that differs from the previous backup was transferred over the wire, and this new backup is merged with the virtual standby, then the export process will not be resource intensive. If all goes well, the virtual standby is in sync with the newest backup.
It goes without saying that this is a generous, almost seductive concept. If paired with the fact that virtual standby machines can be spun up at the disaster recovery (DR) site (where data is replicated), it means that theoretically, in case of catastrophic failure, it’s possible to recreate the whole local area network at the DR site (or even in the cloud) and have users work remotely with minimal interruptions. Little wonder that virtual standbys are a cornerstone of each DR plan and — I say it based on facts — literally haunt the dreams of many backup administrators.
However, reality being what it is and making it work in our favor requires a lot of planning ahead and sound resource management.
The first statement I feel bound to make before crossing the separation between fact and fiction in the realm of data recovery is that, indeed, virtual standbys are essential to any DR plan. The second (and last) statement is that virtual standby priorities are different from backup priorities. What is critical from a backup standpoint may be irrelevant from a virtual standby standpoint.
To understand, let’s walk through some real-life situations.
The subject is an engineering company that hosts its essential data on an 8TB volume. This volume is hosted on a dedicated high-end storage area network (SAN) attached to a server running Windows Server 2012 R2. Losing that data means that the company would go out of business. There is no doubt that backing up this server and checking its recovery points is a mandatory operation — and that replicating this data either to a DR location or in the cloud should also be mandatory. Archiving the data at regular intervals is a good option, too. This would cost a lot of money, as storage and high-bandwidth WAN pipes do not come cheap, but there’s no way around it. Should this machine be paired with a virtual standby, too? Also consider there are 20–30 more servers of various sizes that need to be backed up, as well.
Let’s take a look at several scenarios:
The examples above have a common denominator. From a backup perspective, critical machines are the ones that contain valuable data. From a virtual standby perspective, the critical machines are those that assure the network infrastructure. Please imagine a more complex example: creating a virtual standby for an Exchange server. It’s evident that such a machine is useless without an operational domain controller and Active Directory DNS. Creating virtual standbys of large machines is counterproductive. In the end, it’s the job of each organization to prepare the best DR strategy specific to its goals. Rapid Recovery offers a lot of flexibility in choosing the best combination of features that allow balancing both performance and costs. Among these, if used properly, virtual standbys have a place that cannot be underestimated.
For more information about the technical aspects of virtual standbys, read the Rapid Recovery User Guide.