DR Testing Why and How to accomplish the most boring thing that will save your ass(ets)

DR testing is good.  It is nice to know you can recover if something bad happens. However, unless testing backups is mandatory (typically through compliance requirements) or automated (using a tool like Unitrends Recovery Assurance ), it tends to fall by the wayside.   In a recent survey, 62% of all respondents admitted to testing their backups once annually or less.  Failing to test often ends with devastating consequences when a company attempts a recovery during an emergency.

IT admins know they should test. Why don’t they?   

Testing take resources.  Unless you have adopted a backup strategy with built-in automated testing capabilities (like Unitrends), testing backups requires resources, both personnel and compute. To complete testing, you need separate testing hardware, or a quick-spin-up testing lab. Using a production environment to test a backup adds heavy risk and diverts compute resources from critical business operations.  Then you need to assign an employee to run the tests and validate the results. All this can add up to a significant financial investment that doesn’t impact the bottom line. (Well, it will in a negative way, but not until it is too late).

Testing requires a plan. To test, you have to know what you are testing and the expected result.  Testing to success for a DR plan that doesn’t exist or is out of date is a losing proposition.

Let’s say you do finally get around to seeing if that backup was successful, what’s your plan for ‘how’? A quick stack of some approaches to testing, starting with the most basic:

• Individual file recovery (data verification)
• Boot a machine
• Mount a database
• Multiple machine spin-up and organized boot
• Application Testing post boot
• Recovery Assurance

If you are performing data verification, that’s a good start, but making sure a file is accessible is not a guarantee that your applications will be back up and running.  Some of the more complex recovery problems are related to inter-machine communication and not file access. It is more desirable to perform application-level validation.  If you are doing Application testing, meaning recovering and verifying your application, that’s great! But do you know if you can meet your service level agreements? Can you verify your Recovery Time Objectives and Recovery Point Objectives? No? That’s why you really need Recovery Assurance for any important workloads and applications.  The workhorse of backup validation that is part of the Unitrends solution.

Overwhelmed? Don’t be.  We’ve got your back.   There is a way to get from zero testing to Recovery Assurance.

First: Figure out where you currently are.  Try this Recovery Confidence tool to get a level set: https://unitrends.typeform.com/to/zCAZ0n

Second: Figure out where you want to be.  This whitepaper covers everything you need to know about DR Testing and gives you a list of steps to take and technology to adopt.

Third: Call Unitrends.  You don’t have to go it alone. We are glad to lend a hand and offer full services to set up your automated testing environment and even automatically validate that you will meet your SLAs.