Mistake #4: Not recover-testing your backups
This is a critical deficiency, and it is very common. And, to be truthful, this mistake is not unique to smaller Oracle shops. I’ve been to some larger Oracle shops that also skimp on recovery testing, but I find this to be more common in the smaller shops where resources tend to be spread more thinly.
Disasters happen every day. Even to well-run companies. In the blink of an eye, you could lose it all. Hardware failures, human error, sabotage, natural disasters – no shop can afford to feel immune to these threats. They are real; they are hellish; and I have the sad client stories to prove it.
Can you recover from a disaster? Just because your backup returned a normal completion code or didn’t throw any errors, does that mean can you recover your database? Just because your recovery strategy worked last quarter, does that mean it works now? Is life in the IT arena really that simple? (I wish it were.)
If you aren’t testing your backups, what is the reason? Will that reason seem important in retrospect, if you can’t get your data back when you need it?
Wow, re-reading this entry, I realize that it sounds preachy, almost accusatory. But I feel passionate about this issue. I’ve seen the proverbial wailing and gnashing of teeth when it becomes clear that a complete recovery of a failed production database is not possible. I don’t want this to happen to any of my clients, and, from a purely selfish perspective, I don’t want to witness such desperation again. It’s disturbing.
Can you look your manager in the eye and tell him you are proud of your recovery testing strategy? Can we help you with your strategy? This link will take you to our site, where you can contact us.