1. Зафіксуйте вихідний стан
Запишіть час збою й дату копії. Збережіть доступні логи, файли та поточну базу. Частково зламаний сайт усе ще може містити нові замовлення, заявки або контент. Якщо причина — компрометація, не переносіть заражені компоненти в чисте середовище без аналізу.
Погодьте з бізнесом, скільки даних між резервною точкою та поточним моментом можна втратити і звідки можна добрати різницю.
Незворотний ризик
Перезапис поточної БД старою копією до експорту новіших записів.
Артефакти
Копії поточної БД, файлів, логів і список останніх транзакцій.
2. Розгорніть backup у тестовому середовищі
Перевірте сумісність версій, конфігурацію, доступ до БД, сховище медіа та зовнішні сервіси. У staging вимкніть реальні розсилки й платежі, щоб тест не створював нових клієнтських операцій. Не оцінюйте готовність лише за відкритою головною сторінкою.
Звірте кількість і стан замовлень, останній опублікований контент, користувачів і файли з очікуваною датою копії.
Функції
Форма, вхід, пошук, кошик, оплата в тестовому режимі, сповіщення.
Дані
Цілісність таблиць, медіа та записи після backup.
3. Підготуйте перемикання й відкат
Визначте вікно змін, спосіб синхронізації нових даних, DNS або деплой, того, хто перевіряє результат, та умову повернення. Якщо змінюються URL, потрібна окрема карта адрес; при тому самому домені й шляхах її не вигадують.
Після перемикання протестуйте критичні сторінки, форми, замовлення, HTTPS, інтеграції та серверні помилки. Залиште попередній стан доступним для відкату на погоджений час.
Публічна перевірка
Користувач бачить правильний вміст і може виконати ключову дію.
Внутрішня перевірка
Заявка або замовлення реально доходить до відповідального й не губиться.
4. Зафіксуйте урок
Запишіть фактичну точку даних, тривалість відновлення, втрати, ручні кроки й причини затримки. Виправте політику копій та заплануйте наступний тест, інакше команда повернеться до тієї самої невизначеності.