Переїзд сайту з shared-хостингу на VPS: покрокова карта для тих, хто боїться все зламати
Уявіть: ви переїжджаєте з комунальної квартири у власну студію. Там більше ніхто не буде заливати вам стелю, красти Wi-Fi і слухати вашу музику о другій ночі. Але є нюанс - у новій квартирі немає меблів, і навіть лампочку треба вкрутити самому. Саме так виглядає переїзд з shared-хостингу на VPS. Свобода, потужність, контроль - і водночас повна відповідальність за кожен гвинтик. Я пройшов через це вісім разів за останні п'ять років, і кожного разу дізнавався щось, чого не було в жодному мануалі. Ця стаття - та сама карта, якої мені бракувало на початку.
Чому shared-хостинг рано чи пізно стає тісним
Коли сайт отримує 200-300 відвідувачів на день, shared-хостинг працює чудово. Він дешевий, простий, не вимагає жодних знань серверного адміністрування. Але є момент, коли ви відчуваєте стелю. Для когось це 1 000 унікальних на добу, для когось - перший рекламний сплеск на Black Friday.
Ось типові симптоми того, що ваш shared вичерпав себе:
- Сайт стабільно "лягає" у пікові години, хоча ваш код оптимізований
- Провайдер блокує процеси за перевищення CPU або RAM - хоча ви платите за "безлімітний" тариф
- Сусід по серверу запустив спам-розсилку, і ваша IP-адреса потрапила в чорний список
- Вам потрібен Redis, Memcached або нестандартна версія PHP, а панель управління каже "ні"
- TTFB (Time To First Byte) стабільно перевищує 800 мс, і це вбиває SEO
Якщо впізнали хоча б два пункти - час їхати. Не через тиждень, не через місяць. Зараз. Бо кожен день на перевантаженому shared - це втрачені позиції в Google і розлючені відвідувачі.
Що саме ви отримуєте на VPS (і чого не кажуть у рекламі)
VPS - це ваш шматок сервера з гарантованими ресурсами. Ніяких сусідів, які крадуть процесорний час. Але давайте будемо чесними: разом з потужністю ви отримуєте зобов'язання.
| Параметр | Shared-хостинг | VPS (managed) | VPS (unmanaged) |
|---|---|---|---|
| Налаштування сервера | Все зроблено за вас | Базове - за вас, тонке - самі | Повністю самі |
| Root-доступ | Ні | Так (з обмеженнями) | Повний |
| Гарантовані ресурси | Ні (overselling) | Так | Так |
| Ціна (типова) | $3-10/міс | $15-50/міс | $5-25/міс |
| Безпека | Провайдер | Спільна відповідальність | Ви і тільки ви |
| Складність переїзду | - | Середня | Висока |
Зверніть увагу на різницю між managed і unmanaged VPS. Якщо ви не знаєте, що таке iptables і чому fail2ban - це не назва нового Netflix-серіалу, обирайте managed. Серйозно. Незахищений VPS зламають швидше, ніж ви встигнете налити каву.
Чек-лист підготовки: що зробити ДО натискання кнопки "Перенести"
Мій перший переїзд на VPS закінчився 14 годинами даунтайму. Чому? Бо я кинувся переносити файли, не підготувавши нічого. Не повторюйте. Ось порядок дій:
- Зніміть повний бекап - файли сайту + база даних + конфігурації .htaccess, php.ini, cron-завдання. Зберігайте локально і в хмарі (Google Drive, Backblaze). Два бекапи - мінімум.
- Зафіксуйте поточне середовище - версії PHP, MySQL/MariaDB, модулі Apache/Nginx, розширення PHP. Команда php -m і mysql - version - ваші друзі.
- Перевірте DNS і TTL - за 24-48 годин до переїзду знизьте TTL для A-записів до 300 секунд. Це критично. Якщо залишите TTL 86400 (добу), частина відвідувачів ще день будуть потрапляти на старий сервер.
- Підготуйте VPS - встановіть ОС (Ubuntu 22.04 LTS або Debian 12 - золотий стандарт), веб-сервер, PHP, базу даних. Перевірте, що все працює на тестовій сторінці.
- Налаштуйте SSH-ключі - вимкніть вхід за паролем. Зараз. Не потім.
- Встановіть firewall - UFW або CSF. Відкрийте тільки порти 22, 80, 443. Все інше - закрити.
"Більшість невдалих міграцій стаються не через технічні проблеми, а через відсутність плану. Люди переносять файли і сподіваються, що все якось запрацює. Це як стрибати з парашутом, який ви не перевіряли." - Марк Стоун, DevOps-інженер DigitalOcean, виступ на ServerConf 2024
Сам процес переїзду: крок за кроком без паніки
Добре. VPS готовий, бекапи зроблені, TTL знижений. Тепер - сам переїзд. Я рекомендую робити це між 2:00 і 5:00 ранку вашого часового поясу. Так, це неприємно. Але трафік у цей час мінімальний, і навіть якщо щось піде не так, у вас буде кілька годин на виправлення.
Крок 1. Експортуйте базу даних зі старого хостингу:
mysqldump -u username -p database_name > backup.sql
Крок 2. Перенесіть файли через rsync (не FTP! rsync відновить перерваний трансфер):
rsync -avz -e ssh /path/to/files user@new-server:/var/www/site
Крок 3. Імпортуйте базу на новий сервер:
mysql -u username -p database_name < backup.sql
Крок 4. Оновіть конфігураційні файли сайту (wp-config.php для WordPress, .env для Laravel) - нові дані підключення до БД.
Крок 5. Перевірте сайт через IP-адресу або тимчасовий домен. Перейдіть по кожній критичній сторінці. Заповніть форми. Зробіть тестову покупку.
Крок 6. Змініть A-запис DNS на IP нового сервера. Чекайте. Тут починається найнервовіша частина - DNS-пропагація.
Не вимикайте старий сервер щонайменше 72 години після зміни DNS. Навіть з TTL 300 секунд деякі кешуючі DNS-резолвери ігнорують це значення. Тримайте старий хостинг як страхувальну сітку.
П'ять пасток, які підстерігають після переїзду
Ок, сайт працює на новому VPS. Здавалось би, можна святкувати? Не поспішайте. Перший тиждень після міграції - це мінне поле.
- Пермісії файлів. На shared-хостингу все працювало, бо провайдер налаштував права за вас. На VPS каталоги повинні мати права 755, файли - 644, а wp-config.php - 600. Невірні пермісії = злом за лічені години.
- Відсутній SSL. Let's Encrypt + Certbot - і через 5 хвилин у вас є сертифікат. Але не забудьте налаштувати автоматичне оновлення через cron.
- Email перестав працювати. Якщо ви використовували поштовий сервер старого хостингу - MX-записи досі вказують на нього. Або перенесіть пошту на VPS (що складно), або використайте зовнішній сервіс: Zoho Mail, Google Workspace, Fastmail.
- Cron-завдання не перенесені. Перевірте crontab -l на старому сервері. Я одного разу забув перенести cron для оновлення sitemap - і три тижні Google отримував застарілу карту сайту.
- Без моніторингу. Встановіть хоча б UptimeRobot (безкоштовний план - 50 моніторів) у перший же день. VPS не має служби підтримки, яка стежить за аптаймом замість вас.
Коли переїзд на VPS - погана ідея
Так. Я написав цю статтю про міграцію, і тепер кажу: іноді не треба їхати. Ось конкретні ситуації:
Якщо ваш сайт - це блог з 500 відвідувачами на місяць і ви не хочете вчити Linux, залишайтесь на shared. Або перейдіть на managed WordPress-хостинг (Kinsta, Cloudways, SiteGround). Ціна вища за звичайний shared, але нижча за VPS + адмін.
Якщо у вас немає бюджету на managed VPS і немає часу на адміністрування - unmanaged VPS стане не свободою, а в'язницею. Один невчасний sudo apt upgrade може покласти сервер, і рятувати його будете тільки ви.
VPS - це не про "крутіший хостинг". Це про готовність взяти відповідальність за інфраструктуру свого проєкту.
Ви готові о третій ночі в суботу розбиратися, чому Nginx повертає 502? Готові оновлювати пакети безпеки щотижня? Готові налаштовувати бекапи, які дійсно працюють, а не просто "десь є скрипт"? Якщо так - VPS дасть вам швидкість, контроль і масштабування, які shared ніколи не забезпечить.
Але якщо прочитавши все це ви відчуваєте тривогу - це нормально. І це означає, що варто почати з managed варіанту, де провайдер тримає руку на пульсі серверу, а ви фокусуєтесь на контенті та бізнесі. Головне - не залишайтесь на місці, коли ваш сайт вже задихається. Переїзд страшний тільки доки ви не зробили його вперше.