Перенесення проєкту з VPS на виділений сервер
Переїзд роблять у чотири кроки: піднімають дзеркало оточення на новій машині, синхронізують файли через rsync і базу через дамп, перевіряють проєкт за новою адресою без зміни DNS, потім перемикають записи з коротким TTL. За такої схеми простій вимірюється хвилинами фінальної досинхронізації, а не годинами.
- Знижуйте TTL DNS-записів до 300 секунд за добу до перемикання, інакше частина відвідувачів ще день ходитиме на старий сервер.
- Файли переносьте rsync за два проходи: довгий чорновий на працюючому проєкті та короткий фінальний після зупинки запису.
- Базу переносьте дампом із блокуванням на рівні транзакції, а не копіюванням каталогу даних на живій СУБД.
- Старий VPS тримайте оплаченим ще тиждень — це найдешевший план відкату.
Крок 0. Інвентаризація і підготовка
Зберіть перелік того, що реально працює на VPS: версії PHP, Python чи Node, вебсервер і його конфіги, СУБД та її версія, cron-задачі, systemd-юніти, сертифікати, ключі деплою, зовнішні монтування.
На новому сервері одразу зробіть базове налаштування: ключі SSH, оновлення, фаєрвол, моніторинг. Порядок перших кроків на чистій машині описано в матеріалі приймання виділеного сервера, а загальна логіка переходу між типами хостингу — у статті виділений сервер чи VPS.
| Що переносимо | Чим | На що дивитися |
|---|---|---|
| Файли сайту та завантаження | rsync із ключами -aHAX | Права, власники, жорсткі посилання, xattr |
| MySQL або MariaDB | mysqldump із single-transaction | Кодування, процедури, тригери, події |
| PostgreSQL | pg_dump у форматі custom | Розширення, ролі, права на схеми |
| Пакети та версії | dpkg або rpm зі списком | Версія PHP і модулі, версія СУБД |
| Регулярні задачі | crontab і systemd timers | Користувач задачі, змінні оточення |
| Сертифікати | Копія каталогу або новий випуск | Ланцюжок, права на приватний ключ |
Крок 1. Дані
# перший прохід: можна виконувати на працюючому проєкті
rsync -aHAX --numeric-ids --delete \
-e 'ssh -p 22' /var/www/ root@NEW_IP:/var/www/
# дамп MySQL/MariaDB без блокування таблиць InnoDB
mysqldump --single-transaction --quick --routines --triggers --events \
--databases shop > /root/shop.sql
# передаємо і розгортаємо на новому сервері
scp /root/shop.sql root@NEW_IP:/root/
ssh root@NEW_IP 'mysql shop < /root/shop.sql'
# PostgreSQL: дамп і паралельне відновлення
pg_dump -Fc -U postgres shop > /root/shop.dump
pg_restore -U postgres -d shop -j 4 /root/shop.dump
# перелік пакетів зі старої машини, щоб повторити оточення
dpkg --get-selections | grep -v deinstall > pkgs.txt
Подробиці щодо ключів дампа і відновлення окремих таблиць розібрано в матеріалі mysqldump: резервна копія і відновлення.
Крок 2. Перевірка до перемикання DNS
Не перемикайте домен «щоб подивитися, як вийшло». Новий сервер перевіряють за адресою, і лише після цього чіпають зону:
# запит до нового сервера з правильним іменем хоста та SNI
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' \
--resolve example.com:443:NEW_IP https://example.com/
# порівнюємо відповідь старого і нового вузлів
diff <(curl -s --resolve example.com:443:OLD_IP https://example.com/) \
<(curl -s --resolve example.com:443:NEW_IP https://example.com/)
# перевіряємо, що сервіси підняті й слухають потрібні порти
systemctl is-active nginx php8.3-fpm mariadb
ss -lntp | grep -E ':80|:443|:3306'
Копіювання каталогу даних СУБД на живому сервері звичайною командою копіювання дає пошкоджену базу: частина сторінок потрапить у копію до запису, частина після, і таблиці InnoDB не пройдуть перевірку. Симптом виявляється не одразу — сайт відкривається, а за добу сиплються помилки цілісності на окремих таблицях. Переносьте базу дампом або зупиняйте СУБД перед копіюванням файлів. Перевірка після переїзду: виконайте перевірку таблиць і звірте кількість рядків у 5–10 ключових таблицях зі старою машиною; цифри мають збігтися до одиниці. Окремо перевірте пошту: якщо проєкт надсилає листи самостійно, уточніть політику вихідного SMTP — на VDS порти 25, 465 і 587 типово закриті та відкриваються на запит перевіреним клієнтам.
Крок 3. Перемикання
- За добу знижуєте TTL записів A і AAAA до 300 секунд.
- Вмикаєте на старому сервері режим лише для читання або коротке технічне вікно.
- Виконуєте фінальний rsync і свіжий дамп бази — він триває хвилини, бо основний обсяг уже перенесено.
- Змінюєте A-запис на адресу нового сервера, перевіряєте поширення і логи обох вузлів.
- За добу повертаєте TTL до звичайного значення і відмовляєтеся від старого VPS.
Крок 4. Що змінюється після переїзду
На виділеному сервері зникають сусіди по гіпервізору, а разом із ними — плавуча продуктивність диска. З'являються власні задачі: стежити за станом RAID-масиву та SMART, оновлювати мікрокод і ядро, планувати резервне копіювання, бо миттєвих знімків гіпервізора більше немає. Схему копій зберіть одразу, за матеріалом резервне копіювання виділеного сервера.
Підібрати конфігурацію під навантаження, що зросло, можна в розділі виділені сервери: типовий переїзд із VPS іде на Dedicated Start DE за $49 або на Pro DE з 32 GB ECC і NVMe за $99 на місяць.
Коротко
- Порядок: інвентаризація, дзеркало оточення, дані, перевірка за адресою, DNS.
- TTL знижують заздалегідь, інакше перемикання розтягується на добу.
- База переноситься дампом; копіювання каталогу даних на живій СУБД псує таблиці.
- Перевіряйте новий вузол через curl із підміною адреси до того, як чіпати зону.
- Після переїзду заново налаштуйте моніторинг заліза та резервне копіювання.