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:
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.
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:
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.
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.
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.
Get the latest MSP tips, tricks, and ideas sent to your inbox each week.