Бэкап, который никто не восстанавливал, бэкапом не считается: три инструмента недели

На одной неделе вышли три новости про резервные копии PostgreSQL и релиз Camunda, и все четыре об одном: копия, которую никто не разворачивал, защитой не считается. Я веду серверы заказчиков с 2022 года и думаю так же. Владельцу бизнеса из всего этого нужен один вопрос к подрядчику: когда копию базы последний раз восстанавливали и сколько это заняло.

Что вышло

PostgreSQL News 22 октября опубликовали анонс BackupDrill. Инструмент снимает pg_dump с базы в Supabase, кладёт архив в ваш S3-совместимый bucket с контрольной суммой, а потом командой backupdrill drill разворачивает последнюю копию в одноразовый контейнер PostgreSQL и проверяет: архив цел, pg_restore завершился, индексы и ограничения созданы, все таблицы на месте, а те, где были данные, не пустые. Время восстановления записывается. CLI под лицензией MIT, есть платный сервис по расписанию с бесплатным планом. Пока только для Supabase.

В тот же день там же вышел SafeGrd для PostgreSQL 13 и новее. Демон стоит рядом с базой, подключается ролью только на чтение, шифрует копию ключом age ещё на вашем хосте и пишет в S3 bucket с Object Lock. Проверку они называют Fire Drill: копию либо проигрывают в памяти и сверяют число таблиц, строк и колонок с тем, что записано при снятии, либо восстанавливают в песочницу, и там можно добавить свои SQL-проверки. Каждая проверка оставляет подписанную запись, и записи связаны в цепочку. Бесплатный план на одну базу: копия раз в день, проверка в памяти раз в неделю; платные от $15 в месяц.

Чуть раньше, 18 октября, вышел pgBackRest 2.60.0. Главное изменение в поведении: восстановление теперь останавливается с ошибкой, если в восстановленном файле неверная контрольная сумма страницы, а команда expire откажется удалять старые копии, если самая старая из оставшихся содержит такие ошибки. Отключается это опцией checksum-page-error=n.

Camunda 19 октября описала восстановление кластера в версии 8.10 Self-Managed. Раньше брокеры останавливали, чистили каталоги руками и запускали отдельное приложение; теперь это несколько вызовов REST API: перевести кластер в режим RECOVERING, восстановить хранилище, вызвать POST /v2/restore с ID копии. Мне понравилась их формулировка: план восстановления, который никто не выполнял, не план, а оценка. Они предлагают раз в квартал разворачивать ночную копию в кластер, от которого никто не зависит, и засекать время.

Зачем это бизнесу

Возьмём сервисную компанию, у которой в базе заявки, сметы и история звонков за четыре года. Подрядчик говорит: «бэкапы делаются каждую ночь». В понедельник диск виртуальной машины умирает. Копии есть, но последняя рабочая оказывается трёхнедельной давности: задание копирования месяц назад начало падать на одной таблице, и этого никто не видел. Три недели заявок восстанавливают по почте и по памяти менеджеров.

Гарантию даёт только восстановление, которое кто-то сделал недавно, на отдельной машине, и после которого посчитал строки в главных таблицах. Все четыре новости недели про то, как поставить этот шаг в расписание.

Как это устроено у меня

Почти во всех моих проектах стоит MariaDB, а не PostgreSQL, поэтому BackupDrill и SafeGrd мне напрямую не подходят, и у себя я их не проверял. Принцип тот же, инструменты свои.

С PDR-компанией в США я работаю с 2021 года. В 2022-м я развернул для неё сервер на Debian в Google Cloud и с тех пор веду его сам: сервер, VPN, сетевое оборудование и телефонию. У системы несколько контуров защиты и резервных копий. С 2022 года серьёзных сбоев с восстановлением не было. Удачей я это не считаю: копии есть, и я знаю, что из них поднимается.

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

На сервере студии, где работает сервис «Кофе вместе», база SQLite лежит в Docker volume. Сервер общий, с 2 ГБ памяти, поэтому проверять копию там удобно так: контейнер поднимается рядом, читает копию и гасится. Цифр по времени восстановления я не публикую.

Что я бы сделал

Спросить у подрядчика, где лежат копии и как давно одну из них разворачивали. Ответ «они делаются автоматически» не считается.

Назначить день. Раз в месяц копия разворачивается в отдельный контейнер, и кто-то сверяет число строк в трёх-пяти главных таблицах: заявки, клиенты, документы. Как у SafeGrd, можно добавить свои запросы вроде «сколько сделок без клиента».

Засечь время от решения «восстанавливаем» до рабочей системы. Это ваш реальный срок восстановления. Сравните его с тем, что записано в договоре.

Хранить копии не там, где база. Отдельный bucket или другой сервер, и чтобы удалить их нельзя было тем же ключом, которым пишут. Object Lock у SafeGrd для этого и нужен.

Записывать результат: дата, кто проверял, сколько заняло, что не сошлось. Через год по этим записям видно, растёт ли база быстрее, чем план восстановления.

О том, зачем системе общий центр с данными и как он должен переживать сбои, я писал в статье Сервер: данные, доступ и выполнение процесса, а подход к эксплуатации собран на странице инфраструктура, которую можно выпускать и восстанавливать. Кейсы: технический партнёр PDR-компании и сервер и сеть гидропонной фермы. По той же теме: как я проверяю серверы, когда мир латает критическую дыру и что я доверил бы AI-дежурному на одном сервере. Раньше я писал, что копия становится защитой после проверенного восстановления и что срок хранения деплоев должен совпадать с планом восстановления. Если не знаете, восстановится ли ваша база, опишите, где она стоит: Обсудить задачу.