Rethinking Backup Fundamentals

In my last post, I discussed backup redesign, emphasizing the need to begin with an analysis of the basics which include understanding and analyzing RPO and RTO.

The acronyms RTO and RPO used to cause hands to be raised in presentations as they weren’t well understood by our industry. It seems like they have become standard terms in our industry, but let’s define them for completeness.

RPO — this stands for Recovery Point Objective. In the book, “Implementing Backup and Recovery” written by David Little and David Chapa it is defined as “How far back in time you are willing to go to recover.” If you backup once a day at midnight, and you delete a file at 11:59 PM the next day you will have a backup which almost twenty-four hours old. This might be an appropriate objective for a non-critical file server, but most certainly wouldn’t work for the database of an order entry system for an airline. Imagine the chaos that would occur if all the tickets sold by an airline in one day were lost.

Backup professionals normally concern themselves with the most recent backup copy, since in most cases the end user wants that copy of the data restored. However, RPO also applies both to the oldest and/or the number of points in time you might wish to restore from. The interest in older data reflects some of the changing business requirements which are now often reflected in backup retention policies. Enterprises now determine the backup retention strategy and corresponding RPO requirements in the larger scope of business objectives which include data retention requirements from the legal team, legal hold related to legal discovery and the internal and external regulatory environment.

When there are requirements for extremely long retentions, a hard discussion needs to take place with business leaders about what they plan to do with the data in 15 or 25 years once it is restored. You will need to have a plan for dealing with the applications, file formats and systems which will be obsolete museum pieces in 25 years. People also need to be aware of the cost of storing the media and the likely technology refreshes required to move from one media type to another.

Traditionally, some of the objectives above are best serviced by an application designed for archiving like Enterprise Vault.

RTO — this stands for Recovery Time Objective. Little and Chapa define this as “How fast will specific systems/applications be recovered.” From the point where you are notified that a recovery is required, how long will this recovery process take? If you look at our example above, where a critical order entry system needs recovery, the down time where orders can’t be placed has a tangible cost. Each minute the web site is down prevents sales from occurring. There is a cost associated with being able to recover an application in seconds versus hours. One must examine if the cost is reasonable given the criticality of the application.

If you are given the luxury to re-think backup you could go to each application owner and hammer out a specific RPO and RTO objective for every application. If you were to do this, I expect that you would create a matrix of objectives that would equal or exceed the number of applications supported in your organization. In the latest “State of the Data Center 2008” report issued by Symantec the surveyed customers showed that 41% of data centers report supporting a thousand or more applications. Supporting a thousand SLA’s would be difficult at best and a logistical nightmare.

Use a simpler approach — create three to five basic service levels with a well defined RPO/RTO. There will always be exceptions to the rule, but hopefully, this arrangement will result in fewer SLA’s and smoother backup operations.

Tim Burlowski

Technical Product Manager