For backup strategies to be successful the process has to execute in three areas; backup, recovery, and time.
In my early days of backup design around 25 years ago, I was sure that by this point data would just automatically protect itself or that hardware and software would never fail or corrupt. Of course, today, nothing could be further from the case. The backup process is more complex than ever, and while the chances of failure have been reduced the ramifications of a failure are more severe.
For backup strategies to be successful the process has to successfully execute in three areas; backup, recovery, and time. Backup, of course, is the task of copying data from the source servers to the backup destination. While it is fashionable for marketing people to say that recovery is the most important, I suggest that backup is equally important. If you don't have a good copy of the data secured on another device and, hopefully, another location, you don't have anything to recover. Backup applications have to be able to successfully copy data across a network, accurately capture data from servers or virtual machines that may have active live data, efficiently store that data on a local repository, and have the ability to move that data off-site.
Another key element is how often can these data captures be done. For many applications, traditional once-a-night backup is no longer enough. There is too much data being added or changed in these applications during the business day and a failure in the late afternoon could mean a significant data loss and significant re-keying. If they are protected, transaction logs can help make sure that data is not lost, but the time it takes to replay those logs will impact productivity.
The second phase is recovery. Can you get the data back at all? Most businesses no longer have the time to perform verification of backup jobs. Confidence in your ability to recover then comes from testing. Testing though is a problem of resources and time. As we discuss in our recent article "Virtualization Powered Recovery," modern day recovery systems are leveraging the virtual server infrastructure to be able to recover virtual machines and even complete application stacks into a virtual test sandbox. This allows for a complete recovery test in minutes without requiring additional hardware or software.
The third phase is time. Time is a factor in both backup and recovery. The amount of time it takes to back up an environment and the time it takes to recover a particular VM are both important parts of the equation and are not mutually exclusive. Again, if you don't complete your backups or can't do frequent backups because of your infrastructure or outdated software, it is going to impact both your ability to backup and how long it takes to get back into production in the case of a failure.
The biggest impact in recovery time is the copy process--the time it takes to move a large data set across the network, back to the original server or virtualization host. This copy time can also be reduced by leveraging a virtualized infrastructure. As we discuss in "Backup is All About Recovery Time," appliances are now becoming available that have their own virtual environment on the appliance. In other words you don't even need to be virtualized yet to take advantage of virtualized recovery.
Having their own virtualized environment allows these appliances to backup both physical and virtual servers, but then be able to host those servers in a standalone environment in the case of a failure of server or storage hardware. By hosting the application on the appliance, this provides a temporary resumption of an application without having to copy data, re-install hardware, and re-prepare storage. Instead of recovery in minutes you now have production in minutes.