Содержание:
Восстановить сайт из резервной копии — не значит просто распаковать архив. Нужно выбрать правильную точку, сохранить новые данные, совместить файлы и базу, воспроизвести окружение и проверить бизнес-функции. Иначе технически открывшаяся главная страница может скрывать потерянные заказы, неработающие формы и остановленные интеграции.
Безопаснее сначала развернуть копию в изолированной среде, проверить её и только затем переключать посетителей. Исключение — заранее отрепетированный аварийный регламент, где автоматическое переключение уже протестировано.
Сначала определите, от чего восстанавливаемся
Причина определяет точку и способ восстановления. При ошибочном релизе достаточно вернуть код или конфигурацию. При удалении данных нужен дамп базы или восстановление на момент до операции. После взлома нельзя доверять последней копии, пока не определено примерное время проникновения.
| Событие | Что обычно восстанавливают | Главный риск |
|---|---|---|
| Неудачное обновление | Код, тему, модуль и связанную миграцию базы | Несовместимость отката с новыми данными |
| Случайное удаление | Отдельные записи или базу на выбранный момент | Перезаписать полезные изменения |
| Сбой сервера | Всю среду на новом узле | Забыть конфигурацию, cron, SSL или очередь |
| Взлом | Чистый код и проверенные данные до заражения | Вернуть бэкдор вместе с архивом |
| Ошибочный импорт | Базу до импорта или изменённые сущности | Потерять заказы, появившиеся после него |
До начала фиксируют время инцидента, последний гарантированно корректный момент и операции, которые происходили после него. Это основа для выбора копии.
Защитите текущее состояние и новые данные
Даже повреждённый проект может содержать актуальные заявки, заказы, оплаты, документы и журналы. Перед восстановлением создают снимок текущих файлов и базы, сохраняют логи и выгружают доступные бизнес-операции.
Если сайт продолжает принимать данные, определяют точку остановки. Например, магазин временно блокирует оформление, дожидается завершения платежей, фиксирует последний заказ и только после этого выполняет финальную синхронизацию. Для B2B-портала сохраняют очередь обмена и неподтверждённые документы.
Нельзя импортировать старый дамп поверх рабочей базы, пока не понятна разница между версиями. Это действие трудно отменить, а часть новых данных может исчезнуть без заметной ошибки.
Проверьте состав резервной копии
| Что проверить | Признак пригодности | Типичная проблема |
|---|---|---|
| Файлы | Есть код, загрузки, конфигурация и права | Архив содержит только часть каталога |
| База | Дамп читается, таблицы присутствуют, дата понятна | Файл нулевого размера или обрезан |
| Временная точка | Копия создана до инцидента | Архив уже содержит ошибку или заражение |
| Окружение | Известны версии PHP, СУБД, расширений и сервисов | Копия не запускается на новой конфигурации |
| Шифрование | Есть доступ к ключу и инструкции | Архив существует, но его нельзя расшифровать |
| Внешние зависимости | Зафиксированы DNS, CDN, хранилище, почта и API | Сайт открывается без интеграций |
Если копия хранится только в панели хостинга, заранее уточняют способ получения и ограничения. Не следует считать успешным бэкапом запись в журнале «задача завершена» без проверки размера и тестового развёртывания.
Разверните копию в изолированной среде
Создают отдельную базу, каталог и технический адрес, закрытый от индексации и посторонних пользователей. Восстанавливают файлы, импортируют базу и задают параметры подключения. Затем приводят окружение к совместимым версиям.
На тестовой среде нельзя отправлять реальные письма, списывать деньги, менять остатки в 1С или создавать сделки в CRM. Интеграции переводят в тестовый режим, отключают или направляют в безопасные заглушки.
После запуска проверяют журналы, отсутствующие файлы, ошибки миграций и фоновые задания. Если версия не проходит базовые проверки, её не переключают на продакшен.
Почему файлы и база должны соответствовать друг другу
Код может ожидать новую структуру таблиц, а старый дамп её не содержит. Или база ссылается на изображения, которых ещё не было в файловой копии. Поэтому предпочтительна согласованная точка или задокументированная последовательность восстановления.
Для магазина отдельно проверяют версии модулей оплаты, структуру заказов и миграции. Для WordPress — совместимость ядра, темы и плагинов; для 1С-Битрикс — состояние модулей, настроек и кеша; для кастомного проекта — миграции и зависимости.
Порядок переключения на восстановленную версию
После проверки выбирают окно переключения, останавливают изменения на старой версии и переносят данные, которые появились после резервной точки. Затем меняют маршрут трафика — конфигурацию сервера, балансировщик или DNS — по заранее выбранной схеме.
| Этап | Контрольная точка | Условие перехода дальше |
|---|---|---|
| Подготовка | Копия развёрнута, интеграции безопасны | Нет критичных ошибок запуска |
| Функциональная проверка | Пройдены ключевые пользовательские сценарии | Результат зафиксирован |
| Финальная синхронизация | Новые заявки и заказы сохранены | Определён последний перенесённый объект |
| Переключение | Домен и SSL ведут на нужную среду | Проверка из внешней сети успешна |
| Наблюдение | Ошибки, ресурсы и очереди контролируются | Система стабильна под реальной нагрузкой |
Старую среду не удаляют сразу. Её изолируют и сохраняют на период наблюдения, чтобы иметь источник для сравнения или контролируемого отката.
Функциональная проверка после восстановления
Набор тестов зависит от проекта, но должен отражать реальные деньги и процессы. Для корпоративного сайта это формы, телефоны, почта и CRM. Для магазина — каталог, фильтр, остатки, корзина, промокоды, оплата, уведомления и заказ в учётной системе.
| Область | Что проверить | Как подтвердить |
|---|---|---|
| Публичные страницы | Главную, услуги, карточки, изображения | Нет 404 и повреждённой вёрстки |
| Авторизация | Вход, сброс пароля, роли | Тестовые пользователи получают правильные права |
| Заявки | Форму, письмо, CRM, защиту от дублей | Тестовая заявка найдена во всех нужных системах |
| Заказы и оплата | Корзину, доставку, тестовый платёж, возврат статуса | Один заказ соответствует одной операции |
| Интеграции | 1С, ERP, CRM, телефонию, внешние API | Контрольная сущность прошла полный маршрут |
| Фоновые задачи | Cron, очереди, импорт, рассылки | Задания завершаются без накопления ошибок |
Техническая, SEO- и безопасностная проверка
Проверяют домен, HTTPS, редиректы, canonical, robots.txt, sitemap, коды ответов и отсутствие тестового адреса в ссылках. После переноса среды легко случайно закрыть сайт от индексации или оставить изображения со старого домена.
Сверяют версию PHP и базы, права на файлы, расписание cron, почту, кеш, CDN, свободное место и резервные задания. Пароли и ключи, которые были доступны в повреждённой среде, меняют.
После взлома дополнительно убеждаются, что копия чистая, точка входа закрыта, неизвестные пользователи удалены, а журналы и контроль целостности работают.
Как понять, что восстановление завершено
Сайт должен не просто открываться, а выдерживать обычную нагрузку и выполнять согласованный набор операций. Команда фиксирует выбранную копию, потерянный интервал данных, перенесённые вручную операции, время восстановления и оставшиеся риски.
Наблюдение продолжают как минимум один полный цикл: рекламный пик, импорт, резервное копирование и фоновые задачи. Если проблема была связана с накоплением данных или ночным cron, короткая проверка сразу после запуска её не выявит.
Официальная документация WordPress по резервным копиям отдельно рассматривает базу и файлы. Для бизнеса это важный принцип: пригодность каждой части и их совместимость проверяются до переключения.
Частые вопросы
Можно ли восстановить сайт прямо на рабочем сервере?
Можно, но безопаснее сначала развернуть копию отдельно. Прямое восстановление увеличивает риск перезаписать актуальные данные и лишает возможности спокойно проверить результат.
Как выбрать нужную резервную копию?
Определить последний корректный момент и проверить, что архив создан до ошибки или проникновения. Затем оценить, какие новые операции придётся перенести.
Нужно ли восстанавливать и файлы, и базу?
Зависит от инцидента. При удалении записи иногда достаточно части базы, при полном сбое нужны обе части. Они должны быть совместимы по версии и времени.
Что делать с заказами после даты копии?
Сохранить их до отката, сверить с CRM, платёжной и учётной системами, затем перенести или восстановить по утверждённому сценарию. Нельзя просто считать их потерянными.
Сколько занимает восстановление?
От минут при проверенном автоматическом переключении до многих часов при неполной копии и неизвестном окружении. Реальный срок узнают только после теста восстановления.
Когда можно удалить старую среду?
После завершения периода наблюдения, сверки данных и подтверждения владельца проекта. При инциденте безопасности её могут хранить изолированно дольше для анализа.
Нужно восстановить сайт без потери новых заявок и заказов?
German Web может проверить состав копии, развернуть её в изолированной среде, перенести актуальные данные и провести функциональную проверку перед переключением. Работа разработчика рассчитывается по ставке 2 300 ₽ в час; объём согласуется после оценки архива и проекта. Обратиться можно через техническую поддержку сайтов.
