Резервная копия и пробное восстановление

Откат работает, пока сохранённый выпуск и сервер доступны. Если потерян диск или доступ к аккаунту, ссылка на r1 уже не помогает. Резервная копия нужна для иной задачи: восстановить необходимые файлы и настройки в новом месте. В этом уроке составим такой набор и разберём пробное восстановление, которое не затрагивает действующий сайт.

У release-lab пока только статическое содержимое. Базы и загруженных посетителями файлов нет. Это удобное начало, но даже здесь копия одного index.html недостаточна. Понадобятся публичные материалы, ресурсы, паспорта, выбранный выпуск и конфигурация его обслуживания. Позднее дополним модель постоянными данными и согласованием их состояния.

Состав определяет задача восстановления

Представим потерю учебного VPS. Из Git можно заново получить Markdown и шаблоны, однако на другом компьютере могут отличаться зависимости генератора. Сохранённый артефакт позволяет вернуть уже известный результат быстрее. Конфигурация Nginx объясняет тип ответа старого .php, обработку 404 и корень. Сведения о домене и сертификате помогают восстановить окружение, но закрытые ключи и пароли требуют отдельного защищённого хранения.

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

Копия файлов на учебном VPS

Неизменяемые каталоги выпусков удобно архивировать отдельно. Ниже будущий издатель сохраняет releases, а не всю систему. Каталог назначения предварительно создают с ограниченным доступом; он расположен вне корней веб-сервера. Дата в имени обозначает выбранный момент, но в отчёте нужно записать фактическое время успешного создания и выбранные выпуски.

tar -czf /var/backups/release-lab/static-2026-10-10.tgz \
  -C /srv/release-lab releases
tar -tzf /var/backups/release-lab/static-2026-10-10.tgz

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

Если файлы меняются во время создания архива, его содержимое может отражать разные моменты. Наши выпуски неизменяемы, поэтому это упрощает согласованность. Но логи и будущий shared не обладают этим свойством. Их нельзя автоматически объявить согласованной копией приложения после обычного архивирования. Для динамических данных предусмотрим соответствующий механизм, а в текущей копии явно укажем, что сохранялась только статическая часть.

Описание выбранного состояния

Запишите значение current и идентификатор паспорта. Сама символическая ссылка может быть абсолютной: после восстановления в другом каталоге она всё ещё укажет на прежний путь. Поэтому пробная среда не должна слепо использовать восстановленный current. Мы архивируем каталоги выпусков, а для восстановления выбираем конкретное публичное дерево в новом корне. Это делает процедуру понятной и не связывает её с существованием старого сервера.

Учебный паспорт копии
Сохранённые выпуски: r1, r2
Действующий при создании: r1
Публичный корень для восстановления: releases/r1/public
Отдельно: конфигурация Nginx и сведения о TLS
Пользовательские данные: в этом этапе отсутствуют

Слово «отдельно» означает, что эти материалы действительно должны попасть в согласованное хранилище. Просто перечень желаемых файлов не завершает создание копии. Если конфигурация содержит секреты, её доступ и шифрование отличаются от доступа к публичным HTML. Операторы также должны знать, кто имеет право расшифровать набор после утраты основной машины.

Восстановить в новое место

На выделенном стенде распакуем копию в /srv/release-lab-recovery, который не обслуживается основным доменом. Пользователь восстановления имеет права только на этот каталог. Архив из собственного доверенного хранилища всё равно читают до распаковки, проверяя ожидаемую структуру. Незнакомые абсолютные пути и ссылки требуют отдельного разбора; здесь нет необходимости распаковывать архив с root-правами поверх системы.

mkdir -p /srv/release-lab-recovery
tar -xzf static-2026-10-10.tgz -C /srv/release-lab-recovery

После распаковки отдельный закрытый виртуальный сайт может читать releases/r1/public под этим префиксом. Настройки основного сайта не меняются. Восстановление должно включать подходящий MIME для старых статических .php и реальную 404, иначе проверка файлов не проверяет восстановление обслуживания. Ожидаемый эффект — новый корень способен отдать известный старый выпуск независимо от прежнего current.

Что считать успешным результатом

Проверяем паспорт, главную, каталог, старую статью и её ресурс. Установим также приблизительное время восстановления, когда оно действительно измерено. Строка «архив распакован» подтверждает лишь один этап. Строка «в закрытом окружении проверены обязательные ответы восстановленного r1» описывает практическую способность вернуть сайт. Даты и результаты в данном тексте остаются условными: пробное восстановление при написании не проводилось.

В системе сопровождения полезно определить допустимую потерю изменений и допустимую длительность восстановления. Для редко обновляемой статической библиотеки ежедневная копия может быть приемлема, если автор согласен потерять последнюю публикацию и способен восстановить её из исходников. Для приложения с новыми заказами каждую минуту такой интервал уже имеет другое значение. Одинаковое расписание нельзя выбирать для них только по размеру папки.

Хранение и очистка

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

На Beget встроенное резервирование и восстановление предоставляют дополнительные инструменты. Документация советует избежать смешения старых и новых файлов при восстановлении, а для динамического сайта согласовать дату файлов и базы. Эти принципы совпадают с нашим раздельным каталогом восстановления. Инструкция Beget по резервным копиям.

После урока копия рассматривается как комплект с проверяемым назначением, а восстановление — как отдельная операция с наблюдаемым результатом. Теперь добавим журналы и индикаторы здоровья, чтобы замечать проблемы до того, как понадобится возврат или восстановление.