Have You Tested Your Backups Lately? Why and How to Make Sure Your BDR Solution Works
A backup and disaster recovery solution is a fundamental part of successful business strategies. This is because a BDR solution protects against all sorts of red-alert scenarios, from natural occurrences to malicious intrusions. They help prevent downtime and give your business a playbook to follow when the worst happens.
However, it’s easy to adopt a philosophy of “set it and forget it.” After all, creating and acquiring resources for the BDR was hard enough, so it’s got to work, right?
The only way to know how strong how effective your BDR can be is by stress testing it. This is always a core aspect of any good BDR plan because it pinpoints any weaknesses. It also gives you an idea of where your BDR is strong, so you know what to focus on for the future.
BDR Testing Basics
There are some foundations to having a good BDR and how often to test it, which we’ll go over here. For instance, it’s worth testing the BDR at least once a year, depending on the complexity of your solution. This should check how easy it is to recover files, how long it takes to do so, how long the process of the BDR is, what associated files are affected, and so on.
From there, you’ll want to test for scenarios that are likely to happen. BDRs are there for the worst case scenario, so don’t undershoot and think only one perimeter network server farm will be affected. Craft a scenario that involves the whole of your company infrastructure. Granted, you can test recovery options in smaller portions, but it’s a good idea to test the recovery company-wide.
Pay Attention to Individual Systems
If you’re restoring files to different systems, check the results. You may find it’s harder with different systems as certain files restore and others don’t.
For instance, if you’re restoring files to hard drives or servers, it’s possible the hardware expects the restored data to be mapped exactly as it was. Any changes in hardware or data (especially in cases of failed hardware) might cause a failure in this data restore. That’s not really a problem you want to encounter in a real scenario, is it?
From here, it’s a matter of testing and testing thoroughly. Check how systems behave after a system restore. Are files transferred correctly? Do apps and programs still function? Are directories as they should be, or did they get jumbled around?
Recovering an entire network infrastructure worth of data can be a taxing process, and no doubt not everything will go according to plan. That’s why it’s so important to examine how effective your BDR is and how attuned your responses are to various stress-test scenarios. Doing so will assure that if indeed the worst possible scenario occurs, your BDR will be ready for it.
Leave a Reply