Assuming that your backup is good and you have a viable copy of data, the first challenge when recovering a failed application is the time required to transfer data across the network to the destination. Part of this time is eliminated by virtualization itself. You no longer need to find another server and configure it -- simply move the copy of the virtual machine (VM) back into place. In my opinion, this is all the justification needed to virtualize even the smallest data center.
While virtualization makes it easier to know what to transfer, transferring that VM can still take some time, depending on its size and the speed of the network. Software developers have stepped in with in-place recovery solutions that allow the VM to run from the backup storage area (typically a disk backup appliance).
[ Improved technology and falling costs are resulting in more VDI projects. Read more at Is Storage Saving Virtual Desktop Infrastructure? ]
That means that within moments of a failure, a VM can be returned to operation without the need to wait for data to be transferred across the network. Executing backups from the backup appliance, however, could benefit from a second look at how the disk backup appliance is designed.
In a recent article I discussed how disk backup systems need to be able to respond to the changing state of backup. Thanks to the widespread use of incremental or changed block backups in VM data protection applications, backups happen more frequently and with much smaller files than in the past. Also, these backup appliances now may actually host a VM for a period of time.
A second development is the concept of changed block recovery. Similar to changed block backups, changed block recovery restores only the data needed to make a VM look like it did prior to the failure. This type of recovery applies if, for example, the VM has failed due to data corruption, where the physical hardware (storage and server) are operational. Since most studies on the subject of downtime point to software rather than hardware as the primary cause, this is a common occurrence.
With a changed block recovery capability, the backup administrator can select from within the backup application a version of the VM that exists prior to the time of the corruption. The changed block recovery technology in the backup software would then recover only the blocks of data that had changed since that point in time, cutting the amount of data to be transferred significantly.
Changed block recovery is particularly important for backup products that leverage the cloud as a potential backup destination, as discussed in this article. While capabilities like compression and deduplication help tremendously with cloud-based backup, they have limited value in cloud-based restores. Changed block recovery can leverage what is already in place at your site -- i.e., data that does not need to be updated -- and recover only the data impacted by changes.
Recovery has changed, and so have users' expectations. Most users these days don't expect to ever be down -- and if there is an outage, they don't expect it to last for long. Thanks to modern hardware and software, their expectations can be met, and in some cases exceeded.
Attend Interop Las Vegas May 6-10 and learn the emerging trends in information risk management and security. Use Priority Code MPIWK by March 22 to save an additional $200 off the early bird discount on All Access and Conference Passes. Join us in Las Vegas for access to 125+ workshops and conference classes, 300+ exhibiting companies, and the latest technology. Register today!
