Міграція сайту без простою: покроковий гайд з бекапом, DNS та тестуванням

Міграція сайту: чому всі бояться і чому даремно

Клієнт переносив інтернет-магазин з shared hosting на VPS. Все скопіював, переключив DNS — і наступні 6 годин половина відвідувачів бачила старий сервер, а половина новий. Замовлення, оформлені в цей період, просто зникли — вони потрапили на стару базу, яку вже ніхто не обслуговував.

Причина банальна: TTL на DNS-записах стояв за замовчуванням — 86400 секунд (24 години). Якби за два дні до міграції він знизив TTL до 300 секунд (5 хвилин), переключення зайняло б кілька хвилин, а не пів доби.

Міграція сайту — це не складна операція. Це послідовність простих кроків, де кожен залежить від попереднього. Проблеми виникають коли пропускають кроки, квапляться, або починають з DNS замість бекапу.

Причин для переїзду багато: старий хостинг гальмує, не витримує трафік, не дає root-доступ, або просто коштує забагато за те що пропонує. Яка б не була причина — сам процес міграції однаковий для всіх. У цьому гайді — точна послідовність дій яка дозволяє перенести сайт з нульовим простоєм. Без магії, без дорогих інструментів — тільки правильний порядок і увага до деталей.

Крок 1: Підготовка до міграції

90% проблем при міграції — це наслідки поганої підготовки. Перенос файлів займає хвилини, а ось відновлення після втрачених даних — години або дні. Ми бачили випадки коли клієнти втрачали тижні роботи тільки тому що не зробили бекап перед початком — вважали що "нічого не піде не так". Завжди щось йде не так. Питання лише в тому чи є у вас план B.

Повний бекап

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

Що включити в бекап:

• Файли сайту — весь public_html або www директорія, включаючи .htaccess та конфігураційні файли
• Бази даних — повний дамп через mysqldump або phpMyAdmin
• Email-акаунти — якщо пошта на тому ж хостингу
• SSL-сертифікати — якщо є платний сертифікат, зберігайте ключ та сертифікат
• Cron jobs — скопіюйте розклад завдань, його легко забути

# Бекап файлів через tar
tar -czf backup_site_$(date +%Y%m%d).tar.gz /var/www/html/
# Бекап бази даних
mysqldump -u root -p --single-transaction --routines mydb > backup_db_$(date +%Y%m%d).sql

Зниження DNS TTL

Це найважливіший крок підготовки, і його потрібно зробити за 24-48 годин ДО міграції. Зайдіть у DNS-панель вашого доменного реєстратора та змініть TTL для A-запису з поточного значення (зазвичай 3600 або 86400) на 300 секунд (5 хвилин).

Навіщо? TTL визначає як довго DNS-резолвери по всьому світу кешують вашу IP-адресу. Якщо TTL = 86400 (24 години), після зміни IP-адреси частина користувачів ще добу бачитиме старий сервер — бо їх DNS-провайдер закешував стару адресу і не перевірятиме нову до закінчення TTL. Якщо TTL = 300 (5 хвилин) — DNS-провайдери перевіряють записи кожні 5 хвилин, і переключення відбувається майже миттєво.

Приклад: ваш поточний TTL = 14400 (4 години). Ви змінюєте його на 300. Але потрібно почекати ці 4 години щоб старе значення TTL "вимилось" з усіх кешів. Тільки після цього нове TTL = 300 стане активним. Ось чому цей крок потрібно робити за 24-48 годин до міграції — щоб бути на 100% впевненим.

Інвентаризація

Перед переносом складіть список того що має працювати після міграції. Це звучить очевидно, але саме "очевидні" речі забувають. Зробіть це у текстовому файлі або таблиці — не покладайтесь на пам'ять:

• Версія PHP та розширення (перевірте через php -v та php -m на старому сервері)
• Версія MySQL/MariaDB
• Зовнішні сервіси: платіжні шлюзи, API інтеграції, CDN
• Перенаправлення (.htaccess або конфіг Nginx)
• Поштові записи (MX, SPF, DKIM) — якщо пошта йде через хостинг

Крок 2: Перенос файлів та бази даних

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

Файли

Для невеликих сайтів (до кількох гігабайт) підійде SCP або SFTP через графічний клієнт типу FileZilla. Для великих проєктів — rsync, який показує прогрес, копіює тільки змінені файли, та продовжує після обриву з'єднання (замість початку з нуля). Rsync — найнадійніший інструмент для переносу файлів між серверами, він використовується навіть у корпоративних міграціях:

# Прямий перенос між серверами (якщо є SSH-доступ до обох)
rsync -avz --progress /var/www/html/ user@new-server:/var/www/html/
# Або через локальну машину (двома кроками)
scp -r user@old-server:/var/www/html/ ./site-backup/
scp -r ./site-backup/ user@new-server:/var/www/html/

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

chown -R www-data:www-data /var/www/html/
find /var/www/html/ -type d -exec chmod 755 {} \;
find /var/www/html/ -type f -exec chmod 644 {} \;

Це встановить стандартні права: директорії 755, файли 644, власник www-data (для Nginx та Apache).

База даних

Перенос бази — найвідповідальніший етап. Помилка тут означає або втрату даних, або непрацюючий сайт. Стандартний підхід — дамп на старому сервері, перенос файлу, імпорт на новому:

# На старому сервері — створюємо дамп
mysqldump -u root -p --single-transaction mydb > mydb.sql
# Переносимо файл на новий сервер
scp mydb.sql user@new-server:/tmp/
# На новому сервері — імпортуємо
mysql -u root -p mydb < /tmp/mydb.sql

Прапорець --single-transaction критично важливий для InnoDB таблиць — він дозволяє зробити консистентний дамп без блокування бази. Без нього під час дампу можуть записатись нові дані і дамп буде неконсистентним.

Для великих баз (10+ ГБ) використовуйте стиснення при переносі — це зменшує час в 3-5 разів та економить трафік:

mysqldump -u root -p --single-transaction mydb | gzip | ssh user@new-server "gunzip | mysql -u root -p mydb"

Конфігурація на новому сервері

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

• wp-config.php (WordPress) — нові дані підключення до бази: хост, ім'я бази, користувач, пароль
• .env (Laravel, Node.js тощо) — рядки підключення до бази та зовнішніх сервісів
• Права доступу — перевірте що веб-сервер має доступ до файлів: chown -R www-data:www-data /var/www/html/
• PHP-версія — на новому сервері може стояти інша версія, перевірте сумісність

Особливості для WordPress

WordPress — найпопулярніша CMS, і при міграції є кілька специфічних нюансів. У базі даних зберігаються абсолютні URL-адреси сайту (у таблицях wp_options, wp_posts, wp_postmeta). Якщо домен не змінюється — проблем не буде. Але якщо ви переносили на тимчасовий домен для тестування — потрібно зробити пошук і заміну URL через WP-CLI:

wp search-replace 'temp-domain.com' 'your-domain.com' --all-tables

Також перевірте що на новому сервері встановлені всі PHP-розширення які потребують ваші плагіни. Найчастіше це: php-mysql, php-curl, php-gd, php-mbstring, php-xml. Відсутність одного розширення може зламати конкретний плагін без видимих помилок — сайт буде працювати, але якась функція мовчки перестане.

Після міграції зайдіть в адмін-панель WordPress → Налаштування → Постійні посилання → натисніть "Зберегти зміни" (без змін). Це перегенерує правила URL-перенаправлень і часто виправляє помилки 404 на внутрішніх сторінках.

Міграція з cPanel або DirectAdmin

Якщо ваш поточний хостинг використовує cPanel — процес переносу можна спростити через вбудований бекап. Зайдіть у cPanel → Backup → Generate Full Backup. Це створить архів з усіма файлами, базами даних, email-акаунтами, cron-задачами та конфігами в одному файлі.

Якщо новий сервер теж має cPanel — цей архів можна імпортувати цілком. Якщо новий сервер без панелі (чистий VPS з Nginx) — архів доведеться розпакувати вручну та перенести файли і базу окремо, як описано вище.

DirectAdmin має аналогічну функцію: Панель → Admin Backup / Transfer. Схема та ж: повний бекап на старому → перенос → імпорт на новому. Головне — переконайтесь що версії панелей сумісні, інакше імпорт може не пройти.

Для серверів без панелей управління (чистий Linux з Nginx або Apache) — використовуйте rsync + mysqldump як описано вище. Це найуніверсальніший метод, який працює між будь-якими серверами незалежно від панелей та конфігурацій.

Якщо немає SSH-доступу до старого хостингу

На деяких shared-хостингах SSH закритий. У такому випадку доступні альтернативні методи переносу файлів та бази:

Файли — завантажте через файловий менеджер у панелі хостингу (cPanel File Manager) або через FTP/SFTP клієнт (FileZilla, WinSCP). Для великих сайтів це може зайняти значно більше часу ніж rsync, але працює завжди.

База даних — експортуйте через phpMyAdmin (зазвичай доступний у панелі хостингу). Оберіть вашу базу → вкладка "Export" → формат SQL → натисніть "Go". Файл завантажиться на ваш комп'ютер. Потім імпортуйте його на новому сервері через phpMyAdmin або командний рядок.

Цей метод повільніший за rsync + mysqldump, але дозволяє перенести сайт навіть з найбільш обмеженого shared-хостингу.

Крок 3: Тестування на новому сервері

Файли та база перенесені, конфіги оновлені — але DNS досі дивиться на старий сервер. Це ідеальний момент для тестування: реальні користувачі продовжують працювати зі старим сервером як звичайно, а ви маєте скільки завгодно часу щоб все перевірити на новому. Не квапьтесь — краще витратити зайву годину на тести, ніж потім виправляти проблеми під тиском живого трафіку.

Тестування через hosts-файл

Щоб побачити сайт на новому сервері до зміни DNS — додайте запис у файл hosts на вашому комп'ютері:

# Windows: C:\Windows\System32\drivers\etc\hosts
# macOS/Linux: /etc/hosts
198.51.100.25  example.com
198.51.100.25  www.example.com

Замініть 198.51.100.25 на IP-адресу нового сервера, а example.com на ваш домен. Тепер саме ваш браузер відкриватиме сайт з нового сервера, поки всі інші відвідувачі бачать старий. Це дозволяє повністю протестувати сайт в реальних умовах — з правильним доменом, SSL, і всіма конфігами — без ризику для живих користувачів.

Що перевірити

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

• Головна сторінка та всі основні розділи завантажуються без помилок
• Форми працюють — реєстрація, контактна форма, пошук
• Адмін-панель доступна та працює
• Зображення відображаються (часта проблема — хардкодені абсолютні шляхи)
• HTTPS працює (якщо вже налаштували SSL на новому сервері)
• Для eCommerce: кошик, оформлення замовлення, платіжний шлюз
• Email відправляється з нового сервера (перевірте через контактну форму)

Крок 4: Переключення DNS та фінальна синхронізація

Тестування пройшло успішно — час переключати трафік. Але спочатку пройдіться по фінальному чеклісту. Кожен пропущений пункт — це ризик проблем після переключення:

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

Фінальна синхронізація

Безпосередньо перед переключенням DNS зробіть фінальний rsync та свіжий дамп бази. Rsync з прапорцем --delete видалить файли на новому сервері, яких вже немає на старому — це гарантує повну ідентичність:

# Довантажити тільки змінені файли
rsync -avz --delete --progress user@old-server:/var/www/html/ /var/www/html/
# Свіжий дамп бази
mysqldump -u root -p --single-transaction mydb > final_dump.sql
mysql -u root -p mydb < final_dump.sql

Для сайтів з великою активністю (eCommerce, форуми, SaaS) цей крок критично важливий. Між першим переносом бази та моментом переключення DNS могло пройти кілька годин або навіть днів — за цей час на старому сервері з'явились нові замовлення, коментарі, реєстрації. Якщо просто переключити DNS без фінальної синхронізації — ці дані зникнуть.

Для високонавантажених проєктів рекомендуємо такий підхід: поставте сайт на старому сервері в режим обслуговування (maintenance mode) на 10-15 хвилин, зробіть фінальний дамп, імпортуйте на новий сервер, перевірте — і тоді переключайте DNS. 15 хвилин запланованого простою значно краще ніж втрачені замовлення або дублікати даних.

Зміна DNS

Оновіть A-запис вашого домену на IP-адресу нового сервера у панелі доменного реєстратора. Якщо ви заздалегідь знизили TTL до 300 секунд — більшість користувачів побачать новий сервер протягом 5-10 хвилин. Найкращий час для переключення — ніч або раннє ранок робочого дня, коли трафік мінімальний.

Моніторинг propagation

DNS propagation — не миттєвий процес. Різні DNS-резолвери по всьому світу оновлюються з різною швидкістю. Навіть з TTL 300 секунд деякі провайдери можуть кешувати записи довше. Перевірити стан propagation по різних регіонах та провайдерах можна на безкоштовних сервісах типу dnschecker.org або whatsmydns.net — вони показують яку IP-адресу бачать DNS-сервери в різних країнах.

Протягом propagation частина трафіку може йти на старий сервер, частина — на новий. Саме тому важливо тримати обидва сервери активними та синхронізованими до повного завершення процесу. Не вносьте зміни в контент сайту поки propagation не завершиться — інакше зміни будуть видимі тільки частині відвідувачів.

Крок 5: Перевірка після міграції

DNS переключений, трафік йде на новий сервер — але робота ще не завершена. Перші 24-48 годин — критичний період. Слідкуйте за логами помилок, перевіряйте швидкість завантаження (новий сервер повинен бути мінімум не повільнішим за старий), та реагуйте на будь-які скарги користувачів.

Перевірка SEO

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

• Перевірте Google Search Console на помилки індексації протягом тижня після міграції
• Переконайтесь що robots.txt та sitemap.xml доступні і коректні на новому сервері
• Якщо змінились URL — налаштуйте 301 редиректи зі старих адрес на нові. У Nginx це робиться так:

  # У конфігурації Nginx
  rewrite ^/old-page$ /new-page permanent;

• Перевірте що canonical теги вказують на правильні URL
• Подайте оновлену sitemap через Google Search Console — це прискорить переіндексацію

Швидкість завантаження — ще один фактор SEO який варто перевірити. Якщо новий сервер повільніший за старий (наприклад через іншу локацію дата-центру або слабшу конфігурацію), це може негативно вплинути на позиції. Перевірте через Google PageSpeed Insights або GTmetrix і порівняйте результати з тим що було на старому хостингу.

Перевірка працездатності

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

# Nginx — помилки
tail -f /var/log/nginx/error.log
# Apache — помилки
tail -f /var/log/apache2/error.log
# PHP — помилки (якщо логування налаштоване)
tail -f /var/log/php-fpm/error.log

Якщо бачите помилки 502 Bad Gateway або 504 Gateway Timeout — це зазвичай означає що PHP-FPM або бекенд не встигає обробляти запити. Можливо потрібно збільшити кількість PHP-FPM воркерів або підняти ліміти пам'яті.

SSL-сертифікат

Якщо використовуєте Let's Encrypt (а це найпоширеніший варіант для більшості сайтів) — потрібно згенерувати новий сертифікат на новому сервері. Старий сертифікат прив'язаний до старого сервера і не перенесеться автоматично:

sudo certbot --nginx -d example.com -d www.example.com

Certbot автоматично налаштує Nginx та оновлюватиме сертифікат кожні 90 днів. Якщо у вас платний сертифікат (наприклад, EV або Wildcard) — перенесіть приватний ключ та файл сертифіката на новий сервер і пропишіть шляхи у конфігурації Nginx або Apache.

Email

Якщо пошта була на старому хостингу (а це дуже поширена конфігурація для невеликих сайтів) — переконайтесь що MX-записи вказують на правильний поштовий сервер. Це найчастіша причина "зниклих" листів після міграції: DNS вже дивиться на новий сервер, а пошта на ньому не налаштована — листи просто відбиваються.

Якщо пошта на зовнішньому сервісі (Gmail Workspace, Zoho Mail, Microsoft 365) — MX-записи не змінюються і все буде працювати як раніше. Але перевірте SPF та DKIM записи — вони можуть містити IP-адресу старого сервера, і листи з нового сервера потраплятимуть у спам.

Коли можна видалити старий хостинг

Не раніше ніж через 72 години після переключення DNS — це максимальний час propagation для більшості DNS-провайдерів. Ще краще — почекайте тиждень, переконайтесь що все працює стабільно, і тільки тоді скасовуйте. Зекономлені $10-20 за місяць старого хостингу не варті ризику втратити дані. Деякі провайдери видаляють всі файли миттєво після скасування — без попередження і без можливості відновлення.

Типи міграції: порівняння підходів

Складність міграції залежить від типу сайту, розміру бази даних та кількості інтеграцій. Простий лендінг переноситься за 15 хвилин, а high-load eCommerce з кастомними інтеграціями може зайняти цілий робочий день.

Загальне правило: чим більше динамічного контенту та зовнішніх інтеграцій — тим більше уваги потребує тестування. Статичний сайт або лендінг — файли скопіювали і все працює. Інтернет-магазин з платіжними шлюзами, email-розсилками, CRM-інтеграціями — кожну з цих систем потрібно перевірити окремо після переносу.

7 помилок які роблять міграцію болючою

Ці помилки ми зібрали з реального досвіду — більшість з них виглядають очевидними на папері, але регулярно повторюються навіть у досвідчених адміністраторів. Зазвичай через поспіх або впевненість що "я і так все пам'ятаю".

Якщо ви не впевнені в своїх силах або сайт критично важливий для бізнесу (eCommerce, SaaS) — довірте міграцію професіоналам. Вартість помилки при міграції інтернет-магазину з оборотом навіть $1000 на день може перевищити будь-яку вартість послуги міграції. Hostiserver виконує безкоштовну міграцію для всіх нових клієнтів — і це один з найсильніших аргументів на користь того щоб не робити все самостійно.

Часті питання