From time to time, we forget about things, or they become so familiar that we stop paying attention to them. We only notice when they’re gone, like a building that has just been demolished. This happens with disaster recovery too.
Things appear to work, so we leave them to work, while we are busy with other things. DR plans are apparently in order, so we file them away, without noticing how physical or digital dust starts to accumulate on them.
Change happens, for the most part insidiously, but enough to throw disaster recovery procedures out of kilter without our knowing about it. Here are four reminders on these themes about major causes of DR failure to help jog your memory.
- Backup technology failure. Backups of data, including application code and configurations, should be automatic, reliable, and protected from human blunders. In many cases, enterprises achieve one or two of these goals, but not all three. For instance, technology can automatically, reliably, yet wrongly overwrite essential backups, if a human operator issued the wrong instructions.
- Failing to plan. Or rather, failing to keep planning. As Eisenhower said, “The plan is nothing, planning is everything”.
- Failing to test. Meaning, failing to test realistically. Desktop, paper-based tests may be fine as a starting point, but unless you have gone through a real disaster recovery exercise with real data and real systems, you’ll never really know if your plan works.
- Wrongly assuming your IT systems are the same. You’d like them to be the same, because that would make things much simpler. However, your enterprise data storage may now be done in any number of ways, including cloud storage, networked storage, server storage, and critical “stuff” that managers insist on keeping on their PCs or mobile computing devices (yes, it’s that BYOD time again).
Of course, these causes of DR failure are far from being all that could go wrong. But hopefully, by keeping them in mind, you will already significantly raise the chances that your disaster recovery works properly, should you need it.