Резервное копирование: бэкап, который действительно работает

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

Правило 3-2-1

Классический ориентир, который стоит держать в голове:

• 3 копии данных — рабочая и две резервные.
• 2 разных носителя — не два каталога на одном диске.
• 1 копия вне площадки — в другом дата-центре или у другого провайдера.

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

RPO и RTO: два вопроса перед настройкой

Прежде чем выбирать инструменты, стоит ответить на два вопроса.

RPO (Recovery Point Objective) — сколько данных вы готовы потерять. Если бэкап снимается раз в сутки в три часа ночи, а авария произошла в шесть вечера, потеряется рабочий день. Для сайта-визитки это приемлемо, для интернет-магазина с сотней заказов в день — нет.

RTO (Recovery Time Objective) — сколько времени вы готовы лежать. Восстановление базы на 50 ГБ из сжатого дампа может занять часы. Если допустимый простой — 15 минут, нужна реплика, а не дамп.

Ответы на эти вопросы определяют схему. Без них выбор частоты и способа копирования произволен.

Что именно копировать

Полный бэкап сайта — это не только база:

• База данных. Для PostgreSQL — pg_dump в custom-формате, он поддерживает выборочное восстановление отдельных таблиц.
• Загруженные файлы. Каталог media с изображениями и документами. В отличие от кода, его нет в репозитории — потеря невосполнима.
• Конфигурация. Файлы окружения, конфиги nginx, unit-файлы systemd, задания cron. Именно эта часть теряется чаще всего и восстанавливается по памяти.
• Сертификаты и ключи. Если не выпускаются автоматически.

Код в резервной копии обычно не нужен — он в системе контроля версий. Но убедитесь, что репозиторий не находится на том же сервере, что и сайт.

Глубина хранения

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

Рабочая схема ротации выглядит примерно так:

• ежедневные копии — хранить неделю;
• еженедельные — хранить месяц;
• ежемесячные — хранить год.

Места это занимает немного, особенно при сжатии, а глубина отката получается серьёзной.

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

Ключевая часть, которую пропускают почти все. Регулярно — раз в квартал как минимум — копию нужно разворачивать на тестовом сервере и проверять, что сайт запускается и данные на месте.

Что обычно выясняется на такой проверке:

• дамп базы снимался с ошибкой, а уведомления об этом никто не читал;
• в копии нет каталога media, потому что при настройке его забыли добавить;
• архивы бьются при распаковке — заканчивалось место на диске в момент создания;
• восстановление занимает шесть часов вместо ожидаемых сорока минут;
• резервное копирование остановилось три месяца назад после смены пароля.

Каждый из этих пунктов обнаруживается либо на плановой проверке, либо в момент аварии. Разница в цене существенная.

Мониторинг самого бэкапа

Задание в cron, которое молча перестало работать, — распространённый сценарий. Настройте оповещение не только об ошибке, но и об отсутствии успешного завершения: если за сутки не пришло подтверждение, должно прийти уведомление.

Полезно также отслеживать размер копии. Внезапно уменьшившийся вдвое дамп — верный признак, что что-то пошло не так, даже если код возврата нулевой.

Что в итоге

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