Шаг 1. Зафиксировать текущий момент
Запишите дату backup и время сбоя. Снимите доступные файлы, базу и логи с текущего окружения. Оно может содержать заказы и лиды новее копии. Если есть признаки взлома, источник надо проверить перед переносом кода в чистую среду.
Согласуйте, какие новые записи можно восстановить из CRM, писем или платёжных сервисов и какие потери бизнес считает неприемлемыми.
Нельзя
Накатывать старую БД поверх текущей до экспорта новых данных.
Сохранить
Копии базы, файлов, логов и список последних операций.
Шаг 2. Развернуть изолированную копию
Поднимите архив на staging с совместимыми версиями, базой, медиа и настройками. Отключите реальные письма и оплату на тесте. Открытая главная ещё не означает, что работает оформление заказа или вход.
Сверьте содержимое с датой копии и отдельно выпишите разницу между ней и нынешним состоянием.
Функции
Формы, вход, поиск, корзина, тестовая оплата, уведомления.
Данные
Таблицы, медиа, последние заявки и заказы.
Шаг 3. Спланировать переключение
Нужны окно работ, синхронизация свежих записей, ответственный за проверку и понятный откат. Если URL не меняются, не придумывайте лишних редиректов. При смене адресов потребуется отдельная карта соответствий.
После cutover откройте ключевые страницы, отправьте тестовую форму, проверьте заказ в допустимом тестовом режиме, HTTPS, интеграции и логи. Не удаляйте прежнее окружение до завершения контрольного периода.
Снаружи
Клиент видит верный контент и может совершить ключевое действие.
Внутри
Заявка доходит до ответственного, не теряясь в очереди.
Шаг 4. Записать фактический результат
Отметьте дату последней восстановленной записи, продолжительность работ, ручные операции и причину задержки. На этой основе обновите политику копий и сценарий следующего теста.