Резервное копирование сайта: что сохранять и как проверить восстановление

Составьте список того, без чего сайт не запустится

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

Начните с инвентаризации. У статического сайта могут быть HTML-страницы, изображения, исходные тексты и скрипт сборки. У интернет-магазина добавляются база заказов, пользовательские загрузки, фоновые задания и интеграции. Часть данных иногда хранится вне сервера: в объектном хранилище, CRM или почтовом сервисе.

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

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

Согласуйте допустимую потерю данных и время восстановления

До выбора расписания задайте два вопроса: какой промежуток данных допустимо потерять и сколько времени сайт может оставаться недоступным. В планах восстановления эти цели часто обозначают RPO и RTO. RPO относится к допустимой потере данных во времени, RTO — к целевому сроку восстановления работы. Определения приведены в руководстве AWS по целям восстановления. Это требования проекта; включение бэкапа само по себе не подтверждает их выполнение.

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

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

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

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

Сохраняйте файлы и базу в согласованном состоянии

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

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

Например, документация PostgreSQL по файловым копиям различает остановленный сервер и корректно организованный согласованный снимок. Если данные размещены на нескольких файловых системах, нужно учитывать их совместное состояние. Сам факт наличия snapshot в панели VPS этого не подтверждает.

Логический дамп выгружает данные средствами СУБД. В PostgreSQL pg_dump даёт согласованную копию одной базы на момент начала выгрузки, но роли и другие общие объекты кластера требуют отдельного внимания. Это описано в руководстве по SQL-дампам. Дамп одной базы также не синхронизирует автоматически лежащие рядом пользовательские файлы.

Для MySQL режим --single-transaction у mysqldump подходит для согласованной выгрузки транзакционных таблиц, например InnoDB. Он не даёт тех же гарантий для MyISAM, а некоторые изменения структуры таблиц во время выгрузки могут нарушить результат. Ограничения перечислены в справке MySQL. Перед настройкой нужно знать движки таблиц и характер операций сайта.

Для резервной копии Битрикс проверяйте выбранный состав архива и комплектность всех его частей. При переносе предусмотрен штатный скрипт восстановления restore.php; порядок приведён в официальном уроке. После работы уберите архивы и инструменты восстановления из публичного доступа. Пароль шифрования должен быть доступен ответственному отдельно от копии.

Выберите расписание и независимое место хранения

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

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

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

Помимо расписания определите срок хранения версий. Если ошибка обнаружится через неделю, вчерашний архив может уже содержать повреждение. Несколько точек восстановления дают выбор. В рекомендациях NCSC по восстановлению отдельно отмечен риск единственной постоянно перезаписываемой копии.

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

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

Проверяйте завершение задания и целостность архива

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

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

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

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

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

Проведите восстановление в изолированном окружении

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

Закройте доступ посторонним средствами авторизации или сети. Запрет индексации не защищает содержащиеся в копии сведения. Выберите минимально нужный круг участников проверки и предусмотрите удаление тестового окружения по окончании работ.

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

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

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

Зафиксируйте результат и следующий срок проверки

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

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

Если проверка не прошла, сохраните предыдущие пригодные копии, найдите причину и повторите испытание после исправления. Не удаляйте последнюю проверенную копию, пока не проверите новую. После смены хостинга, обновления СУБД или переноса загрузок повторите проверку: прежний протокол относится к другому устройству системы.

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

Начать можно с одной учебной попытки: составить перечень объектов, получить копию и развернуть её по записанной инструкции. Так вы найдёте недостающие доступы и пропущенные шаги. Если нужна помощь с резервированием, передайте ШТАБ ИТ описание сайта, текущей схемы хранения и допустимого простоя. По ним можно согласовать состав работ и проверить выбранный порядок восстановления.