|   | ![]() |
|
Backup Overview 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 Testing your planOnce a backup plan is devised, it is normally set into stone and then forgotten about. This is the biggest mistake that any DBA can make. Your databases and environment are constantly changing. The backuip plan you had last month might not apply this month. The backup plan could have holes in it that you dont realize. The only way to find and eliminate these problems is by continuous testing. Just as the selection of the products and media used in your backup plan are vital decisions that have a large impact on your ability to recover systems, the investment in a low end server to be used in testing your backup plan is your systems insurance policy. How do you know if a recovery will fit into your time constraints if you do not actually perform a restore? How do you know is your backups are intact if you do not attempt to restore them? How do you know if you can locate your backups unless you actually go through this process? How do you know if that one hour gap where you have no transaction log dump will cause data loss unless you attempt a restore? How do you know if you can even perform the required restore without doing a lot of research into what you need to do? These and many more questions can only be answered one way, by practice. The last thing you want to do is be required to perform your first restore while a system is down, the phone is ringing off the hook, and the CEO is standing over your shoulder wondering when the system will be back online and watching your every move. Youll probably find yourself out of a job very quickly in this case. The server that gets set aside for testing your backups is a lifesaver in this case. This gives you an isolated environment where you can test you backup plan, find any weaknesses, reformulate the backup plan, test it, and also train yourself to do restores under your backup plan. You should be performing at least one restore every single day. This can either be a single database or an entire server. You should restore an entire server at least once per month. This gives you the ability to verify the integrity of your backups on a continuous basis. You also can verify that you have the ability to restore a database without any data loss. Along with this verification comes training. This is the trap many experienced DBAs fall into. The common sentiment is: "Ive done hundreds of restores and dont need to do anymore." This is false. If you can prove that you can restore any database on any server off the top of your head without the need to consult any document, article, or book, then you dont need to do a restore for training purposes. You do still need to do the restores to verif the integrity of yoru backup. The online sales database that your company bases its livelihood on has just crashed. Your company is potentially losing thousands of dollars every hour it is down.
Backup Overview 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
All content on this site, except where noted, represents an original work of Michael R. Hotek and is protected by applicable copyright laws. The SQL Server FAQ is the sole work of Neil Pike. No page, portion of a page, or download may be used for commercial purposes in whole or in part without the express, written permission of the applicable author.