Як перенести сайт або застосунок на новий хмарний сервер
Щоб безпечно перенести проєкт на хмарний сервер, не чіпайте старий сервер, доки новий не обслужить реальний трафік. Це план для сайту, магазину чи застосунку: три чеклісти (до, перемикання, відкат), команди, які можна адаптувати, і чесні межі щодо простою. Спочатку підберіть ресурси за посібником із підбору хмарного сервера, а регіон оберіть за посібником із локацій у Європі.
Оберіть спосіб міграції
Майже будь-який перенос вкладається в чотири способи. Часто їх поєднують.
| Спосіб | Підходить для | Головний ризик |
|---|---|---|
| rsync файлів | Статичні сайти, завантаження, код | Дані змінюються під час копіювання, потрібна фінальна синхронізація |
| Образ або відновлення з бекапу | Та сама ОС і структура, перевірене відновлення | Старі драйвери й імена інтерфейсів, більший обсяг |
| Повторне розгортання застосунку | Контейнери й код у git | Забутий прихований стан на старому диску |
| Реплікація бази даних | Великі або завантажені бази | Складність налаштування й обмеження версій |
Почніть із хмарного сервера від EUR 15.00/міс, перевірено 2026-10 і відрепетируйте там увесь план.
Чекліст перед міграцією
- Інвентаризація - випишіть сервіси, порти, cron-завдання, налаштування пошти, сертифікати, правила файрвола та всі імена, що вказують на стару IP-адресу.
- Прихований стан - знайдіть файли поза веб-каталогом: завантаження, черги, сесії, ліцензії, секрети у змінних середовища.
- Бекапи - зробіть повну копію старого сервера й один раз відновіть її деінде: неперевірений бекап лише надія.
- Доступ - лише SSH-ключі, файрвол і користувач без прав root на новому сервері.
- Знімок - зробіть знімок нового сервера перед першою реальною синхронізацією, щоб помилка коштувала хвилини.
Копіювання файлів і даних
У прикладах нова адреса сервера - 203.0.113.10 (адреса з документації). Підставте свої імена й шляхи. Кроки 1 і 2 можна повторювати безпечно, крок 5 виконується лише коли старий сайт у режимі читання.
# 1. Bulk copy while the old server keeps serving (repeat any time)
rsync -aHAX --numeric-ids --info=progress2 \
-e ssh /var/www/ deploy@203.0.113.10:/var/www/
# 2. Database dump and restore (MySQL / MariaDB shown)
mysqldump --single-transaction --routines --triggers appdb \
| gzip | ssh deploy@203.0.113.10 'gunzip | mysql appdb'
# 3. Test the new server under the real hostname, DNS untouched
curl -sS --resolve example.com:443:203.0.113.10 \
https://example.com/ -o /dev/null -w '%{http_code}\n'
# 4. Check the TTL resolvers will honour
dig +noall +answer example.com A
# 5. Final sync after the old site is read-only
rsync -aHAX --numeric-ids --delete \
-e ssh /var/www/ deploy@203.0.113.10:/var/www/
Прапорець --delete видаляє на цілі файли, яких уже немає на джерелі. Використовуйте його лише в останньому запуску і лише тоді, коли точно знаєте, яка сторона головна.
Спершу перевірте через файл hosts
До зміни DNS змусьте власний комп'ютер відкривати сайт із нового сервера. Додайте рядок у файл hosts (/etc/hosts або C:\Windows\System32\drivers\etc\hosts у Windows): 203.0.113.10 example.com www.example.com. Параметр --resolve у curl (крок 3) робить те саме для одного запиту. Потім приберіть рядок із hosts, інакше тижнями тестуватимете новий сервер, не помічаючи цього.
Знизьте TTL у DNS і перемкніть
Зменшіть TTL записів A та AAAA приблизно до 300 секунд щонайменше за один повний період старого TTL до переїзду. Інакше резолвери тримають стару адресу стільки, скільки дозволяє старий TTL. Частина резолверів ігнорує короткий TTL, тож очікуйте хвіст відвідувачів на старій IP-адресі протягом годин (це оцінка, а не вимірювання).
Чекліст перемикання:
- TTL - знижене значення діє, старе вже минуло.
- Лише читання - старий сайт у режимі обслуговування або читання.
- Фінальна синхронізація - зроблено останній дамп бази і крок 5 із коду вище.
- DNS - записи A та AAAA вказують на нову IP; поштові записи не змінюйте, якщо пошта не переїжджає.
- Димова перевірка - вхід, замовлення, завантаження, e-mail, cron і сертифікат перевірено на публічному імені.
- Старий сервер - залиште його працюючим, доступним і недоторканим.
Чекліст відкату
- Поріг - заздалегідь визначте, що вважати збоєм (наприклад, невдалі платежі або частка 5xx), і хто ухвалює рішення.
- DNS назад - поверніть записи на стару IP; за низького TTL більшість відвідувачів повертається за хвилини чи години.
- Запис даних - знову відкрийте старий сайт. Якщо новий після перемикання прийняв замовлення чи файли, спершу експортуйте їх і перенесіть на старий.
Що насправді потрібно для нульового простою
Нульовий простій залежить від архітектури вашого застосунку, і ми не обіцяємо його для жодного проєкту. Потрібні застосунок без стану, база, що реплікується або приймає запис з обох боків, спільне чи репліковане сховище та перевірене перемикання. Класичний сайт з однією базою зазвичай має коротке вікно читання на кілька хвилин.
Після переїзду
Щонайменше тиждень стежте за журналами помилок, диском, пам'яттю, часом відповіді та доставкою пошти. Коли все стабільно, знову збільште TTL. Виводьте старий сервер лише після повного циклу бекапів на новому; щотижневий бекап входить у кожен пресет. Перевірте все за чеклістом пробного періоду до замовлення; короткий тест можна обговорити, написавши на sales@dcxv.com, на розсуд DCXV і без гарантії.
Налаштуйте хмарний сервер для переїзду або запитайте інженера про міграцію.
