Міграція сайту на новий хостинг: перенесення без простоїв

Уявіть: ви вирішили переїхати на новий сервер, щоб збільшити продуктивність. Але в процесі перенесення щось пішло не так — дамп БД битий, файли не скопіювалися, сайт упав на добу. Це типова ситуація для тих, хто пробує міграцію вперше. Інженери нашої команди (5+ років досвіду) провели 200+ успішних міграцій. Розроблений процес гарантує downtime не більше 15 хвилин — використовуємо паралельну роботу та попереднє тестування. Детально: перед перемиканням DNS підіймаємо повну копію на новому сервері, перевіряємо всі сценарії (авторизація, оплата, форми). Тільки потім — змінюємо A-запис з TTL 300 секунд. Такий підхід виключає втрату даних і довгий простий. При цьому ми підтримуємо обидва сервери активними до 72 годин після перемикання — на випадок відкату.

Які ризики виникають при зміні хостингу?

Неправильна міграція призводить до:

• Помилок конфігурації веб-сервера (несумісність версій PHP, модулів)
• Втрати даних через неповний дамп БД або битий архів
• Довгого даунтайму (12+ годин замість 15 хвилин)
• Битих посилань у контенті (абсолютні шляхи залишилися від старого сервера)

Ми вирішуємо ці проблеми поетапно та з надлишковим контролем.

Як мінімізувати downtime при міграції?

Ключовий принцип — паралельна робота (жарг. hot standby). Виконуємо міграцію на новому сервері, поки старий обслуговує відвідувачів. Після повної перевірки через hosts-файл перемикаємо DNS з низьким TTL (300 с). Середній даунтайм — 5–15 хвилин.

Порівняння методів перенесення даних

Rsync швидший за FTP у 5–10 разів при обсягах >10 ГБ. Ми використовуємо rsync для первинної копії та tar для резервного архіву. Додатково використовуємо pigz для розпаралелювання стиснення — прискорює процес на 30%.

Що входить в роботу?

• Перенесення файлів (rsync з винятком .git, кешу)
• Міграція БД (дамп + відновлення на новій версії СУБД)
• Налаштування веб-сервера (Nginx/Apache) та оточення (PHP, Node.js, Redis)
• Встановлення SSL-сертифіката (Let's Encrypt або ваш)
• Налаштування cron, queue workers, змінних оточення
• Перевірка через /etc/hosts до перемикання DNS
• Моніторинг 72 години після перемикання

Типові помилки при самостійній міграції

Розробники часто забувають:

• Синхронізувати .env та права на storage (chmod 775)
• Експортувати базу з прапорами --add-drop-table і --complete-insert для InnoDB
• Перевірити редиректи (http→https, www→non-www) на новому сервері
• Оновити IP в налаштуваннях CDN (Cloudflare, Vercel)

Етапи міграції

Підготовка нового сервера

Встановлюємо необхідний стек (LEMP, Node.js тощо):

# Встановлення LEMP-стеку на Ubuntu 22.04 sudo apt update && sudo apt upgrade -y sudo apt install -y nginx mysql-server php8.2-fpm php8.2-mysql php8.2-gd \ php8.2-curl php8.2-zip php8.2-mbstring php8.2-xml php8.2-intl redis-server # Для Node.js проєктів curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash - sudo apt install -y nodejs 

Перенесення файлів та бази даних

Спочатку копіюємо базу даних, потім файли — щоб мінімізувати розходження даних:

# MySQL: дамп і відновлення mysqldump -u root -p mysite_db > /tmp/mysite_db.sql scp /tmp/mysite_db.sql user@new-server:/tmp/ ssh user@new-server "mysql -u root -p new_db < /tmp/mysite_db.sql" # rsync файлів (виключаємо .git) rsync -avz --progress --exclude='.git' \ -e "ssh -p 22" \ user@old-server:/var/www/mysite/ \ user@new-server:/var/www/mysite/ 

Для PostgreSQL використовуємо pg_dump/psql. Важливо: для великих БД (50+ ГБ) застосовуємо потоковий дамп через pg_dump -Fc та pg_restore -j 4 для прискорення.

Налаштування на новому сервері

• Створюємо virtual host (Nginx/Apache)
• Переносимо .env з актуальними даними
• Встановлюємо SSL-сертифікат
• Виставляємо права на директорії: storage, cache, uploads
• Налаштовуємо cron та queue workers

Перевірка через hosts-файл

До перемикання DNS перевіряємо сайт локально:

# На локальній машині додаємо в /etc/hosts (або C:\Windows\System32\drivers\etc\hosts) NEW_SERVER_IP mysite.com www.mysite.com 

Відкриваємо сайт у браузері, перевіряємо форми, авторизацію, платіжні сценарії. Переконуємося, що всі функції працюють.

Перемикання DNS

За добу до перемикання знижуємо TTL до 300 секунд. У момент перемикання змінюємо A-запис на IP нового сервера. Після оновлення повертаємо TTL до 3600+.

# Моніторинг поширення DNS watch -n 5 "dig @8.8.8.8 mysite.com A +short" watch -n 5 "dig @1.1.1.1 mysite.com A +short" 

Пост-міграційний моніторинг

Тримаємо старий сервер активним 48–72 години. Виконуємо:

• curl перевірки доступності
• перевірка SSL-сертифіката (openssl)
• перевірка редиректів (http→https, www→non-www)

curl -I https://mysite.com echo | openssl s_client -connect mysite.com:443 2>/dev/null | grep "Verify return code" curl -I http://mysite.com # очікуємо 301 

Чому важливо тестувати на новому сервері до перемикання DNS?

Якщо перемкнути DNS без попередньої перевірки, ви можете отримати сайт з помилками: не працюють форми, битий CSS, втрата даних. Ми завжди тестуємо через hosts-файл, щоб переконатися: новий сервер відпрацьовує всі сценарії, включаючи критичні — оплату, реєстрацію, email-розсилки.

Строки та вартість

Стандартна міграція займає від 4 до 16 годин залежно від обсягу даних, кількості баз і специфіки оточення. Вартість розраховується індивідуально — пишіть, оцінимо ваш проєкт. Ми працюємо з хостингом будь-якої складності: від shared до dedicated.

Замовте міграцію під ключ — отримайте безшовний перенос з гарантією працездатності. Зв'яжіться з нами для консультації.