# План відкату міграції: як безпечно повернутися назад

> План відкату міграції сайту: три точки відкату, числові критерії рішення і покрокові команди для повернення на старий сервер без втрати даних.

## Навіщо потрібен план відкату

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

План пишуть до початку міграції, а не після першої помилки. У ньому фіксують точки відкату, критерії ухвалення рішення і покрокові команди для повернення.

## Що фіксувати перед стартом міграції

Перед перенесенням збережіть знімок стану старого сервера — він залишається еталоном, із яким звіряють новий сервер:

```
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 під час переїзду описано в статті [про зміну хостингу без простою](https://www.zevshost.net/uk/kb/migratsia-dns-bez-prostoya/).

## Критерії ухвалення рішення про відкат

Заздалегідь пропишіть умови, за яких відкат є обов'язковим, а не бажаним:

- Сайт повертає помилки 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, база даних, файли.
- Пропишіть числові критерії, за яких відкат є обов'язковим.
- Протестуйте план відкату на копії сайту заздалегідь.

Після успішного перемикання, незалежно від того, був відкат чи ні, пройдіть загальний [чек-лист перевірки після міграції](https://www.zevshost.net/uk/kb/migratsia-proverka-posle/), а для самого перенесення бази використовуйте [інструкцію з перенесення бази даних MySQL](https://www.zevshost.net/uk/kb/perenesti-bazu-dannykh/).

---

Джерело: https://www.zevshost.net/uk/kb/migratsia-plan-otkata/