Business Recovery, Step 8: Disaster Recovery Testing
We’ve reached the final article in this 8-step program. Throughout the last 7 articles, I’ve laid the foundation for expanding your backup services to a true recovery offering by establishing the Recovery Time Objectives and Recovery Point Objectives for each critical data set, application, service, or server, and introducing various kinds of recovery services you can provide:
- Virtual Disaster Recovery
- Continuous Recovery
- File Versioning
- File Level Recovery
- Virtual to Virtual Recovery
- Bare Metal Recovery
Remember, the goal in adding these services is to both better protect your customer’s business, as well as to increase your ongoing and services revenue streams.
But, even with these advanced recovery options in place, how do you know they’re really going to work?
In the spirit of adding on services, there is one last service you should be providing with each recovery service to ensure its success: testing.
Disaster Recovery: Testing Not Included
One of the benefits of adding any of the aforementioned services is the requirement to test backups. While data shouldn’t be corrupted, and backups are designed to contain complete data sets, if an application or server is so critical that one of the recovery services above is being used, it makes sense that you need to be certain a given backup set contains enough information to perform a recovery.
The risk around recovery without testing is high, as assumptions around what is included in a backup may not align with the actual data set. For example, you may check the box that says Exchange Server and think it backs up every part of the Exchange server, when, in fact, it only may backup every bit of data related specifically to Exchange (and leave off the OS). Additionally, misunderstandings around the use (and usefulness) of full and incremental backups may place you in a position where recovery is impossible without the correct backup sets.
Since the customer likely has zero expectations around how much testing is needed (only one of my customers ever had recovery testing as part of their operations plan), so this is a bit of greenfield, mixed with logical conclusions based on the importance of what’s being backed up. Let’s break requirements down into five parts:
- Use RTO/RPOs – You need to start with your per-application/server/data RTOs and RPOs to determine how long you really have to recover a given backup (which, in turn, defines how much “practice” you need to make sure it works.)
- Define Testing Frequency – Staying with the per-application/server/data mindset, you have the opportunity to establish with the customer how often recovery testing should occur. The Fax server may only get tested once annually, but email may be tested quarterly.
- Consider the Disaster – You likely are thinking in terms of getting “server X” back up, but you should have the customer thinking about the kinds of disasters (e.g. failures at the OS, hardware, or location level) that may occur.
- Consider the Recovery Environment Needed – remember, some of these recovery methods require as much as a complete cloud-based virtual environment.
- Consider the Recovery Method – Some of these are more concerned with just recovering a database, or an entire OS. In some cases your testing may assume you have a fully functional OS, so you need some way of establishing that in an offline environment to test the recovery.
Once all of these requirements are addressed, you’ll find you have some pretty specific recovery testing scenarios you can use to begin to build predictable testing offerings from.
What’s the benefit?
It’s evident that the end result is regular services revenue. How much really depends on the needs of the customer, and the resulting work you’ll need to perform to test backups based on those needs.
Business Recovery: Lots of Options
To wrap this series up, you have many directions to take a basic backup and recovery service. Recurring monthly revenue streams and frequent services revenue from dependable recovery offerings will not only protect your customer’s business, but the future of your own as well.