SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Crash and Burn


Crash and Burn

Author
Message
Steve Jones
Steve Jones
SSC Guru
SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)

Group: Administrators
Points: 61915 Visits: 19099
Comments posted to this topic are about the item Crash and Burn

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (85K reputation)SSC Guru (85K reputation)SSC Guru (85K reputation)SSC Guru (85K reputation)SSC Guru (85K reputation)SSC Guru (85K reputation)SSC Guru (85K reputation)SSC Guru (85K reputation)

Group: General Forum Members
Points: 85160 Visits: 41077
Heh... I absolutely agree... all the backups in the world mean squat unless you can restore them. The DBA's a couple of jobs ago went through that. Took 40 people ten days to almost get all the data back. It was a huge mess.

I noticed that Jeff lost the data on the hosting provider... the more I hear about things like this, the more I'm inclined to say keep the cloud... there's too much weather there.
;-)

--Jeff Moden

RBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
bwillsie-842793
bwillsie-842793
SSC-Enthusiastic
SSC-Enthusiastic (153 reputation)SSC-Enthusiastic (153 reputation)SSC-Enthusiastic (153 reputation)SSC-Enthusiastic (153 reputation)SSC-Enthusiastic (153 reputation)SSC-Enthusiastic (153 reputation)SSC-Enthusiastic (153 reputation)SSC-Enthusiastic (153 reputation)

Group: General Forum Members
Points: 153 Visits: 290
Excellent point on checking ability to restore.

I started as IS manager at a company some years back and asked what they had for backup and restore procedures.

The VP of Sales (also their "Techie") promptly informed that they knew they had good backups because they hadn't gotten any error messages on their backup runs for over 6 months.

This was particularly odd to me when I noticed the dust on the backup tape that was in the drive. It looked like it had been in the machine 6 months itself.

A check in the backup logs indicated that last successful run was also over 6 months in the past, due to a dead drive.

We quickly replaced the drive, did backups, and tested restores.

I still haven't figured out how they managed to be so lucky that they made it 6 months without someone wanting at least a minor file restored.
OCTom
OCTom
Hall of Fame
Hall of Fame (3.1K reputation)Hall of Fame (3.1K reputation)Hall of Fame (3.1K reputation)Hall of Fame (3.1K reputation)Hall of Fame (3.1K reputation)Hall of Fame (3.1K reputation)Hall of Fame (3.1K reputation)Hall of Fame (3.1K reputation)

Group: General Forum Members
Points: 3109 Visits: 4152
Trust no one but you with your stuff. You are utlimately responsible.
bwillsie-842793
bwillsie-842793
SSC-Enthusiastic
SSC-Enthusiastic (153 reputation)SSC-Enthusiastic (153 reputation)SSC-Enthusiastic (153 reputation)SSC-Enthusiastic (153 reputation)SSC-Enthusiastic (153 reputation)SSC-Enthusiastic (153 reputation)SSC-Enthusiastic (153 reputation)SSC-Enthusiastic (153 reputation)

Group: General Forum Members
Points: 153 Visits: 290
skjoldtc (12/29/2009)
Trust no one but you with your stuff.


When it comes to my data, I find it hard to even trust myself.

Trust, but verify...
Jon Russell
Jon Russell
SSC-Addicted
SSC-Addicted (497 reputation)SSC-Addicted (497 reputation)SSC-Addicted (497 reputation)SSC-Addicted (497 reputation)SSC-Addicted (497 reputation)SSC-Addicted (497 reputation)SSC-Addicted (497 reputation)SSC-Addicted (497 reputation)

Group: General Forum Members
Points: 497 Visits: 1177
Agreed. Also, practice makes perfect. I perform restores on a regular basis. Not just for rehearsal, but also to refine DR recovery procedures and to confirm that a copy of the latest backup is not corrupt.
bradmcgehee@hotmail.com
bradmcgehee@hotmail.com
SSChasing Mays
SSChasing Mays (616 reputation)SSChasing Mays (616 reputation)SSChasing Mays (616 reputation)SSChasing Mays (616 reputation)SSChasing Mays (616 reputation)SSChasing Mays (616 reputation)SSChasing Mays (616 reputation)SSChasing Mays (616 reputation)

Group: General Forum Members
Points: 616 Visits: 730
In two of the presentations I regularly give, I emphasize the importance of maintaining backups that are restorable, including the need for storing backups offsite and regularly checking to see if backups can be restored. Often, when I say this during presentations, many members of the audience roll their eyes, as if saying to me, "yeah, duh, that's obvious." The reason I include such "obvious" advice in these presentations is because some DBAs don't put this obvious advice into action, and I want to provide a little reminder to them. So, if you attend one of my presentations in the future, and you hear this advice from me, please stand up and shout, "great advice man", so that those DBAs that roll their eyes will know that I'm not the only one who believes in the importance of DBA basics.

Brad M. McGehee
DBA
Daniel Hallam
Daniel Hallam
Valued Member
Valued Member (54 reputation)Valued Member (54 reputation)Valued Member (54 reputation)Valued Member (54 reputation)Valued Member (54 reputation)Valued Member (54 reputation)Valued Member (54 reputation)Valued Member (54 reputation)

Group: General Forum Members
Points: 54 Visits: 398
Last year we had a full test of our disaster recovery plan (always comforting to be part of a company that has one). Mostly went well except that the disk segment replication to our DR site ended up with unsync'd filegroups for our primary db server so we couldn't do the restore, meaning a complete failure in the end.

If it was a real disaster, we would have had to resort to tape backups taking our DR recovery from 3 hours to over 48 hours, and having some data loss.

Always good to make sure a restore works.
markjholmes
markjholmes
SSC Journeyman
SSC Journeyman (87 reputation)SSC Journeyman (87 reputation)SSC Journeyman (87 reputation)SSC Journeyman (87 reputation)SSC Journeyman (87 reputation)SSC Journeyman (87 reputation)SSC Journeyman (87 reputation)SSC Journeyman (87 reputation)

Group: General Forum Members
Points: 87 Visits: 181
I've encountered the rude awakening a few times myself. Once, at a company that had no DBA, just "the SQL boy," a manager issued a DROP TABLE statement by accident on a database in bulk-logged recovery mode. The transaction logs had never been backed up, and were 300GB on 20GB of data. We soon realized that in order to restore last week's backups (because they took so long they were only done on weekends), the 100GB free was insufficient, and needed some creative space management and several days of data transfers on a severely overloaded and badly designed system. They ended up regenerating the missing data over a three week period because it was faster. They didn't lose ALL their customers...
Grant Fritchey
Grant Fritchey
SSC-Dedicated
SSC-Dedicated (39K reputation)SSC-Dedicated (39K reputation)SSC-Dedicated (39K reputation)SSC-Dedicated (39K reputation)SSC-Dedicated (39K reputation)SSC-Dedicated (39K reputation)SSC-Dedicated (39K reputation)SSC-Dedicated (39K reputation)

Group: General Forum Members
Points: 39368 Visits: 32628
Excellent, excellent, excellent post. Nothing is more important than verifying backups, except, verifying that you know how to run a restore. You're absolutely right when you say that backups are no good unless you can restore them, but it goes beyond actually validating that the backup files themselves are valid and accessible. You need to know that you, and any other DBA's in the organization, can actually run a restore, knows how to read the file header, can do a point in time recovery, etc. Practice restoring databases not only validates that the backups are good, but that you're good as well.

----------------------------------------------------
The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood...
Theodore Roosevelt

The Scary DBA
Author of: SQL Server Query Performance Tuning and SQL Server Execution Plans
Product Evangelist for Red Gate Software
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search