A disaster recovery test evaluates your business continuity and disaster recovery plans to ensure they are functional and efficient in the event of a disaster. It’s critical to test your disaster recovery plan on a regular basis to ensure critical applications and operations continue operating after an interruption of service.
There are three major areas to focus on:
- Communications recovery
- Data recovery
- Application recovery
Most businesses have IT personnel to assist them with their disaster recovery planning and testing. But sometimes, IT personnel will cheat to speed up and simplify the process of testing or to show successful results.
These are the the top 4 ways your IT personnel may be cheating:
Saving A Copy
Your IT personnel may copy server data onto their hard drive, an external drive, or a once-only tape. If the disaster recovery test fails, they’ll have their backup handy to ensure the test appears successful. In a real disaster, backup data wouldn’t be available. This type of cheating also sets up your business for a potential security breach if the data is unencrypted and stored on their hardware.
Migrating Servers From Physical to Virtual
IT personnel can migrate servers ahead of time from physical to virtual, then bring them up as virtual machines during the test, instead of restoring servers. This approach is much less time consuming and difficult compared to restoring physical servers, often decreasing recovery time by 8-10 hours. They might miss problems with the physical servers when using this method of cheating.
Getting Information From An Outside Contact
During a disaster recovery test, your IT personnel may discover a missing file or faulty aspect of the plan, and they make a call to an outside contact to transfer the file to them. This will be impossible in a real disaster situation.
Recovering The “Easy” Systems
If your company has a mainframe and end users access data via a middleware application instead of accessing the mainframe directly, make sure you IT personnel test the ability to leverage data directly from the mainframe. Often, IT personnel will focus on bringing up the middleware application and and not the mainframe. In a real disaster, leveraging data directly from the mainframe might be necessary.
Ask your current IT personnel for details regarding the disaster recovery test, such as steps they’ve taken to ensure your communications, data, and applications are recoverable. If they try to “simplify” or “speed up” the test, hire new IT personnel or hire an outside IT provider to conduct a thorough test.
To learn more about disaster recovery planning and testing, give us a call or send us an email. We can help you develop a reliable disaster recovery plan and conduct thorough ongoing disaster planning tests.
