• 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