Навіщо потрібен план відкату
План відкату — це заздалегідь описаний порядок дій на випадок, якщо міграція пішла не так: сайт не відкривається, база даних пошкоджена або продуктивність на новому сервері нижча за очікувану. Без готового плану рішення про відкат ухвалюють у паніці, втрачаючи час на з'ясування, що і в якому порядку повертати.
План пишуть до початку міграції, а не після першої помилки. У ньому фіксують точки відкату, критерії ухвалення рішення і покрокові команди для повернення.
Що фіксувати перед стартом міграції
Перед перенесенням збережіть знімок стану старого сервера — він залишається еталоном, із яким звіряють новий сервер:
mysqldump -u root -p --all-databases > /backup/before_migration_2026_09_29.sql
tar czf /backup/files_before_migration.tar.gz /var/www
dig +short NS example.com > /backup/dns_before_migration.txt
Запишіть поточні значення TTL у DNS-записах і поточну версію ПЗ (PHP, MySQL, вебсервера) — ці дані знадобляться, якщо відкат доведеться робити через тиждень після переїзду.
Точки відкату: DNS, база даних, файли
Визначте три незалежні точки, кожну з яких можна відкотити окремо:
| Точка відкату | Що повертаємо | Час відкату |
|---|---|---|
| DNS | A-записи на старий сервер | від 5 хвилин до TTL |
| База даних | дамп до початку міграції | 10-30 хвилин |
| Файли | архів до перенесення | 10-60 хвилин |
Старий сервер тримайте увімкненим і без змін щонайменше 7 днів після перемикання — це і є остання точка відкату, якщо проблему буде виявлено не одразу. Загальний порядок керування DNS під час переїзду описано в статті про зміну хостингу без простою.
Критерії ухвалення рішення про відкат
Заздалегідь пропишіть умови, за яких відкат є обов'язковим, а не бажаним:
- Сайт повертає помилки 500 більш ніж на 5% запитів протягом 15 хвилин.
- Розбіжність кількості записів у ключових таблицях бази даних більш ніж на 1%.
- Критичний функціонал (оплата, авторизація) не працює понад 30 хвилин.
- Продуктивність сторінок впала більш ніж удвічі відносно старого сервера.
Покроковий відкат
Порядок дій за ухваленого рішення про відкат:
# 1. Повернути DNS-записи на старий сервер
# 2. Переконатися, що старий сервер досі приймає запити
curl -I https://old-server-ip -H "Host: example.com"
# 3. Відновити базу даних із дампа, якщо на новому сервері були записи
mysql -u root -p example_db < /backup/before_migration_2026_09_29.sql
# 4. Повідомити користувачів про тимчасову недоступність окремих функцій
Якщо дані встигли змінитися на новому сервері після перемикання, перед відкатом синхронізуйте різницю вручну — інакше користувачі втратять замовлення або коментарі, створені після переїзду.
Тестування плану відкату заздалегідь
Перевірте план на тестовому середовищі до реальної міграції: розгорніть копію сайту, виконайте перенесення, а потім відкотіть його за написаним планом. Виміряйте реальний час відкату — він має вкладатися в допустимий час простою, погоджений із власником сайту.
Підсумок: чек-лист готовності до відкату
- Зробіть дамп бази даних і архів файлів безпосередньо перед міграцією.
- Зафіксуйте поточні NS-записи і TTL до змін.
- Опишіть три точки відкату: DNS, база даних, файли.
- Пропишіть числові критерії, за яких відкат є обов'язковим.
- Протестуйте план відкату на копії сайту заздалегідь.
Після успішного перемикання, незалежно від того, був відкат чи ні, пройдіть загальний чек-лист перевірки після міграції, а для самого перенесення бази використовуйте інструкцію з перенесення бази даних MySQL.