Как проверить целостность бэкапа и правильно оценить результат

Файл бэкапа скачался, а панель показала успешный запуск — этого недостаточно, чтобы считать копию целой. Сверьте её с заранее сохранённой контрольной суммой, выполните проверку формата и убедитесь, что прочитаны все данные выбранного комплекта.

Совпадение суммы подтверждает сохранность байтов относительно эталона, но не полноту исходной копии и не работоспособность сайта. Если надёжного эталона нет, сегодняшняя сумма станет точкой отсчёта для будущих сравнений, а прошлую целостность придётся оценивать другими проверками.

1. Зафиксируйте, какой комплект проверяете

Дождитесь завершения резервирования: файл, в который ещё идёт запись, не подходит для сравнения. Запишите идентификатор задания, время с часовым поясом, имена объектов и ожидаемый состав — например, архив файлов и дамп базы.

Размер и дата помогают заметить подозрительное отличие, но одинаковый размер не означает одинаковое содержимое. Не смешивайте файлы разных запусков: каждый может быть целым отдельно, а комплект — несогласованным.

Проверяйте копию из того хранилища, откуда собираетесь восстанавливаться. Проверка временного архива на сервере до загрузки не подтверждает состояние удалённой версии. Не размещайте архив и список сумм в публичном каталоге сайта.

2. Сравните SHA-256 с доверенным эталоном

Контрольная сумма — короткое значение, вычисленное по содержимому файла. Эталон нужно получать после успешного завершения создания копии и сохранять защищённо; при проверке хранилища заново читают сохранённый объект и сравнивают результат.

Пример для отдельного каталога завершённого комплекта в Linux с GNU Coreutils:

sha256sum files.tar.gz database.sql.gz > SHA256SUMS

Это создание эталона, а не проверка уже имеющегося повреждения. Перенесите оба файла и список сумм в хранилище; позже в каталоге скачанного комплекта выполните:

sha256sum --check SHA256SUMS

Режим проверки заново вычисляет суммы перечисленных файлов. Смотрите результат каждого файла и итоговый код завершения: строка OK для одного объекта не подтверждает весь комплект. Синтаксис и назначение SHA-2 описаны в документации GNU Coreutils.

Если сумму впервые вычислили после повреждения, она точно описывает уже повреждённый файл. Если злоумышленник может заменить и архив, и эталон, простое совпадение не доказывает подлинность: нужны отдельно защищённый манифест или проверяемая подпись. Сам список сумм также должен охватывать все ожидаемые объекты, иначе пропущенный дамп останется незамеченным.

3. Проверьте формат и полное чтение

Для gzip-файла предусмотрен режим тестирования:

gzip -t files.tar.gz
gzip -t database.sql.gz

Он проверяет целостность сжатого потока без записи распакованного файла. Назначение -t и коды завершения приведены в руководстве GNU gzip: отсутствие текста в терминале само по себе не является протоколом успеха.

Успех gzip-теста не подтверждает корректность SQL внутри или наличие всех каталогов сайта. Просмотр списка имён тоже не доказывает, что каждый файл можно прочитать до конца. Следующий уровень — чтение всего содержимого или распаковка в отдельный закрытый каталог с достаточным местом, без запуска восстановленного приложения и без перезаписи оригинала.

Для дедуплицированного хранилища используйте штатную проверку своей системы. Например, в Borg 1.x проверка метаданных архива и криптографическая проверка содержимого различаются: полный проход данных требует --verify-data, читает, расшифровывает и распаковывает данные. Сверьте режим и область проверки с руководством установленной версии Borg; быстрый или частичный проход не выдавайте за полный.

Полное чтение занимает ресурсы диска, сети и процессора. Выбирайте окно с учётом нагрузки и проверяйте доступность ключа расшифровки через защищённый процесс. Остановленный проход фиксируйте как незавершённый, даже если до остановки ошибок не было.

4. Разберите несовпадение, сохранив исходную копию

Не пересчитывайте эталон поверх прежнего и не удаляйте подозрительный архив. Сначала определите, на каком участке возникло расхождение:

1. Не совпадает скачанный файл. Повторите загрузку в другой каталог и сравните обе версии с тем же эталоном.
2. Расхождение повторяется. Проверьте, выбран ли тот же объект и его версия, завершилась ли загрузка в хранилище, нет ли ошибок чтения.
3. Сумма совпала, тест формата провалился. Возможно, повреждённый поток был сохранён ещё до создания эталона; изучите журнал исходного задания.
4. Чтение прошло, состав неполный. Уточните правила включения и исключения файлов, наличие дампа и зависимых частей цепочки резервирования.

Автоматическое «исправление» репозитория не равнозначно восстановлению данных. В Borg режим --repair может привести к дополнительной потере, поэтому не включайте его только ради зелёного статуса; сначала сохраните исходное состояние и разберите причину по документации.

5. Запишите границы результата

В протоколе укажите комплект, источник эталона, инструмент и версию, охват проверки, время, код завершения и ошибки. Формулировка «суммы совпали, сжатые потоки проверены полностью» точнее, чем «бэкап исправен».

Даже такой результат не подтверждает свежесть заказов, согласованность базы с файлами, совместимость окружения или возможность запустить сайт. Следующий самостоятельный этап — пробное восстановление бэкапа на изолированном стенде.

Web-Puls может наблюдать за доступностью публичного сайта после реального восстановления, но HTTP-проверка не читает резервные копии и не подтверждает их целостность.

Если проверка выявила повреждение и нужен безопасный план восстановления, отправьте заявку на профессиональную поддержку. Укажите публичный адрес сайта, формат копии и обезличенное сообщение ошибки: специалист оценит задачу и предложит формат работ; архивы, ключи и пароли в форму передавать не нужно.