When is a Backup Considered Successful?

  • Comments posted to this topic are about the item When is a Backup Considered Successful?

  • Hi

    It is a really a good Article for the biginers as like me . and good ideas u have given

    Regards

    ksr

  • Good article.

    You could have carried it a bit further. Including RESTORE VERIFYONLY as a part and parcel of your backup routines adds to the overall confidence you have in your backups. You also didn't mention getting consistency checks in place to run before full backups to ensure what's being backed up is more likely to restore.

    Still, this is important information to get out to people and you made a good start. Well done.

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

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • Good job mentioning the offsite tape testing. It's a good idea to get at least an annual test in the budget and make sure that the time to recovery doesn't increase over time. If it took 14 hours last year and takes 18 hours this year, then you need to analyze what happened in the chain... did someone forget where they had the contact information, were the restore instructions out-of-date because of server changes, etc.

  • Nice article. What good does a backup do if it can't be restored? None. A disaster is not the time to find your backup plan is useless.

    I would also add figuring out the timings so you know how long it will take to get the tapes and do the restore. Let everyone know it so there are no expectations that can't be met. And, test it at the most inconvenient time to see how long it takes to get it from the offsite vendor.

  • Thanks for the value added comments. They're all worth appending into the article.

  • 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

  • Also, it's usually a good idea to run DBCC CHECKDB after restoring databases from backups.

  • not sure about native SQL backups, but with Netbackup you can do page verification during the backup and restore if you have it set up on the database

  • The RedGate backup will also validate the file.

  • 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.

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

  • 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.

  • Things you should be aware of re. RESTORE VERIFYONLY here.

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

    SQL BAK Explorer - read SQL Server backup file details without SQL Server.
    Supports backup files created with SQL Server 2005 up to SQL Server 2017.

  • Thanks for this good article.

    How can i made a restore test process and certify that my restoration is ok ? A sp_helpdb ?

  • 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.

    SQL BAK Explorer - read SQL Server backup file details without SQL Server.
    Supports backup files created with SQL Server 2005 up to SQL Server 2017.

Viewing 15 posts - 1 through 15 (of 18 total)

You must be logged in to reply to this topic. Login to reply