• State Suggested Answer
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 13 subscribers
  • Views 1759 views
  • Users 0 members are here
Options
Related

Is there a way to guarantee that backup files have not been changed?

pitodba
over 2 years ago

Is there a way to guarantee that backup files have not been changed after they have been written to the backup storage?

I use @with = checksum in the backup job.

I wondered if the checksum value is saved in the backup so xp_restore_checksumonly will report an error if the backup file is somehow modified, but xp_restore_checksumonly  seems to do nothing.

it just returns a checksum id and file size. And the checksum id does not actually seem to be a checksum result. So I wonder what is the use of that stored procedure.

If anyone knows of a way to store the checksum values, so that I can compare the current checksum values against them to know that there was a modification, I would appreciate it.

Parents
  • 0 over 2 years ago

    Hello pitodba,

    Hope you're doing good Today,

    Check the following link within Quest Documentation about the use of the xp_restore_checksumonly stored procedure --> LiteSpeed for SQL Server 8.9.5 - Installation Guide (quest.com)

    "This procedure generates a checksum of an entire backup file. It can be used to validate that a file has not been corrupted since a previous point in time. This feature does not validate that the backup set is valid, but provides you with a check sum value to validate your files with."

    NOTE: When you restore a backup containing checksum, it is automatically checked. If you do not want to check the checksums during a restore, supply 'NO_CHECKSUM' .

    LiteSpeed for SQL Server 8.9.5 - User Guide (quest.com)

    Additionally, you can use the certutil windows feature in order to compare checksum after backup has been created: certutil -hashfile path-to-your-file MD5

    As a test Example:

    If you create a backup file, use the xp_restore_checksumonly to get and save the Checksum ID as well perform a xp_restore_verifyonly to check if the backup is valid.

    Once you have saved the values from above and checked if the backup is valid, try modifying the backup file and then perform the same operations from above to compare results.

    Unfortunately the checksum value is no stored, it's a value that is calculated 

    Hope this helps.

Reply
  • 0 over 2 years ago

    Hello pitodba,

    Hope you're doing good Today,

    Check the following link within Quest Documentation about the use of the xp_restore_checksumonly stored procedure --> LiteSpeed for SQL Server 8.9.5 - Installation Guide (quest.com)

    "This procedure generates a checksum of an entire backup file. It can be used to validate that a file has not been corrupted since a previous point in time. This feature does not validate that the backup set is valid, but provides you with a check sum value to validate your files with."

    NOTE: When you restore a backup containing checksum, it is automatically checked. If you do not want to check the checksums during a restore, supply 'NO_CHECKSUM' .

    LiteSpeed for SQL Server 8.9.5 - User Guide (quest.com)

    Additionally, you can use the certutil windows feature in order to compare checksum after backup has been created: certutil -hashfile path-to-your-file MD5

    As a test Example:

    If you create a backup file, use the xp_restore_checksumonly to get and save the Checksum ID as well perform a xp_restore_verifyonly to check if the backup is valid.

    Once you have saved the values from above and checked if the backup is valid, try modifying the backup file and then perform the same operations from above to compare results.

    Unfortunately the checksum value is no stored, it's a value that is calculated 

    Hope this helps.

Children
No Data