Total System Failure: Why you should validate your database backup


Total System Failure: Why you should validate your database backup

Every now and then things happen that make us realize how important double checking things can be.

I had a recent experience in which four unrelated parties (including me) did the wrong thing regarding one business transaction. If any one of us had done the right thing, there would have been no problem. But all four parties dropped the ball, causing potentially serious problem. This is why it is important to leave nothing to chance. Here is the story.

A few months ago, our health insurance company asked us to send it a report detailing who was on our payroll last year. The following sequence of mistakes turned this simple request into potentially serious problem for our business.

Mistake number 1: I put that request that I received from the insurance company to the side and did not send the report to them by the due date. This would normally be OK, because the insurance company sends out a certified letter in the event that they do not receive the report in time.

But…

Mistake number 2: We have a mailing address and a different physical address. For some inexplicable reason, the insurance company sent out the certified letter to our physical address instead of our mailing address, where they send all other correspondence, and where we would expect important business mail to arrive. This would normally be OK because if we receive mail to our physical address, it will eventually get to our bookkeeper and be addressed.

But…

Mistake number 3: The US Postal service delivered the certified letter notices to wrong suite They delivered it to the neighboring business instead of to us. This happens occasionally. I dont understand why this happens but since most of our mail comes to our mailing address, and our neighbor usually brings our mail over when this happens, it is normally not a problem.

But…

Mistake number 4: For some reason that puzzles me most of all, the neighboring business never bothered to tell me or the mailman that they received two certified letter notices for me over a month ago! While I acknowledge that this party had the least obligation in the transaction, I am shocked at the lack of consideration that they showed.

So, what does all this have to do with your Database?

All four parties involved in the above scenario had a well defined job to do, or at least a well understood and expected course of action. All are trusted parties that usually do what is expected of them. We had every reason to believe that all four parties involved would perform their jobs properly. And yet not one of the parties involved did the right thing.

The same can be true of your disaster recovery processes. Just because you have specified what should happen with your database backup, and who should do it, does not mean it us actually being done!

As I mentioned in an earlier post, when we examine a client’s disaster recovery posture, we find in a large percentage of systems that the backups are not working the way the client thinks they are, and in many cases, they are not working at all!

So be sure to have an independent party validate that you are really as protected as you think you are.

Important Steps to take to validate database backups.

  1. Validate Database Backup Schedules.
  2. Validate that ALL required databases and Schemas are being backed up
  3. Validate that ALL database stored procedures, etc are being backed up
  4. Validate that all external files (such as Oracle control and redo log files and SQL Server transaction logs) are included properly in the backup.
  5. Validate that the database files are placed into a backup-safe state (eg, Hot Backups in Oracle) prior to backing them up.
  6. Perform Test Restores using actual backup files from the nightly production backup routine to ensure that the backups are usable in the event of a disaster.

Bottom line: Validate that your backups really do what you think they are doing, and that they will enable you to recover fully when the inevitable system failure occurs.

Posted on Categories Backup and Recovery, Best Practices, DatabaseTags , ,

Leave a Reply

Your email address will not be published. Required fields are marked *