sha256sum --check: как проверить целостность резервной копии
Воспроизводимая проверка SHA-256-манифеста: успешная сверка, изменение одного байта, отсутствующий файл, строгий режим и границы — почему совпавший хэш ещё не доказывает восстановимость.
В этой статье
Контрольная сумма отвечает на узкий вопрос: совпадают ли текущие байты файлов с теми, по которым создан манифест. Для набора резервной копии сначала создают backup.sha256, затем запускают sha256sum --check --strict и обязательно проверяют код выхода. Строки OK при коде 0 подтверждают совпадение только перечисленных файлов; восстановимость копии этим не доказана.
Сначала проверим механику на безопасной модели. Два небольших файла изображают дамп каталога товаров и архив медиа. Затем отдельно воспроизводятся изменение одного байта без изменения длины, отсутствие файла и повреждённая строка манифеста. Рабочие данные, службы и сеть не используются.
Входные условия
- Linux с GNU coreutils и утилитой sha256sum.
- Каталог, где имена файлов не меняются между созданием и проверкой манифеста.
- Права чтения всех проверяемых файлов и самого манифеста.
- Отдельное понимание, кто создал манифест и защищён ли он от совместной подмены с архивом.
sha256sum --version
sha256sum (GNU coreutils) 9.4
Проверка выполнена 20 октября 2026 года в изолированном временном каталоге, созданном только для этого теста. catalog.sql.gz занимал 18 байт, media.tar.zst — 17 байт. Расширения учебные: это обычные короткие файлы, а не настоящие SQL-дамп и архив.
Файл | Размер в тесте | Роль |
|---|---|---|
catalog.sql.gz | 18 байт | Учебный дамп каталога |
media.tar.zst | 17 байт | Учебный архив медиа |
backup.sha256 | 2 строки после создания | Манифест ожидаемых хэшей |
Создаём манифест
Перейдите в каталог с подготовленным набором. Путь ниже — заглушка: замените его своим проверенным каталогом, не выполняйте команду из случайной директории.
cd /path/to/backup-set
sha256sum catalog.sql.gz media.tar.zst > backup.sha256
Команда читает файлы и записывает их SHA-256 вместе с именами. Созданный в том же каталоге манифест удобен для проверки примера, но для рабочего процесса этого мало: если злоумышленник или ошибочная задача может одновременно заменить архив и backup.sha256, совпадение не подтвердит происхождение копии.
Первая проверка: все байты совпадают
sha256sum --check --strict backup.sha256
catalog.sql.gz: OK
media.tar.zst: OK
В исходном наборе команда завершилась с кодом 0. Это означает, что обе строки манифеста корректно разобраны, оба файла прочитаны и вычисленные хэши совпали. По одному тексту OK выводить рано: автоматизация должна проверять также код завершения процесса.
Меняем один байт, но сохраняем длину
Следующая команда относится только к учебной копии. Она перезаписывает первый байт catalog.sql.gz и не меняет длину файла.
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
Размер catalog.sql.gz остался 18 байт, но sha256sum завершился с кодом 1. Сравнение только имени, размера и времени изменения могло бы пропустить такой сценарий; манифест проверяет содержимое байт за байтом через вычисленный digest.
Отсутствующий файл и повреждённая строка
Сценарий | Наблюдаемый вывод | Код |
|---|---|---|
media.tar.zst отсутствует | FAILED open or read; listed file could not be read | 1 |
В манифест добавлена not-a-checksum | 1 line is improperly formatted при --strict | 1 |
Оба файла на месте и строки корректны | OK для обоих файлов | 0 |
Эти ошибки имеют разный смысл. Несовпавший digest означает, что файл прочитан, но его байты изменились. FAILED open or read означает, что файл не найден или недоступен для чтения. Неправильная строка относится к структуре манифеста; параметр --strict делает её причиной ненулевого кода выхода.
Где хранить манифест
- Не ограничиваться копией backup.sha256 рядом с теми же архивами и под теми же правами записи.
- Сохранять манифест в журнале задания или отдельном хранилище с ограничением изменения.
- Фиксировать дату, набор файлов, версию процедуры и источник манифеста.
- Для недоверенной передачи добавлять механизм аутентификации: цифровую подпись или MAC по принятой в компании схеме.
- Не публиковать пути, имена и служебные сведения, если они раскрывают внутреннее устройство системы.
Стандарт FIPS 180-4 описывает SHA-256 как алгоритм формирования digest, который помогает обнаружить изменение сообщения. Параметры проверки строк и строгого режима описаны в руководстве GNU Coreutils 9.11. Ни один из этих механизмов сам по себе не подтверждает, что манифест создан доверенной стороной.
Порядок приёмки рабочей копии
Зафиксировать перечень файлов и точку времени; для работающей базы сначала обеспечить согласованный способ создания копии.
Создать манифест после успешного завершения записи файлов и сохранить его в защищённом месте.
Перед передачей или восстановлением запустить sha256sum --check --strict и сохранить код выхода.
При коде 1 разделить несовпадение хэша, отсутствие файла и ошибку формата; не сводить их к общему «бэкап повреждён».
После успешной сверки проверить полноту набора, права, секреты и версии программ.
Восстановить копию в изоляции и выполнить предметную приёмку сервиса.
Контрольная сумма — ранний фильтр, а не финальная приёмка. В отдельном материале разобраны RPO, RTO и тестовое восстановление интернет-магазина. Он продолжает эту проверку на уровне полноты и работоспособности системы.
Что проверка не доказывает
- Что в набор попали все нужные файлы, база, конфигурация и секреты.
- Что дамп работающей базы создан в согласованной точке.
- Что архив можно распаковать и приложение запустится на нужной версии окружения.
- Что манифест подлинный, если его могли заменить вместе с файлами.
- Что копия соответствует требуемым RPO и RTO.
Критерий готовности прост: код 0 подтверждает совпадение перечисленных байтов с сохранённым манифестом; любой код 1 останавливает переход к восстановлению до разбора причины. Даже после кода 0 остаётся отдельная задача — доказать полноту, согласованность и восстановимость копии.
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.
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
Record the list of files and the point in time; for a working database, first ensure a consistent method for creating a copy.
Create the manifest after successful file writing is complete and save it in a secure location.
Before transferring or restoring, run sha256sum --check --strict and save the exit code.
On exit code 1, distinguish between hash mismatch, missing file, and format error; do not lump them into a generic "backup corrupted" message.
After a successful check, verify the completeness of the set, permissions, secrets, and software versions.
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.
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.
Обсуждение 0
Делись опытом и задавай вопросы. Комментарии без ссылок появляются после проверки редактором.
Пока никто не написал. Начни обсуждение.