Проверка восстановления бекапа

Бекап, который завершился без ошибок, — еще не бекап, который получится восстановить. Единственное настоящее доказательство — восстановить его. Databasus делает это за вас по расписанию:

берет последний бекап
восстанавливает его во временный контейнер с базой
сверяет восстановленную базу с исходной
удаляет контейнер
сообщает результат

Что такое агент проверки?

Агент проверки — это небольшой бинарник на Go, который вы запускаете на своей машине: подойдет любая со свободными CPU, RAM и диском. Агент регистрируется в Databasus, забирает задачи проверки из очереди, выполняет их локально и отправляет результаты обратно.

Что понадобится

Хост с исходящим HTTPS-доступом к вашему адресу Databasus.
Docker на этом хосте — для каждой задачи агент поднимает временный контейнер базы данных подходящей мажорной версии.
Место на диске под каждую задачу проверки: размер файла бекапа плюс размер базы в несжатом виде плюс запас сверху.
Не меньше 1 ядра CPU и 512 МБ RAM на каждую параллельную задачу.

Почему не хватает контрольных сумм?

Контрольные суммы и коды возврата ловят часть проблем, но другие пропускают полностью:

Контрольные суммы ловят повреждение битов в файле архива, но ничего не говорят о том, полон ли сам дамп и корректен ли он по смыслу.
Код возврата дампа говорит лишь о том, что команда дампа отработала. Он не поймает роль без права чтения на отдельных объектах, отсутствующее расширение на источнике или несовпадение tablespace — а из-за них объекты молча пропускаются или урезаются.
Проверка восстановления реально прогоняет архив через штатный инструмент восстановления СУБД и считает строки в каждой таблице. Это единственная проверка, которая ловит все перечисленное: если бекап не восстановится, вы узнаете об этом заранее, а не во время аварии.

Настройка

Создайте агента в интерфейсе

Откройте Settings → Verification agents и нажмите Create verification agent. Выберите говорящее имя вроде staging-verifier или eu-west-host-1. В следующем диалоге будут показаны токен и ID агента.

Токен показывается ровно один раз — скопируйте его до закрытия диалога. Если позже вы его потеряете, воспользуйтесь действием Rotate token в строке агента, чтобы выпустить новый; старый токен перестанет работать на следующем heartbeat агента. Следующий диалог показывает команды установки под архитектуру вашего сервера — те же команды описаны ниже.

Запустите агента на своем сервере

Зайдите по SSH на машину, которая будет выполнять проверки. Сначала скачайте бинарник агента. Замените https://your-databasus-host на адрес вашего Databasus и поменяйте amd64 на arm64, если у вас ARM-сервер:

curl -L -o verification-agent "https://your-databasus-host/api/v1/system/verification-agent?arch=amd64" \
  && chmod +x verification-agent

Затем запустите агента. ID агента и токен возьмите из диалога с предыдущего шага:

./verification-agent start \
  --databasus-host=https://your-databasus-host \
  --agent-id=<AGENT_ID> \
  --token=<TOKEN> \
  --max-cpu=2 \
  --max-ram-mb=2048 \
  --max-disk-gb=20 \
  --max-concurrent-jobs=1

Команда start демонизирует агента и записывает его флаги в файл databasus-verification.json в рабочем каталоге, так что при последующих перезапусках можно выполнять ./verification-agent start вообще без флагов. Логи пишутся в databasus-verification.log рядом с бинарником.

Адрес Databasus должен начинаться с https://. Обычный HTTP разрешен только с флагом --allow-insecure-http и предназначен для локальных тестов — никогда не выставляйте боевого агента наружу по незашифрованному HTTP.

Четыре флага --max-* — это общие лимиты, а не выделение ресурсов на одну задачу. Агент сообщает их Databasus в каждом heartbeat, и Databasus делит их между разрешенными параллельными задачами. При --max-cpu=2 --max-ram-mb=2048 --max-concurrent-jobs=1 единственная задача получает все 2 CPU и 2 ГБ RAM. При --max-concurrent-jobs=2 каждая задача получает 1 CPU и 1 ГБ. Минимум — 1 CPU и 512 МБ на задачу: если лимитов на этот минимум не хватает, агент сам снизит параллельность. С лимитом диска ошибиться проще всего: каждой задаче нужно место под размер файла бекапа, размер базы в несжатом виде и запас до 5 ГБ сверху, поэтому задайте --max-disk-gb с заметным запасом относительно вашей самой большой базы.

Управление агентом

Тот же бинарник дает четыре подкоманды:

./verification-agent status — показать, запущен ли демон и какие задачи он сейчас выполняет.
./verification-agent stop — остановить демона. Незавершенные проверки отправляются в Databasus как неуспешные и ставятся в очередь заново.
./verification-agent start — перезапустить демона. Флаги запоминаются с первого запуска; после ротации токена передайте --token=<NEW>, чтобы обновить сохраненный токен.
./verification-agent run — работать на переднем плане, а не как демон. Используйте этот режим, когда оборачиваете агента в systemd-юнит или Docker-контейнер: такие супервизоры ожидают, что процесс не уйдет в фон.

На странице Settings у каждой строки агента есть три действия-иконки: снова посмотреть команды установки (без раскрытия токена), ротировать токен и удалить агента. Удаление безопасно: проверки, назначенные этому агенту, возвращаются в очередь, и их подхватит другой агент, если он доступен.

Расписания и уведомления

Проверка восстановления настраивается для каждой базы отдельно. Откройте настройки проверки у базы данных, включите Scheduled verification и выберите интервал.

Варианты интервалов

After backup — самая сильная гарантия: каждый успешный бекап проверяется сразу после завершения.
Hourly, daily, weekly, monthly — выберите периодичность и время суток.
Cron — cron-выражение в UTC для всего, что не покрывают пресеты. Примеры: 0 4 * * 0 (каждое воскресенье в 4:00 UTC) и 0 */6 * * * (каждые шесть часов).

Как очередь обрабатывает "After backup"

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

Ручные запуски

Разовую проверку можно запустить со вкладки Restore verifications у базы данных, не меняя расписание. Это удобно, чтобы выборочно проверить конкретный бекап или прогнать нового агента от начала до конца, прежде чем доверить ему нагрузку по расписанию.

Уведомления

Об успехе и провале можно сообщать через любой канал уведомлений, уже подключенный к базе. Два чекбокса — Verification success и Verification failed — независимы. Большинство команд включает только уведомления о провале, чтобы не утонуть в оповещениях. Как подключить Slack, Microsoft Teams, Discord, почту и другие каналы, описано в документации по уведомлениям.

Чтение результатов

Каждая попытка проверки отображается отдельной строкой на вкладке Restore verifications у базы данных. Статус — один из Pending, Running, Successful, Failed или Canceled. Клик по строке открывает панель с полным таймлайном, кодом возврата восстановления, размером восстановленной базы, числом схем и таблиц и разбивкой числа строк по таблицам. У неуспешных запусков сообщение об ошибке показано в верхней части панели.