How to Verify Backup File Integrity in Linux

Backup-file checks can detect changes, incomplete transfers and damaged archives before you need the data. This guide explains what common Linux checks prove and why a test restore is still necessary.

Why backup integrity verification matters

A backup job can finish without producing a usable recovery copy. Check its result, the saved files and the restore procedure rather than relying only on a success notification.

Common causes of backup file corruption

Interrupted transfers, storage faults and incomplete backup jobs can damage a copy. A consistent copy also requires a suitable backup method for actively changing applications and databases.

Methods to verify backup file integrity in Linux

Compare a saved checksum

After the backup is complete, work in the folder containing it and create a SHA-256 checksum:

sha256sum importantfile.zip > file.sha256

Transfer the backup and checksum file to the destination. From the destination folder, check:

sha256sum -c file.sha256

OK means the file matches the saved checksum. A failure or unreadable file needs investigation. Preserve the original checksum: generating a new one from a damaged copy cannot detect the earlier damage. A checksum is not a digital signature and does not prove authenticity if both files can be altered.

Check archive readability

For a gzip-compressed tar archive:

gzip -t backup.tar.gz
tar -tzf backup.tar.gz

Read errors and check that expected paths are listed. A successful listing does not validate every file’s contents or prove that the application can be restored.

tar --compare --file=backup.tar compares an uncompressed archive with matching paths in the current filesystem. Differences may reflect legitimate changes since the backup; this is a different check from verifying stored media.

Compare a directory copy

For a file-based backup, replace these paths with the actual source and backup directories:

rsync -aicn /source/ /backup/

-c compares file checksums, -i itemises proposed changes and -n makes this a dry run. Read any reported differences and errors. This does not check extra destination files or create a consistent snapshot of a changing database.

Automating backup verification with cron

Once the checksum check works manually, schedule it under a user who can read the backup and write the log:

0 3 * * * cd /backup && /usr/bin/sha256sum -c file.sha256 >> /backup/backup-verify.log 2>&1

Confirm the actual folder and command path. This example runs at 03:00 in the server’s time zone and verifies the files named in that manifest. Arrange monitoring for failures; writing a log alone does not alert anyone.

Best practices for ensuring backup integrity

Keep a separate protected copy, retain checksums from completed backups and use your backup software’s supported validation tools. Periodically restore into an isolated location and test the recovered application and data. File-integrity checks complement those tests rather than guaranteeing recovery.