June 16, 2013 at 9:33 pm
Comments posted to this topic are about the item Losing Data
June 17, 2013 at 1:03 am
This is why I love the Ola Hallengren backup solution - set it for all user databases and you know that anything developers create will get backed up even if you're on holiday.
June 17, 2013 at 2:09 am
You have no backup until you have proven that the restore works. 😎
June 17, 2013 at 8:05 am
You could even add the creation of the self-invite to a meeting to the script.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
June 17, 2013 at 8:07 am
I agree completely, we should have not excuses to "forget" backing up a database. I have to admit, I have done that exact same thing in the past and we get busy and plan to get it done "tomorrow" and tomorrow gets here and we're busy with others tasks. It is difficult to keep an eye on everything. We are using virtual machines and our network guy has scheduled some snapshots of our system and at least once a day it runs throught each database and makes a backup. In addition to that, I also have scheduled backup scripts. It may sound too redundant but we have the means and we would hate to loose any data. I think we have a good balance. Team work it's important, it's true that DBAs are responsible for db backups but it doesn't hurt to have another team member watching your back too.
June 17, 2013 at 4:21 pm
Excellent on all points, backup and test the backup. And monitor that it keeps happening. Check after events happen like scheduled down time, new hardware installations etc. Assume nothing and secure everything you can. And in reality a little healthy paranoia can be helpful here.
🙂
Not all gray hairs are Dinosaurs!
June 17, 2013 at 5:55 pm
Miles Neale (6/17/2013)
... And monitor that it keeps happening. ....
The script I use to create the backup plan also includes steps to setup the e-mail system and attach notification to the backup job(s).
It never hurts to have that come in.
----------------
Jim P.
A little bit of this and a little byte of that can cause bloatware.
June 18, 2013 at 1:24 am
One other reason to setup back-ups immediately and (performance) monitoring as soon as possible has to do with another phenomena: When a new version is released under time pressure, things are more likely to go wrong or cause trouble because testing in a production-like environment is usualy very time consuming.
Even without any problematic changes in the database itself, changes are bigger that a piece of newly developed or sligtly adjusted code will have a dramatic impact on query performance, cause deadlocks or corrupts the data in ways that could have been avoided with proper constraints if there had have been more time to implement and test them thoroughly.
One last additional advice: NEVER forget to back-up the database BEFORE you deploy a new version of the software. No matter how much you are in a hurry, you will always regret it when you can not restore the previous version. Too often it is needed when something goes wrong, just to make a side-by-side comparison, or to rerun the upgrade scripts when it gets stuck because some 'small' changes were made by hand in the test environment.
See you at the next upgrade!
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply