Как восстановить сайт из бэкапа и убедиться, что копия рабочая

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

Ниже — что должно быть в полной копии, порядок восстановления для трёх типов сайтов, часовой тест и таблица, кто за копии отвечает.

Что входит в полную копию: таблица, а не только файлы

Резервная копия сайта — это не один zip-архив с картинками и текстами. Часть данных хранится вне папки сайта, и про неё часто забывают уже на этапе настройки копирования.

Копия хостинга закрывает первые две строки таблицы: файлы и базу. Остальное придётся выгружать вручную или настроить инструментом резервного копирования, который умеет забирать конфиги и расписание задач, а не только /public_html. Без этого восстановление вернёт сайт, а не рабочий процесс вокруг него: письма перестанут уходить, обмен с 1С замолчит, и об этом узнают через неделю, не сразу.

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

Как восстановить сайт на тестовом поддомене

Общий порядок один для любой CMS. Копию разворачивают рядом с боевым сайтом, на отдельном поддомене с чистой базой, и только потом переносят на основной домен.

1. Создайте тестовый поддомен (test.вашсайт.ru) с отдельной базой данных.
2. Загрузите архив файлов на сервер и распакуйте в корень поддомена.
3. Импортируйте дамп базы в новую, пустую базу поддомена.
4. Пропишите в конфиге адрес базы, логин, пароль и домен поддомена вместо боевого.
5. Закройте поддомен от индексации (robots.txt или заголовок X-Robots-Tag). Иначе Яндекс и Google увидят дубль главного сайта.
6. Проверьте вход в админку и работу форм.
7. Если тест прошёл, повторите шаги 2–4 на боевом домене, предварительно сняв копию текущего состояния — на случай, если новая копия окажется хуже старой.

Для 1С-Битрикс есть штатный путь короче общего. Скрипт restore.php из раздела «Настройки → Инструменты → Резервное копирование» кладётся в корень сайта и сам разворачивает архив по шагам мастера — правку конфига и импорт базы он берёт на себя. Актуальное описание работы со скриптом — в разделе резервного копирования на docs.1c-bitrix.ru¹.

Для WordPress готового мастера восстановления в ядре нет. Файлы и таблица wp_options, где хранится адрес сайта, разворачиваются вручную по шагам 1–4 выше, а адрес в базе после импорта меняется отдельным SQL-запросом или через команду wp-cli search-replace. Порядок работы с файлами и базой описан в разделе Backups документации разработчика WordPress²; готового скрипта на все случаи там нет, только последовательность и предупреждения о рисках прямой правки таблиц.

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

Тест восстановления за час: чек-лист

Копия проверяется не открытием архива, а разворачиванием на тесте. Раз в квартал (для интернет-магазина — раз в месяц) выполните на тестовом поддомене:

1. Возьмите последнюю копию из хранилища — без выбора «покрасивее», ровно ту, что развернётся при аварии.
2. Разверните файлы и базу по шагам из раздела выше.
3. Засеките время от старта до рабочего сайта на тесте.
4. Войдите в админку под тестовым пользователем.
5. Откройте карточку товара или услуги. Проверьте, что цена и остаток на месте.
6. Отправьте тестовую заявку через форму. Проверьте, что письмо или запись в CRM дошли.
7. Если есть оплата — пройдите до экрана оплаты в тестовом режиме провайдера, не завершая платёж.
8. Проверьте, что подключаются внешние модули: поиск, чат, счётчики.
9. Сверьте количество товаров или страниц в тестовой базе с боевой. Расхождение покажет, что копия делалась не полностью.
10. Запишите время восстановления и дату теста. Это число понадобится при расчёте простоя, а не абстрактная оценка «быстро».

Результат теста — точное время в минутах и список того, что не поднялось само. «Копия есть» — не ответ на вопрос «сколько мы теряем при аварии». Забытый cron-обмен или потерянный ключ платёжного шлюза чаще всего всплывают именно на этом шаге, не в момент реальной аварии, когда цена ошибки уже другая.

Из какой копии восстанавливать после взлома

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

Порядок действий:

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

Если сайт заражён прямо сейчас и это первые сутки происшествия, план на первые сутки после взлома описывает приоритеты за пределами одного только восстановления из копии: что делать до неё и что — параллельно с ней.

Как часто делать копии и где хранить: правило 3-2-1

Практика резервного копирования, на которую опираются специалисты по безопасности, — три копии данных, на двух разных типах носителей, одна из которых хранится вне основной инфраструктуры. В такой формулировке правило описывает CISA (Cybersecurity and Infrastructure Security Agency, агентство кибербезопасности США) в материалах о защите от вымогательского ПО³.

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

Частота копирования зависит от того, как часто меняются данные:

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

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

Кто отвечает за копии: хостинг, подрядчик, вы

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

• Хостинг. Делает копию инфраструктуры для своих задач: аварийного восстановления сервера, а не именно вашего сайта. Срок хранения короткий, обычно 7–14 дней, и копия исчезает вместе с аккаунтом при неоплате или блокировке — рассчитывать на неё как на единственный экземпляр рискованно. Что спросить у хостинга про резервные копии перед оплатой тарифа, разбирает отдельный материал про выбор хостинга: копия хостинга не заменяет собственную, вне его инфраструктуры.
• Подрядчик по поддержке. Настраивает регулярное копирование вне хостинга и следит за тестом восстановления, если это прописано в договоре. Разовая резервная копия у Toimi обойдётся от 3 500 ₽ (прод, сверено 29.09.2026); регулярное копирование с тестом восстановления входит в пакеты техподдержки.
• Владелец сайта. Хранит минимум одну копию доступов и понимает, куда обращаться при аварии, даже если техническую часть ведёт подрядчик. Без этого одна уволенная должность может унести с собой единственный пароль к хранилищу копий.

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