The Importance of Validating Backups

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » Article Discussions » Article Discussions by Author » Discuss content posted by Paul Randal » The Importance of Validating Backups

55 posts, Page 1 of 6

1 2 3 4 5 »»»

The Importance of Validating Backups

Rate Topic

Display Mode

Topic Options

Author

Message

Paul Randal

Posted Sunday, September 23, 2012 5:57 PM

SSCommitted

Group: General Forum Members
Last Login: Yesterday @ 4:00 PM
Points: 1,910, Visits: 1,602

Comments posted to this topic are about the item The Importance of Validating Backups

Paul Randal
CEO, SQLskills.com: Check out SQLskills online training!
Blog:www.SQLskills.com/blogs/paul Twitter: @PaulRandal
SQL MVP, Microsoft RD, Contributing Editor of TechNet Magazine
Author of DBCC CHECKDB/repair (and other Storage Engine) code of SQL Server 2005

Post #1363312

Divine Flame

Posted Monday, September 24, 2012 2:40 AM

Ten Centuries

Group: General Forum Members
Last Login: Yesterday @ 5:48 AM
Points: 1,076, Visits: 1,922

Thanks Paul for writing such a nice article & clarifying the importance of "WITH CHECKSUM" option when taking the backups! Smile

- Divine Flame

Post #1363365

mohammed moinudheen

Posted Monday, September 24, 2012 3:21 AM

SSCrazy

Group: General Forum Members
Last Login: Yesterday @ 7:43 PM
Points: 2,174, Visits: 3,586

Great stuff as usual by the SQL legend Smile

Mohammed Moinudheen

Post #1363378

Paul Brewer

Posted Monday, September 24, 2012 3:32 AM

Valued Member

Group: General Forum Members
Last Login: Yesterday @ 8:51 AM
Points: 54, Visits: 618

Post #1363380

Gazareth

Posted Monday, September 24, 2012 3:57 AM

UDP Broadcaster

Group: General Forum Members
Last Login: Monday, May 20, 2013 1:53 AM
Points: 1,474, Visits: 2,342

Paul Brewer (9/24/2012)

cannot cope with databases with more than 1 data file at the moment.

Hi Paul,
Been working on a similar script myself - I use RESTORE FILELISTONLY to get the data files & also to generate the MOVE statements.

Happy to send you over some code, although it'll probably need modifying to fit your process.
My starting point is the backup files themselves, rather than msdb database.

Cheers
Gaz

Post #1363393

Grant Fritchey

Posted Monday, September 24, 2012 3:59 AM

SSChampion

Group: General Forum Members
Last Login: Today @ 3:41 AM
Points: 13,383, Visits: 25,189

Well you know I loved this article. I've been ranting about this issue for quite some time. It's nice to have yet another resource to point to in order to try to get the point across. Thanks Paul.

----------------------------------------------------
"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 2012 Query Performance Tuning
SQL Server 2008 Query Performance Tuning Distilled
and
SQL Server Execution Plans

Product Evangelist for Red Gate Software

Post #1363394

Gazareth

Posted Monday, September 24, 2012 4:10 AM

UDP Broadcaster

Group: General Forum Members
Last Login: Monday, May 20, 2013 1:53 AM
Points: 1,474, Visits: 2,342

Yes, thanks for the article Paul.

Is there actually an easy way to check the output from DBCC CHECKDB?
I currently scan the SQL log using xp_readerrorlog for the DBCC output info, another way is to use TABLERESULTS clause, and check for the completion line.
However, both methods could be called undocumented - you won't find either in BOL!

Post #1363400

charles.wong

Posted Monday, September 24, 2012 4:32 AM

Forum Newbie

Group: General Forum Members
Last Login: Yesterday @ 10:36 AM
Points: 3, Visits: 17

Great article.

Is it possible to use DBCC CHECKDB to check the database first before backing up (with all your other recommendations), so that we don't have to restore the backup to perform that test?

Post #1363405

cfradenburg

Posted Monday, September 24, 2012 6:13 AM

SSCommitted

Group: General Forum Members
Last Login: Thursday, May 16, 2013 7:44 AM
Points: 1,559, Visits: 1,925

I recently talked my boss into getting a drive big enough to restore all of our DBs so we can pull them from tape and do tests on a few each week. Now just comes the job of automating that which is likely to be very fun. It would also appear that we need to do some work to secure our backups a little better.

charles.wong (9/24/2012)

You can run CHECKDB first but there's no guarantee that the DB doesn't get corrupt before the backup is done. It also won't guarantee that the backup file itself doesn't get corrupted. Some people recommend doing an integrity check and if the DB is corrupt not to back it up (assuming that this means you may be deleting the last good backup.) Our process here is to backup the database since we send the backups to another location so we shouldn't be destroying a good backup. It also means that we have a copy of the corrupt DB so if we need to restore we can then do some comparisons to try and recover some of the changes. The thing you need to be careful of is making sure you're not destroying the last good backup because then you have a problem.

Post #1363441

Paul Randal

Posted Monday, September 24, 2012 6:29 AM

SSCommitted

Group: General Forum Members
Last Login: Yesterday @ 4:00 PM
Points: 1,910, Visits: 1,602

Glad you all like the article!

Some of the questions:
1) If you can run CHECKDB on the prod system, go for it. But also do the backup/copy/restore/CHECKDB process too. Defense in depth - just like with security.
2) Did CHECKDB complete and find errors? Check the value of @@ERROR afterwards - guarantees to be non-zero if CHECKDB found/had a problem.

Cheers

Paul Randal
CEO, SQLskills.com: Check out SQLskills online training!
Blog:www.SQLskills.com/blogs/paul Twitter: @PaulRandal
SQL MVP, Microsoft RD, Contributing Editor of TechNet Magazine
Author of DBCC CHECKDB/repair (and other Storage Engine) code of SQL Server 2005

Post #1363450

« Prev Topic | Next Topic »

55 posts, Page 1 of 6

1 2 3 4 5 »»»

Permissions