Резервная копия существует не для того, чтобы создаваться, а для того, чтобы разворачиваться. Между этими двумя вещами разницы больше, чем кажется: система может годами исправно писать архивы, которые невозможно распаковать. Узнают об этом обычно в самый неподходящий момент.
Почему копия может не восстановиться
- Копируется не всё. Классика жанра: бэкапится папка с сайтом, но не база данных. Или база, но не загруженные пользователями файлы. Или всё вместе, кроме конфигурации веб-сервера и сертификатов.
- Архив повреждён. Копирование прервалось, диск сбоил, места не хватило — а система отчиталась «успешно», потому что проверяет только факт запуска задачи, а не результат.
- Копия снята «на живую». База копировалась во время работы, без корректной остановки записи. Файл есть, но внутри он в несогласованном состоянии: половина заказа записана, половина нет.
- Копию некуда развернуть. Архив в порядке, но сервера с нужной версией PHP или базы данных уже не существует. Редкость, но на старых проектах встречается.
- Никто не знает, как разворачивать. Формально всё хорошо, но человек, который это умел, больше здесь не работает.
Что значит «проверить бэкап»
Проверка — это не «посмотреть, что файл на месте» и не «убедиться, что задача выполнилась без ошибок». Это развернуть копию и убедиться, что проект на ней работает.
Честная проверка отвечает на четыре вопроса:
- Разворачивается ли копия вообще?
- Открывается ли проект после разворачивания?
- На месте ли данные — свежие заказы, последние записи, загруженные файлы?
- Сколько времени всё это заняло?
Последний пункт часто пропускают, а он самый практичный. Одно дело знать, что восстановиться можно в принципе. Другое — знать, что это займёт двадцать минут, а не полтора дня.
Как выглядит тестовое восстановление
Разворачивать копию поверх работающего проекта нельзя — это надёжный способ устроить аварию своими руками. Восстановление проверяют в стороне:
- поднимают отдельный временный сервер или контейнер;
- разворачивают туда последнюю копию;
- открывают проект по временному адресу или через локальную подмену адреса, не трогая DNS;
- проверяют главное: открывается ли сайт, на месте ли данные, работает ли вход и оформление заказа;
- записывают время и всё, что пошло не так;
- временный сервер удаляют.
Первая такая проверка почти всегда что-нибудь находит: забытую папку, отсутствующий сертификат, недостающий доступ, недокументированный шаг. В этом и смысл упражнения — узнать про пробелы заранее, а не в день аварии.
Два числа, которые полезно знать
Есть два показателя, и их стоит проговорить обычными словами, без терминов.
Сколько данных мы готовы потерять. Если копии снимаются раз в сутки ночью, а сервер умер вечером, теряется рабочий день. Для сайта-визитки это терпимо. Для магазина — нет.
Сколько времени займёт возвращение к работе. Не «сколько разворачивается архив», а сколько пройдёт от аварии до момента, когда клиенты снова могут оформлять заказы. Сюда входит всё: заметить проблему, принять решение, найти доступы, развернуть, проверить, переключить.
Если оба числа вас устраивают — схема резервного копирования нормальная. Если нет — менять надо не сами бэкапы, а их частоту и способ хранения.
Как часто проверять
Разумный минимум для небольшого проекта — раз в квартал. Плюс обязательно после любого крупного изменения: смены хостинга, обновления движка, подключения нового сервиса.
Полезно вести короткую запись: дата проверки, что разворачивали, сколько заняло, что не сработало. Через год такой список расскажет о состоянии инфраструктуры больше, чем любые автоматические отчёты.
Коротко
Незаметная деталь: почти все, кто терял данные, имели резервные копии. Разница между ними и теми, кто ничего не потерял, — не в наличии бэкапов, а в том, разворачивал ли их кто-нибудь до аварии.
Мы проверяем восстановление у клиентов регулярно и показываем результат: сколько заняло и что пришлось поправить. Это скучная работа, которая один раз в жизни проекта окупает себя целиком.