Настройка резервного копирования с проверкой восстановления: как убедиться, что бэкап спасёт данные

Успешное задание резервного копирования подтверждает только то, что программа создала некоторый набор данных. Оно ещё не доказывает, что архив читается, в нём есть все зависимости сайта, пароль доступен ответственным сотрудникам, а восстановление уложится в допустимое время. CISA рекомендует хранить критичные копии в защищённом офлайн-контуре и регулярно проверять их доступность и целостность в сценарии аварийного восстановления [1]. Поэтому рабочий процесс заканчивается не сообщением «backup completed», а протоколом тестового запуска сайта из выбранной точки восстановления.

Сначала определить, что именно нужно вернуть

Для сайта резервная копия — это не только каталог с PHP-файлами. В состав могут входить база данных, пользовательские загрузки, конфигурация веб-сервера и PHP, задания cron, переменные окружения, ключи шифрования, сертификаты, правила очередей, конфигурация почты, объектное хранилище и данные внешнего поиска. Часть компонентов можно заново развернуть из кода, но для этого должны сохраниться репозиторий, описание версии окружения и инструкция сборки. До настройки расписания составьте реестр: компонент, место хранения, способ копирования, ответственный и способ проверки после восстановления.

Зафиксировать RPO и RTO

RPO показывает, к какой по давности точке нужно уметь вернуться: он задаёт допустимую потерю последних изменений. RTO описывает допустимую продолжительность восстановления сервиса. NIST связывает RTO со временем, в течение которого компоненты системы могут оставаться в фазе восстановления без неприемлемого влияния на работу организации [2]. Эти цели задают по бизнес-процессам, а не по возможностям выбранной программы. Если каталог товаров можно пересобрать, а заказы нельзя потерять, у них будут разные требования и разные проверки.

Разделить рабочую систему и хранилище копий

Копия на том же VPS полезна перед небольшим изменением, но не защищает от отказа диска, удаления сервера или компрометации административной учётной записи. Хотя бы одна актуальная копия должна находиться вне основной площадки и не быть постоянно доступной теми же реквизитами, которыми управляется сайт. Для наиболее важных точек применяют неизменяемое хранение: например, Object Lock блокирует перезапись или удаление объекта на заданный срок [3]. Это дополнительный слой, а не замена контролю доступа, шифрованию и проверке восстановления.

Пошаговая настройка процесса

1. Проведите инвентаризацию. Отметьте файлы, базы, внешние хранилища, конфигурацию и секреты. Для каждого компонента укажите владельца и зависимые сервисы.
2. Выберите согласованный способ создания копии. Простое копирование файлов работающей базы может дать несогласованное состояние. Используйте штатный дамп СУБД, снапшот с поддерживаемой процедурой остановки записи или механизм резервирования самой платформы.
3. Настройте расписание от RPO. Частота должна быть достаточной для допустимой потери данных. Отдельно задайте срок хранения и несколько точек во времени: одна свежая копия не поможет, если повреждение заметили поздно.
4. Отделите права. Учётная запись сайта не должна уметь удалять всю историю копий. Доступ к чтению, записи, изменению политики хранения и ключам расшифрования разделяют настолько, насколько позволяет инфраструктура.
5. Контролируйте не только код завершения. Проверяйте размер, возраст последней точки, наличие всех частей, свободное место и ошибки выгрузки. Уведомление должно доходить до конкретного ответственного.
6. Подготовьте изолированный стенд. Тестовая копия не должна отправлять клиентские письма, выполнять реальные платежи, обмениваться с продуктивной 1С или конкурировать с рабочим сайтом за домен и очереди.
7. Проведите восстановление по инструкции. Другой специалист должен суметь взять выбранную точку, получить необходимые ключи, развернуть окружение и выполнить контрольные сценарии без устных подсказок автора процесса.

Для «1С-Битрикс» официальная документация отдельно описывает состав архива, варианты размещения, шифрование и работу мастера восстановления. Она также указывает, что локальные копии уязвимы к авариям самого сервера и их следует переносить в другое место [4]. При этом штатный архив не освобождает от проверки модулей, интеграций и серверного окружения конкретного проекта.

Как провести тестовое восстановление

Выберите реальную точку из обычного расписания, а не специально подготовленный архив. Зафиксируйте время начала и ожидаемый результат. Разверните чистую совместимую среду, восстановите файлы и базу, подключите тестовые версии зависимостей. Не меняйте продуктивные DNS-записи и не запускайте внешние задания до изоляции стенда.

После запуска проверьте минимум следующие сценарии:

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

Автоматическая проверка архива полезна как ранний фильтр, но не заменяет развёртывание. Например, Microsoft прямо предупреждает, что RESTORE VERIFYONLY проверяет читаемость и полноту набора SQL Server, но не проверяет структуру данных внутри [5]. Облачные системы резервирования по той же причине предлагают отдельные задания restore testing, которые действительно создают восстановленный ресурс и измеряют продолжительность операции [6].

Что должно остаться после проверки

Результат оформляют как короткий протокол: идентификатор копии, дата данных, состав, стенд, исполнитель, длительность этапов, выполненные сценарии, найденные расхождения и решение по ним. Если RTO превышен, это не повод скрывать тест: нужно уменьшить объём ручных действий, подготовить инфраструктуру как код, изменить схему копирования или честно пересмотреть цель. Инструкция должна храниться отдельно от сервера вместе с контактами, реквизитами доступа и порядком получения ключей.

Типичные ошибки

• копировать только файлы или только базу, не учитывая их согласованность;
• хранить все точки под одной административной учётной записью;
• не контролировать пароль и ключ расшифрования до аварии;
• считать снапшот единственным резервным каналом;
• тестировать восстановление поверх рабочего сайта;
• проверять лишь открытие главной страницы, не затрагивая данные и фоновые процессы;
• не обновлять инструкцию после миграции, смены PHP, СУБД или хранилища.

Источники

[1] CISA — #StopRansomware Guide.

[2] NIST — Recovery Time Objective и SP 800-34 Rev. 1.

[3] Amazon Web Services — S3 Object Lock.

[4] 1С-Битрикс — Резервное копирование и восстановление.

[5] Microsoft Learn — RESTORE VERIFYONLY.

[6] AWS Backup — Restore testing.