Payments are experiencing issues due to temporary restrictions in Russia. If your payment does not go through, please submit a support request.Our support team is available 24/7 — we are always here to help with hosting and server issues.We are now accepting requests for dedicated server rental and colocation services in our data center.Reminder: we recommend enabling backups for additional data protection.A new VPS/VDS lineup with NVMe storage and improved performance is now available.Maintenance work on some servers has been completed. All services are operating normally.
Article5 min readViews0

sha256sum --check: how to verify backup integrity

Reproducible SHA-256 manifest verification: successful match, single-byte alteration, missing file, strict mode, and boundaries — why a matching hash does not prove recoverability.

МихаилCommunity author★ 16
Comments 0

Backup storage and archive case on a desktop next to an amber warning lamp
In this article

A checksum answers a narrow question: do the current file bytes match those used to create the manifest? For a backup set, first create backup.sha256, then run sha256sum --check --strict and always check the exit code. OK lines with exit code 0 confirm only the listed files match; this does not prove the backup is recoverable.

First, we test the mechanics on a safe model. Two small files represent a product catalog dump and a media archive. Then, we reproduce a single-byte change without altering length, a missing file, and a corrupted manifest line. No working data, services, or network are used.

Prerequisites

  • Linux with GNU coreutils and the sha256sum utility.
  • A directory where file names do not change between manifest creation and verification.
  • Read permissions for all files being checked and for the manifest itself.
  • Clear understanding of who created the manifest and whether it is protected against joint tampering with the archive.

sha256sum --version

sha256sum (GNU coreutils) 9.4

The check was performed on October 20, 2026, in an isolated temporary directory created solely for this test. catalog.sql.gz was 18 bytes, media.tar.zst was 17 bytes. The extensions are test files: they are ordinary short files, not a real SQL dump or archive.

File

Size in test

Role

catalog.sql.gz

18 bytes

Sample catalog dump

media.tar.zst

17 bytes

Sample media archive

backup.sha256

2 lines after creation

Manifest of expected hashes

Creating the manifest

Navigate to the directory with the prepared set. The path below is a placeholder: replace it with your verified directory; do not execute the command from a random directory.

cd /path/to/backup-set

sha256sum catalog.sql.gz media.tar.zst > backup.sha256

The command reads the files and writes their SHA-256 hashes along with the filenames. The manifest created in the same directory is convenient for verifying the example, but this is insufficient for a production workflow: if an attacker or a faulty task can simultaneously replace the archive and backup.sha256, a match does not confirm the origin of the copy.

First check: all bytes match

sha256sum --check --strict backup.sha256

catalog.sql.gz: OK media.tar.zst: OK

In the original set, the command completed with exit code 0. This means both lines of the manifest were parsed correctly, both files were read, and the computed hashes matched. It is premature to output a single OK text: automation must also verify the process exit code.

Changing one byte while preserving length

The next command applies only to the test copy. It overwrites the first byte of catalog.sql.gz without changing the file length.

printf 'X' | dd of=catalog.sql.gz bs=1 seek=0 conv=notrunc status=none

sha256sum --check --strict backup.sha256

catalog.sql.gz: FAILED media.tar.zst: OK sha256sum: WARNING: 1 computed checksum did NOT match

The catalog.sql.gz file size remained 18 bytes, but sha256sum exited with code 1. Comparing only the name, size, and modification time could have missed this scenario; the manifest verifies content byte by byte via a computed digest.

Missing file and malformed line

Scenario

Observed output

Code

media.tar.zst is missing

FAILED open or read; listed file could not be read

1

not-a-checksum added to the manifest

1 line is improperly formatted with --strict

1

Both files are present and lines are correct

OK for both files

0

These errors have different meanings. A mismatched digest means the file was read, but its bytes changed. FAILED open or read means the file was not found or is unreadable. A malformed line refers to the manifest structure; the --strict parameter causes it to return a non-zero exit code.

Four SHA-256 check results: match, byte change, missing file, and line error
Tutorial test: only the original set exited with code 0; the three deviations returned code 1.

Where to store the manifest

  • Do not limit yourself to a backup.sha256 copy placed next to the same archives with identical write permissions.
  • Store the manifest in a job log or a separate storage with modification restrictions.
  • Record the date, file set, procedure version, and manifest source.
  • For untrusted transfers, add an authentication mechanism: a digital signature or MAC using the company-approved scheme.
  • Do not publish paths, names, or technical details that reveal the system's internal architecture.

The FIPS 180-4 standard describes SHA-256 as an algorithm for generating a digest, which helps detect message changes. Parameters for string verification and strict mode are described in the GNU Coreutils 9.11 guide. Neither of these mechanisms alone confirms that the manifest was created by a trusted party.

Acceptance testing order for the working copy

  1. Record the list of files and the point in time; for a working database, first ensure a consistent method for creating a copy.

  2. Create the manifest after successful file writing is complete and save it in a secure location.

  3. Before transferring or restoring, run sha256sum --check --strict and save the exit code.

  4. On exit code 1, distinguish between hash mismatch, missing file, and format error; do not lump them into a generic "backup corrupted" message.

  5. After a successful check, verify the completeness of the set, permissions, secrets, and software versions.

  6. Restore the copy in isolation and perform domain-specific acceptance testing for the service.

A checksum is an early filter, not final acceptance. A separate article covers RPO, RTO, and test restoration of an online store. It continues this verification at the level of system completeness and operability.

Separating hash verification from backup recovery testing
A hash match confirms the listed bytes; completeness and recoverability are verified separately.

What the check does not prove

  • That the set contains all necessary files, the database, configuration, and secrets.
  • That the dump of the live database was created at a consistent point.
  • That the archive can be unpacked and the application starts on the required environment version.
  • That the manifest is authentic, in case it could be replaced along with the files.
  • That the copy meets the required RPO and RTO.

The readiness criterion is simple: code 0 confirms that the listed bytes match the saved manifest; any code 1 stops the transition to recovery until the cause is analyzed. Even after code 0, a separate task remains to prove the completeness, consistency, and recoverability of the copy.

GENERAL IT

Read more on this topic

Discussion 0

Share your experience and ask questions. Comments without links appear after editorial review.

No comments yet. Start the discussion.