The Latest Unitrends News
Product and Solution Information, Press Releases, Announcements
VG Tuesday Tips: DR Testing - Why and How to Accomplish the Most Boring Thing That Will Save Your Ass(ets)
June 05, 2018 By VG.Admin
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, 66% of all respondents admitted to testing their backups once per quarter 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.
Original post from Unitrends.