Over the past two decades, IT departments have had dedicated physical servers per application. Disk storage is associated with each server as direct attached, network attached, or storage area network storage. Software backup applications agents reside on each physical server and each night the changed files associated with each physical server’s associated storage is copied to either tape or disk.
In the physical server world, you back up the data only. In some cases, you may do a complete image-based backup for bare metal restores but the vast majority of backup is data only.
IT data centers are rapidly moving to a virtualized server world using VMWare, Hyper-V, and other hypervisors. The virtual world still uses direct attached storage, network attached storage, or storage area network storage. However, the backup application no longer backs up just the data but rather backs up the entire virtual machine (VM).
A VM includes the guest operating system, the application, all associated system files, and the data. The fact that you are backing up the entire VM changes the way you need to think about backup.
The amount of backup storage is no longer just the data but the entire physical machine including all operating systems, applications, system files, etc. The amount being backed up is much greater than just the physical files. You cannot assume the same amount of backup storage in the virtual world that you were using in the physical server world.
The good news is that there is a benefit to requiring an increase in backup storage. In the past, if a primary server failed for any reason, you would obtain a new server, load the server software or copy an image on to the server, and then restore the most recent data backups to ensure that the most up-to-date data is on the system. In the virtual world, VM backups are typically written to disk. Since the VM is sitting on backup disk, you can simply boot it from the backup system. Simply booting a VM off the backup system changes everything.
If the primary systems fail, you can boot a VM off the backup system and users can continue to work directly off the backup system. Once the hypervisor is used to make the primary systems operational, the user activity is transparently moved back to the primary systems. This is called “VM instant recovery” and allows your recovery time to be minutes versus hours.
If a third-party auditor is auditing your business continuity, you can boot a VM off the backup system in order to demonstrate that you have a working copy of the entire VM, including data. In the past, it was almost impossible to show an auditor that you could recover from a failure. In the VM world, you can simply boot the VM off the backup disk, show the auditor that it is running, and the audit is complete. This is called a “verified” or “sure backup.”
Since VMs are sitting in the backup system, you can also boot the VM, apply a patch, and test to see the impact before rolling it out in the primary virtualized environment. This is a “virtual lab” versus risking the primary environment.
Backing up VMs changes how you recover, how you pass internal audits, and how you test outside of the production environment.
As you can imagine, changing backup from backing up just the data to backing up the entire VM also changes your backup infrastructure and process.
In virtualized environments, the changed storage blocks are tracked by the hypervisor. This is called “changed block tracking” (CBT). The backup application picks up the changed blocks and copies them to the backup storage target. Unlike traditional physical server backup where a full backup is performed every Friday night, in the virtualized world each backup is the changed blocks only.
There are backup window benefits to only backing up changed blocks but there is also risk to keeping only changed block backups. If you retain too many CBT backups, the time to restore is painful. In addition, if a block is damaged or corrupted anywhere in the chain, reconstituting a full backup will fail. Therefore, most vendors recommend that you create a full backup, sometimes called a “synthetic full” backup, at least once per week.
With the need to boot VMs for instant recoveries, boot VMs for auditors, boot VMs to test software changes and updates outside of production, and the need to perform weekly synthetic fulls – disk is required in the virtualized backup world as you cannot boot from tape and you cannot easily read/write with tape.
With CBT, most VM backup applications with a weekly synthetic full will see a storage reduction of 2:1 to as much as 6:1. As the retention period grows, so does the disk storage. With retention periods of four to six copies or greater the amount of disk storage required becomes quite costly very quickly. Therefore, for four to six copies of retention or less, straight disk can be used.
With a larger number of copies, disk-based backup appliances with data deduplication are required. Data deduplication appliances can raise the rate of deduplication in a virtualized environment to as much as 20:1. As a result, far less disk is used, and the cost to store a larger number of copies for retention is far less using dedicated appliances with data deduplication versus using straight disk.
However, when using a disk appliance with data deduplication, there still needs to be a high-speed disk cache in order to store full version VMs in order to be able to boot for many scenarios or to be able to easily perform a synthetic full backup. There are two types of disk-based backup appliances. The first deduplicates the data inline, which means deduplication occurs on the way to disk and therefore only stores deduplicated data. In order to be able to boot a VM, you need to put a straight disk storage cache in front of the appliance in order to have full VMs ready to boot and then have the longer-term deduplicated storage in the appliance. The second type of appliance has both built in to a single integrated appliance. These appliances have a disk cache or “landing zone” in order to maintain the most recent VMs in their full form ready to be booted or restored and then store all the deduplicated data behind that.
Backup has changed from backing up data to backing up complete virtualized machines, ultimately changing how you set up and store backups and how much backup storage is required.