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.
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.
Go to the beginning of the Disaster Recovery FAQ Guide