You could answer that with one word really, and I would have to say "testing." Just "testing." Whatever you do when you're protecting data, whether it's a backup, whether it's replication, whatever it is, make sure that you test what you put in place. Just because the vendor's glossy ad said that the product allows you to restore "virtually in seconds," I wouldn't necessarily take their word for it.
It's a question of being prepared. You have all this beautiful technology, you have all these storage tiers, you have these recovery schemes, you've done everything the right way -- but unless you test all of this on a regular basis, you will always run the risk that it will not work when you need it the most.
Once, I saw a database that was replicated after the production database became corrupt. And, because of a planning glitch, poor documentation or human error, the corrupted copy of the database was restored over the good copy. So, they ended up with two corrupted database copies. It goes to show that documentation, planning and of course testing -- making sure everything works -- is really important.
Many times you will ask clients when you walk into an environment: "How are your backups?"
"Oh our backups are fine -- run every night; successful completion every night."
The next question usually is: "Did you try restoring from all this?"
"Umm. Well, we do the occasional file restore."
That's very common, so test, test, test.
Listen to Pierre's answer to this question or download the entire Disaster recovery FAQ audiocast.
Go to the beginning of the Disaster Recovery FAQ Guide
