Архив появился, но восстановится ли сайт?
Зелёная отметка задания резервного копирования подтверждает лишь завершение определённой операции. Она не отвечает на вопросы: попали ли в копию загрузки пользователей, сохранились ли права, доступен ли ключ расшифровки и запустится ли приложение на другом сервере. Надёжный бэкап проверяется восстановлением конкретного рабочего сценария. Для сайта услуг это как минимум просмотр контента, вход администратора и приём обращения.
Начните с двух договорённостей. RPO определяет допустимую потерю последних изменений во времени, RTO задаёт целевое время возвращения сервиса. Это требования владельца сайта, а не свойства архиватора. Если допустима потеря только небольшой части рабочего дня, одной ночной копии может быть недостаточно. Если восстановление должно быть быстрым, заранее понадобятся доступы, ресурсы и отработанная инструкция.
Определите полный комплект восстановления
Составьте реестр компонентов: код или воспроизводимый релиз, база данных, загруженные файлы, расширения CMS, конфигурация веб-сервера, фоновые задания и описание окружения. Для каждого компонента укажите источник, место резервирования и владельца. Не предполагайте, что папка проекта содержит всё: файлы могут лежать в Docker-томе или объектном хранилище, а настройки CMS в базе.
Секреты требуют отдельного защищённого процесса. В инструкции достаточно указать, как уполномоченный сотрудник получает доступ к хранилищу секретов и ключам. Хранить единственный ключ расшифровки рядом с единственной копией на том же VPS бессмысленно. Отдельно проверьте доступ к домену, DNS и внешним интеграциям: восстановленный сервер без этих зависимостей может остаться недоступным пользователям.
Согласуйте базу и файлы
Для PostgreSQL утилита pg_dump создаёт согласованный экспорт одной базы, но не включает автоматически общие для кластера объекты, например роли. Эти границы описаны в официальной документации pg_dump. Там же различаются текстовый и архивные форматы восстановления. Выбор регулярного резервирования зависит от нагрузки и требований: логический экспорт не заменяет во всех случаях физические копии и восстановление на момент времени.
Согласованность базы не означает согласованность всего сайта. Запись о загруженном документе может попасть в дамп, а сам документ ещё не попасть в файловую копию. Для небольшого проекта предусмотрите согласованное окно без изменений либо другой проверенный механизм синхронизации компонентов. Метод выбирают под приложение; универсального обещания «скопируем папку работающего сервера и всё будет целым» здесь быть не должно.
Каждому комплекту присвойте идентификатор и запишите время, версию приложения, версию базы, состав файлов и результат выполнения. Полезно хранить небольшой манифест с контрольными суммами и количеством объектов. Это помогает обнаружить неполный комплект до аварии. Длительность копирования и восстановленный момент данных фиксируйте отдельно: они отвечают на разные вопросы.
Проверка хранилища не равна проверке приложения
Предусмотрите независимое место хранения и ограничьте полномочия рабочей системы на удаление старых копий. Политику сроков хранения согласуйте до заполнения диска. Нужны не только самые свежие экземпляры: ошибочное изменение иногда обнаруживается спустя время. При этом дополнительные копии содержат те же чувствительные данные и требуют такого же внимания к доступу.
Если используется restic, обычный check и проверка содержимого выполняют разные задачи. Документация restic по целостности поясняет, что для чтения и проверки всех пакетов нужен параметр --read-data. Такая проверка требует времени и передачи данных; её нагрузку учитывают в расписании. Даже успешный результат не доказывает, что восстановленная CMS сможет войти в базу.
Чек-лист учебного восстановления
- Выберите конкретный комплект и запишите начало испытания. Убедитесь, что оператор может получить копию и ключи без доступа к исходному серверу.
- Подготовьте изолированное окружение с отдельной базой, каталогами и адресом. До запуска запретите исходящие письма, платежи, CRM-вызовы и другие рабочие интеграции.
- Проверьте архив и восстановите файлы в новую пустую директорию. Не направляйте учебное восстановление в рабочий каталог сайта.
- Восстановите базу, необходимые роли и расширения, затем проверьте владельцев файлов и соответствие версии приложения схеме данных.
- Откройте несколько типов страниц, старые и новые загрузки, выполните вход с тестовой учётной записью и создайте помеченное обращение.
- Проверьте фоновые задачи в безопасном режиме. Сопоставьте контрольные записи и файлы с манифестом, зафиксируйте ошибки и длительность этапов.
Почему важна пустая директория? В руководстве restic по восстановлению на месте указано, что существующие файлы по умолчанию перезаписываются, а прерывание может оставить частично восстановленное состояние. Учебный прогон не должен превращаться в незапланированное изменение работающего сайта. Перед реальным восстановлением поверх текущих данных также нужен отдельный план и проверенная копия текущего состояния.
Типичные ошибки
Самые неприятные пробелы: копировать только код, забывать загрузки и расширения, проверять лишь размер архива, хранить всё под теми же полномочиями, что у приложения. Другая ошибка возникает на тестовом стенде: восстановленные фоновые задания начинают отправлять настоящие уведомления или повторно создавать карточки CRM. Изоляцию проверяют до старта процессов, а не после первого письма.
Не считайте доступность главной страницы достаточной проверкой. Она может быть статической и не обращаться к базе. И не ограничивайтесь одним удачным испытанием: смена версии базы, появление нового хранилища или изменение авторизации способны сделать прежнюю инструкцию неполной.
Критерии приёмки
Работу можно принимать, когда восстановлен весь заявленный комплект, подтверждены чтение и запись, проверены доступы и файлы, а измеренные сроки укладываются в согласованные цели. Отчёт должен содержать идентификатор копии, восстановленный момент данных, время до готовности сервиса, выполненные проверки и обнаруженные ограничения. Ошибки не скрывают общей отметкой «бэкап работает».
Инструкцию должен суметь выполнить второй уполномоченный сотрудник без устных подсказок автора. Периодичность повторных испытаний выбирают по частоте изменений и риску. Такое восстановление дополняет проверки перед запуском и является самостоятельной задачей эксплуатации инфраструктуры, а не побочным эффектом установки архиватора.
Короткий FAQ
Достаточно ли снимка VPS у провайдера?
Это может быть полезным слоем защиты, но нужно проверить состав, согласованность данных, доступность при потере аккаунта и реальный порядок восстановления.
Можно ли проверять восстановление на рабочем сайте?
Для учебной проверки используйте изолированное окружение. Рабочее восстановление требует согласованного окна, защиты текущих данных и отдельного решения о переключении.
Что важнее: частота копирования или испытания?
Оба параметра. Частота ограничивает возможную потерю новых данных, испытания показывают, что сохранёнными данными действительно можно воспользоваться.