Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12

When is a Backup Considered Successful? Expand / Collapse
Author
Message
Posted Monday, June 8, 2009 4:50 PM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 10:21 AM
Points: 5,886, Visits: 13,042
SQL Noob (6/8/2009)
there is a constant tape/disk battle here and i've used both. i'll take tape any day over disk.

in the last 9 years i've seen less than 5 tapes go bad over time. in the same time i've seen servers and disk systems die a lot more often. and with disk if the disk dies than all backups on the disk are gone.

we backup all of our SQL to tape via netbackup and the database agents. works very nice. for periodic restores we do them to QA and once in a while we call back tapes from offsite and restore them as well


I think most people would prefer to backup to disk and then copy that backup to tape. Either way you want an on-site and an off-site copy.


---------------------------------------------------------------------

Post #731024
Posted Monday, June 8, 2009 7:11 PM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Tuesday, November 11, 2014 2:57 PM
Points: 202, Visits: 392
All good ideas. A full onsite and offsite process should be developed, documented and implemented, including testing. And not just for the database, but for the entire application(s).

depending on the business nature of the database, the size, and any reporting needs, I setup a report server where I can both test the backups automatically, and build reporting databases.



The more you are prepared, the less you need it.
Post #731068
Posted Tuesday, June 9, 2009 12:21 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Friday, September 26, 2014 12:57 AM
Points: 343, Visits: 1,520
Things you should be aware of re. RESTORE VERIFYONLY here.

Verifying SQL Server backup files on a file server on a budget here.


Ray Mond
Yohz Software
Providing SQL Server database tools for 9 years and counting.
http://www.yohz.com
Post #731159
Posted Tuesday, June 9, 2009 12:24 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Friday, February 5, 2010 1:12 AM
Points: 14, Visits: 135
Thanks for this good article.
How can i made a restore test process and certify that my restoration is ok ? A sp_helpdb ?
Post #731162
Posted Tuesday, June 9, 2009 12:38 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Friday, September 26, 2014 12:57 AM
Points: 343, Visits: 1,520
Use DBCC CHECKDB. Preferably before the backup too. If after the restore, DBCC CHECKDB returns consistency errors, you can at least tell if the error was because the database was inconsistent to start with, or because the backup file was damaged between the time of backup and restore. Without a DBCC CHECKDB before the backup, you can't tell.

Or if using SQL 2005 or later, using the CHECKSUM option during the backup process will also cause SQL Server to verify page checksums where present. Not as informative as DBCC CHECKDB, but still checks the consistency of your data.


Ray Mond
Yohz Software
Providing SQL Server database tools for 9 years and counting.
http://www.yohz.com
Post #731169
Posted Tuesday, June 9, 2009 7:17 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, November 26, 2013 8:14 AM
Points: 134, Visits: 165
I don't have to worry about this because at my company we have a separate Disaster Recovery location with twin servers for all our production servers. I transfer and restore the weekly Full backups to the DR SQL servers. Every other day of the week, I transfer and restore Differential backups. Therefore, if there's ever a problem with restoring any of the backups, I'll know right away! So far, I haven't seen any issues. Typically, SQL Server backs up DBs reliably.
Post #731418
Posted Tuesday, June 9, 2009 8:38 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Wednesday, November 12, 2014 1:00 PM
Points: 12, Visits: 208
very good article. it helps dba to streamline the backup and recovery process. thanks
Post #731496
Posted Tuesday, June 9, 2009 11:40 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, June 9, 2009 11:38 AM
Points: 1, Visits: 0
Great article with considerations that should be obvious, but are good reminders.

Kathy Miranda
InStock, Inc.
www.instockinc.com
Post #731735
Posted Friday, June 12, 2009 5:19 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Wednesday, November 12, 2014 4:52 PM
Points: 67, Visits: 447
Great article! I will use it to uncover flaws in the back-up procedure at the various companies I perform regulare DBA tasks, as most of it not only applies to database back-ups but also to file back-ups as well. Thank you for all those sweet reminders.
Post #733701
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse