July 9, 2011 at 11:51 am
Comments posted to this topic are about the item Verify a database backup using T-SQL
Thanks & Regards,
Nakul Vachhrajani.
http://nakulvachhrajani.com
Follow me on
Twitter: @sqltwins
July 11, 2011 at 3:29 am
No criticism of the article, but I would argue that the only way to verify a backup properly is to restore it fully and perform the usual checks on the restored database. Assuming of course that you can restore it before the next backup arrives 🙂
July 11, 2011 at 3:39 am
david.wright-948385 (7/11/2011)
No criticism of the article, but I would argue that the only way to verify a backup properly is to restore it fully and perform the usual checks on the restored database. Assuming of course that you can restore it before the next backup arrives 🙂
I completely agree. This script is best used to eliminate I/O issues. If the backup file structure is logically corrupt, no point in even attempting a restore. Once we know that no I/O issues exist, then I am with you on the point that the next step should always be a restore followed by the usual checks.
Thanks & Regards,
Nakul Vachhrajani.
http://nakulvachhrajani.com
Follow me on
Twitter: @sqltwins
July 11, 2011 at 7:11 am
Nakul Vachhrajani (7/11/2011)This script is best used to eliminate I/O issues. If the backup file structure is logically corrupt, no point in even attempting a restore. Once we know that no I/O issues exist, then I am with you on the point that the next step should always be a restore followed by the usual checks.
Using the script RESTORE VERIFYONLY does not eliminate I/O issues or verify the backup file structure. As it states on BOL "RESTORE VERIFYONLY does not attempt to verify the structure of the data contained in the backup volumes". I would think that alone would be it does not eliminate I/O issues.
Even though you are giving it a file to move to, does it actually validate the backup file for I/O consistency? If I give a false path to the MOVE statement you included in your script. It will simply tell me that it cannot use the file path but still gives the message "The backup set on file 1 is valid". If I give it a legit path that does exist it still gives me the same message, "The backup set on file 1 is valid".
How the structure of the data is written during the backup is where your I/O issue can exist, I would think. Following Paul Randal's advice (24p) the best way to confirm your restore is consistent, short of doing an actual restore, is to use VERIFYONLY + WITH CHECKSUM. This will provide a more deeper consistency check on that backup file to see if it is good or not. However you would have to have taken the backup WITH CHECKSUM in order for it to do that check as well.
Shawn Melton
Twitter: @wsmelton
Blog: wsmelton.github.com
Github: wsmelton
May 12, 2016 at 7:28 am
Thanks for the script.
December 21, 2020 at 7:22 am
This was removed by the editor as SPAM
December 31, 2020 at 5:09 am
This reply has been reported for inappropriate content.
every of us holds a completely unique area within the international. you are unique,irrespective of what others say or what you may think. so forget about approximately being replaced. you may’t be.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply