Резервная копия, которую ни разу не разворачивали, не является резервной копией. Это файл, про который команда надеется, что он рабочий. Разница становится видна в худший момент: диск умер, база повреждена, кто-то выполнил DROP TABLE не в том окружении, и только теперь выясняется, что архив пустой, дамп обрывается на середине, а ключ шифрования остался у уволившегося администратора.
Эта статья о том, как превратить «у нас есть бэкапы» в «мы восстанавливаемся за известное время с известной потерей данных». Это проверяемое утверждение, и его можно проверить самостоятельно.
Зачем тестировать восстановление, если копии создаются каждую ночь
Создание копии и восстановление из неё — два разных процесса, и ломаются они по-разному. Задание на копирование может отрабатывать без ошибок и при этом сохранять не те данные: не ту базу, не тот каталог, базу без таблиц, которые добавили полгода назад в другую схему. Архив может быть целым, но несовместимым с текущей версией сервера. Копия может лежать в хранилище, доступ к которому есть только у одного человека.
Ни одна из этих проблем не видна в журнале задания. Все они видны при попытке восстановиться. Поэтому единственный честный показатель защищённости данных — результат последнего теста восстановления, а не зелёный статус в планировщике.
RPO и RTO простыми словами
Два параметра описывают, что вы готовы потерять при аварии. Их стоит сформулировать до того, как обсуждать инструменты.
- RPO (Recovery Point Objective) — сколько данных во времени допустимо потерять. Если копия делается раз в сутки, после аварии вы вернётесь к состоянию на момент последней копии, и всё, что произошло после, исчезнет. RPO в этом случае равен суткам.
- RTO (Recovery Time Objective) — сколько времени сервис может не работать, пока вы восстанавливаетесь. Это время на поиск копии, разворачивание сервера, загрузку данных, проверку и переключение трафика.
Оба значения должен назвать бизнес, а не инженер. Интернет-магазину потеря заказов за сутки обойдётся дороже, чем внутреннему порталу документов. Когда числа названы, становится ясно, достаточно ли ночного дампа или нужна непрерывная репликация, и что именно проверять.
Пошаговый план проверки
План ниже рассчитан на типичный набор: приложение, PostgreSQL или MySQL, файлы пользователей в объектном хранилище или на диске. Для другого стека шаги те же, меняется содержимое.
- Составьте список того, что должно быть в копии. Базы данных, файлы, конфигурации, секреты, сертификаты, схема инфраструктуры. Сравните со списком того, что копируется на самом деле. Расхождение — первая находка.
- Возьмите последнюю копию из того места, где она хранится. Не с сервера, с которого она делалась, а из хранилища, куда она уезжает. Если для этого нужен доступ, которого нет у дежурного инженера, это вторая находка.
- Разверните чистое окружение. Отдельная виртуальная машина или контейнер с той же версией базы и приложения. Не используйте рабочие серверы: восстановление поверх живых данных — это не тест, а второй инцидент.
- Восстановите данные и засеките время. Время от решения «восстанавливаемся» до работающего приложения — это ваш фактический RTO. Запишите его.
- Проверьте содержимое, а не факт восстановления. Количество строк в ключевых таблицах, последняя запись по времени, открытие нескольких файлов пользователей, вход в приложение, выполнение одного типового сценария. Дамп, который «восстановился», но содержит таблицы без данных, встречается чаще, чем кажется.
- Сравните результат с RPO и RTO. Если восстановление заняло шесть часов, а бизнес назвал один час, у вас есть конкретная задача, а не абстрактная тревога.
- Запишите, что делали. Команды, пути, учётные записи, порядок действий. Это и есть инструкция по восстановлению; её отсутствие — отдельный пункт ниже.
Типовые ошибки, которые находит первый же тест
Копии лежат там же, где данные
Дамп базы в соседнем каталоге на том же диске защищает от случайного удаления таблицы и не защищает ни от чего другого. Отказ диска, компрометация сервера, ошибка оператора с rm -rf уносят и данные, и копию. Как минимум одна копия должна находиться на другом сервере или в другом хранилище, желательно у другого провайдера или в другой зоне.
Дампы PostgreSQL никто не открывал
Задание pg_dump может завершаться с ошибкой прав на одну из таблиц и всё равно выдавать файл. Файл есть, размер похож на правду, а внутри нет нужной схемы. Проверка — только восстановление в отдельную базу и сверка списка таблиц и количества строк. Для больших баз имеет смысл делать это хотя бы выборочно, но регулярно.
Нет инструкции
Восстановление описано в голове одного инженера. Он в отпуске, на больничном или уже не работает в компании. Инструкция должна быть такой, чтобы её выполнил человек, который видит эту систему впервые: откуда взять копию, какими учётными данными, в каком порядке поднимать сервисы, как проверить, что всё работает.
Секреты и конфигурация не входят в копию
База восстановлена, а приложение не запускается: ключ шифрования, переменные окружения, сертификат и конфигурация прокси остались на умершем сервере. Копия должна содержать всё, что нужно для запуска, или инструкция должна точно указывать, где это всё взять.
Хранение не ограничено или ограничено слишком жёстко
В первом случае хранилище растёт, пока не кончатся деньги или место, и тогда задание молча перестаёт работать. Во втором — повреждение данных, которое заметили через две недели, уже невозможно откатить, потому что все копии содержат испорченную версию. Политика хранения должна учитывать, за какое время вы обычно замечаете проблемы.
Как сделать проверку регулярной
Один удачный тест говорит о состоянии дел на вчерашний день. Через полгода добавится новая база, изменится схема, переедет хранилище, и копия снова станет надеждой, а не фактом. Проверка должна стать частью процесса, а не разовым событием.
- Автоматизируйте минимальную проверку после каждого копирования: архив открывается, дамп восстанавливается в отдельную базу, число таблиц и строк в контрольных таблицах не ниже порога. Результат уходит в мониторинг как метрика, а не в лог, который никто не читает.
- Раз в квартал проводите полное восстановление руками по инструкции, желательно силами инженера, который не писал эту инструкцию. Расхождения между текстом и реальностью исправляйте сразу.
- Заведите алерт на отсутствие свежей копии, а не только на ошибку задания. Задание, которое не запустилось, ошибки не выдаёт.
- Пересматривайте RPO и RTO при изменении бизнеса. Сервис, который год назад был вспомогательным, мог стать основным.
На странице мониторинга, резервного копирования и восстановления описано, как мы выстраиваем этот процесс: политика хранения, проверка восстановления и согласование RPO и RTO с требованиями бизнеса.
Что дальше
Если вы не уверены, что ваши копии восстанавливаются, проверка состояния резервного копирования входит в бесплатный экспресс-аудит инфраструктуры за 48 часов: смотрим, что копируется, куда, как хранится и была ли хоть одна проверка восстановления.