Ночной cron завершился с exit 0, файл появился в хранилище, dashboard позеленел. При восстановлении схема загрузилась наполовину и упала на оборванном дампе. По данным Captain Pragmatic, 34% компаний не могут вернуть все данные из бэкапа, когда они понадобились.
Задача дежурного — не убедиться, что backup job создал файл. Нужно без остановки продакшена доказать, что из этого файла поднимется база, а приложение сможет читать и записывать данные. Для этого проверку делят на четыре уровня: файл, схема, данные, приложение.
Если пайплайн ещё не настроен, начни с бэкапов PostgreSQL в S3 и проверки восстановления. Если файлы уже пишутся, проверь, насколько далеко твоя автоматика проходит по цепочке восстановления.
Целый файл — только первый уровень
После каждого бэкапа проверь наличие файла, ожидаемый размер и checksum. Отдельный ежечасный sweep должен находить пропущенные файлы, оборванные загрузки и повреждения в object storage; такая проверка занимает секунды.
Хеш отвечает на узкий вопрос: совпадают ли записанные байты с ожидаемыми. Он не проверяет DDL, ключ шифрования, совместимость collation и способность приложения запуститься на восстановленной базе (stackharbor.com; remote-backups.com).
В Proxmox Backup Server эту работу выполняет verify job. PBS перечитывает сохранённые чанки, заново считает SHA-256 и помечает чанк повреждённым, если новый хеш не совпал с сохранённым.
Verify job создаётся через proxmox-backup-manager verify-job; расписание принимает systemd calendar или cron-подобное выражение. Для больших datastore пригодится --outdated-after: параметр повторно проверяет чанки, которые не проходили верификацию заданное число дней. --ignore-verified пропускает уже проверенные данные.
Запускай verify после backup job и следи за Task Log либо метриками PBS для Prometheus. Проверка читает datastore и не затрагивает live-систему, но создаёт нагрузку на хранилище.
Даже чистый verify log не доказывает, что VM загрузится. Он подтверждает целостность чанков — и только её.
Следующая проверка должна загрузить схему
Каждый день поднимай scratch-базу и восстанавливай в неё только схему. Для PostgreSQL команда выглядит так:
createdb backup_verify
pg_restore --schema-only --dbname=backup_verify backup.dumpДля MySQL загрузи schema.sql, для MongoDB запусти mongorestore --dryRun. Такая проверка занимает от 2 до 10 минут и находит оборванный хвост дампа, неподдерживаемый DDL, а также конфликт charset или collation.
Scratch-среде нужны отдельные database server и storage. Продакшен для этой проверки останавливать не требуется.
Схема восстановилась — значит, дамп хотя бы разбирается инструментом restore. Сохранность строк и индексов этот тест ещё не подтверждает.
Раз в неделю загружай данные и сверяй результат
Полный restore в scratch-базу проверяет следующий участок цепочки. После загрузки сравни число строк в критичных таблицах, наличие индексов и время контрольных запросов. Такой прогон занимает от 10 до 60 минут — срок зависит от размера и нагрузки базы.
Сохрани ожидаемые таблицы и контрольные запросы рядом с кодом инфраструктуры. Тогда удалённая таблица или забытая миграция сломают тест, а не останутся незамеченными до аварии.
При сравнении учитывай момент снимка. Расхождение до 0,1% на горячей OLTP-таблице может появиться между созданием бэкапа и проверкой; разница в 30% указывает на испорченный бэкап либо ошибку в самом сравнении.
Строки могут загрузиться, а индекс — нет. Если контрольный индексный запрос после восстановления работает более чем втрое дольше эталона, считай проверку проваленной и разбирай план выполнения.
Рабочий restore подтверждает приложение
Последний тест запускает приложение с восстановленной базой. Прогони критичный сценарий: авторизация, чтение существующей записи, создание новой, изменение и повторное чтение. Только такой тест показывает, пригоден ли бэкап для штатных операций приложения.
Полный drill требует CPU, временного диска и отдельного сервера базы. На него закладывают от 30 до 120 минут. Сокращённый сценарий запускают ежемесячно, полный — раз в квартал для каждой критичной VM или базы (stackharbor.com; remote-backups.com).
Не превращай drill в ручную инструкцию на двадцать страниц. Автоматизируй подготовку scratch-среды, restore и проверки. Человеку оставь решение: принять результат или остановить пайплайн и открыть инцидент.
Расписание проверки бэкапов
Поставь проверки по глубине и стоимости:
- После каждого бэкапа проверь файл, размер и checksum. Ежечасно ищи пропуски и оборванные загрузки.
- Ежедневно восстанавливай схему в scratch-базу.
- Еженедельно загружай данные, сверяй строки и запускай контрольные индексные запросы.
- Ежемесячно поднимай приложение и прогоняй критичный сценарий чтения и записи.
- Ежеквартально проводи полный restore drill с замером фактического времени восстановления.
Бэкап становится рабочим не после exit 0 и не после совпадения SHA-256. Его статус определяет последняя успешно пройденная проверка восстановления. Если приложение на восстановленных данных не запускалось три месяца, у тебя есть непроверенный файл, а не доказанный путь возврата в строй.
