Eight reasons to test your data backups and disaster recovery plan
Cars, electronic goods and software are just three types of products that manufacturers check for quality before they’re put “in production.” Imagine what might happen if companies didn’t test their products before buyers try them!
The same logic applies to computer backups and disaster recovery (DR) plans. Or at least it should. Organizations must design and plan their backups to cover all their important systems. Yet many companies still “test” (i.e. use) their backups and DR plans for the first time during an actual recovery, after a malware attack, hardware failure or other disastrous event that cuts off their access to important systems, applications and data.
The short-sighted nature of skipping tests ought to be self-evident. If it isn’t, the following reasons definitely spell out the importance of making sure backups and DR work before you actually need them.
Gain trust in a system
Once a backup plan and system has been implemented, it must be tested immediately. The sooner any shortcomings are found and addressed, the more likely it is that backups will serve their intended purpose.
It’s normal to discover flaws in design or missed details after implementation. But people sometimes are surprised. The dependability of traditional consumer-grade backup and disaster recovery systems can mislead business leaders into believing that enterprise backups work just as well “out of the box.” In fact, the more complex the computing environment, the more customized the backup processes and DR plans must be and the less likely it is that a solution works properly when it’s first implemented.
Regularly scheduled (or surprise) tests provide ongoing confirmation of the effectiveness of backup and DR plans. The time to learn that a backup disk is faulty or a file is corrupted is NOT when the data it’s supposed to store is required!
Make sure the plans fit the business environment
Are all servers covered? What about data created on notebook computers or mobile devices? Does the backup plan retain data far enough in the past to ensure the organization meets regulatory requirements? Do backups make the organization “e-discovery ready” should litigation arise? These are just some of the questions organizations must ask when they test their backup and DR plans.
Gain understanding of the DR process
Once IT professionals do practice runs, they understand how the DR plan works. They will also gain the confidence to tackle any “This is not a drill!” scenarios.
Learn how to work with parties involved in DR
When a DR team tests the plan, members learn how to work with each other. They can also collaborate on changing the DR plan whenever updates are needed.
Determine a reasonable recovery time objective (RTO)
RTO is the amount of time a system or data can be unavailable before a business suffers material consequences. Those consequences usually mean the business starts to lose money.
Should a system go offline, people will ask how long it will take to bring back online. Timing a test recovery effort gives an approximate answer to that question. Timing specific phases of the process helps IT staff identify potential pinch points in the process and re-shape up-to-date RTO estimates during the recovery process.
If tests reveal that the RTO is inadequate, changes can be made in the plan, the systems or elsewhere to achieve an acceptable RTO.
Keep plans consistent with the current computing environment
Organizations regularly implement new systems, replace old ones, add users to their computing environments, retire old systems and take other actions that affect current backup and DR plans, even potentially rendering them obsolete.
Once updated, they must be tested again against the current environment.
Organizations can also schedule periodic tests to detect changes and possible issues that might fly under the radar.
Enable offline testing of changes to a DR plan
Once backups exist, copies of those backups can be used in virtual machines to test changes to the DR plan without affecting production environments.
Such “offline testing” helps organizations do things like reduce RTO and incorporate changes to the backup and DR plan, all without hampering daily operations or taxing production environments.
Successful tests cost less than the consequences of unsuccessful recoveries
Losing data that organizations use to serve internal users, customers, or both can result in a variety of negative consequences like: litigation, lost business, and the negative impacts on cash flow such events cause. Any one of these consequences will likely cost less than the time required for regular testing of backups and DR plan
We understand the importance of making sure backup processes and disaster recovery plans work properly before they’re needed. Want to know more? Contact us. We care about this stuff and we’ll gladly answer your questions.
Leave a Reply