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

Файл с названием backup.zip легко принять за страховку. Но архив может оказаться неполным, повреждённым, слишком старым или зависимым от версии PHP и настроек сервера, которых уже нет. Узнать это во время сбоя — значит потратить первые часы не на восстановление сайта, а на выяснение содержимого копии.

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

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

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

Полезно ответить на два вопроса:

до какого момента должны сохраниться данные;
сколько времени бизнес может работать без сайта.

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

Проверьте комплектность копии

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

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

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

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

Не проверяйте восстановление поверх рабочего сайта

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

Тестовый сайт лучше закрыть от поисковой индексации и посторонних посетителей. Одного файла robots.txt для ограничения доступа недостаточно: он даёт рекомендации роботам, но не заменяет пароль или сетевое правило.

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

Разверните сайт в воспроизводимом порядке

До начала засеките время. Цель теста — не поставить рекорд, а увидеть реальную длительность и места, где нужны ручные действия.

Подготовьте совместимое окружение. Уточните версии PHP, сервера базы данных и необходимые расширения. Если точных сведений нет, отмечайте каждое предположение: во время настоящего инцидента оно снова отнимет время.
Восстановите файлы. Проверьте права доступа, наличие пользовательских загрузок, конфигурации, тем и модулей.
Импортируйте базу. Убедитесь, что восстановлены все таблицы и импорт завершился без ошибок или обрезанных данных.
Свяжите конфигурацию с тестовой средой. Используйте отдельные реквизиты базы и не переносите действующие секреты туда, где они не нужны.
Замените адрес сайта безопасным способом. Простая текстовая замена в дампе может повредить сериализованные данные WordPress. Используйте штатный инструмент CMS или проверенную команду миграции.
Отключите внешние действия. Письма перехватывайте в тестовый ящик, платежи оставляйте в песочнице, планировщик и вебхуки запускайте только осознанно.
Очистите кэш и пересохраните правила адресов. Иначе исправный сайт может показывать старые страницы или возвращать ошибки на внутренних URL.

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

Главная страница — только начало проверки

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

Проверьте:

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

Сверьте несколько свежих материалов, пользователей, заказов или заявок с выбранной контрольной точкой. Так можно заметить, что база восстановилась, но оказалась старше файлов либо импортировалась не полностью.

Отдельно исключите возврат причины сбоя

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

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

Запишите результат так, чтобы им можно было воспользоваться

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

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

Чек-лист проверки резервной копии сайта

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

Частые вопросы о восстановлении сайта

Достаточно ли проверить, что архив открывается?

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

Как часто проводить пробное восстановление?

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

Чем VOWE может помочь, если сайт уже взломан?

В рамках работ по безопасности сайта VOWE проверяет сайт на вирусы, уязвимости и следы взлома. Если сайт уже пострадал, специалисты сначала локализуют проблему и оценивают восстановление, а затем предлагают меры против повторного заражения. Конкретный план зависит от состояния сайта, CMS, хостинга и доступных копий.