Як перенести всі облікові записи cPanel з одного сервера на інший

Міграція всіх облікових записів cPanel між серверами — це процес перенесення кожного розміщеного домену, його файлів, баз даних MySQL, облікових записів електронної пошти, DNS-зон, SSL-сертифікатів та завдань cron з вихідного екземпляра WHM до цільового екземпляра WHM — як правило, за допомогою вбудованого WHM Transfer Tool через автентифіковане SSH-з’єднання. При правильному виконанні цей процес не потребує ручного копіювання файлів і зберігає всі метадані облікових записів у цілості.

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

Передумови та контрольний список перед міграцією

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

Root-доступ на обох серверах. WHM Transfer Tool автентифікується на вихідному сервері через SSH як root. Якщо на вихідному сервері встановлено PermitRootLogin no у /etc/ssh/sshd_config, необхідно або тимчасово увімкнути його, або попередньо налаштувати автентифікацію SSH за ключем для root.

Сумісні версії cPanel/WHM. cPanel може переносити облікові записи зі старіших версій на новіші, але не навпаки. Цільовий сервер з cPanel 110 може отримувати дані з вихідного сервера з cPanel 98, але зворотне завершиться невдачею. Перевірте версії у WHM у розділі Server Information або виконайте:

cat /usr/local/cpanel/version

Відповідні або сумісні версії PHP та MySQL. Якщо на вихідному сервері встановлено PHP 7.4 та MySQL 5.7, а на цільовому — PHP 8.2 та MySQL 8.0, застосунки можуть перестати працювати після перенесення, навіть якщо файли скопіювалися коректно. Перевірте встановлені версії PHP та обробники за замовчуванням на обох серверах перед початком роботи.

Достатній дисковий простір на цільовому сервері. Transfer Tool потребує вільного місця, рівного щонайменше загальному стисненому розміру всіх облікових записів, що переносяться, плюс запас для розпакування. Виконайте df -h на цільовому сервері та порівняйте із загальним використанням дискового простору облікових записів, видимим у поданні List Accounts WHM на вихідному сервері.

Правила брандмауера, що дозволяють SSH між серверами. Цільовий сервер ініціює вихідне SSH-з’єднання до вихідного сервера. Переконайтеся, що порт 22 (або нестандартний SSH-порт) відкритий у брандмауері вихідного сервера для IP-адреси цільового сервера.

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

/scripts/pkgacct username /backup/directory

Якщо ви запускаєте нове середовище на плані VPS Hosting, переконайтеся, що ваш VPS має ліцензований та встановлений cPanel/WHM перед початком роботи. Для нової інсталяції cPanel потрібна дійсна ліцензія, прив’язана до IP-адреси сервера.

Крок 1: Встановлення та налаштування cPanel/WHM на цільовому сервері

Якщо cPanel ще не встановлено на цільовому сервері, запустіть офіційний інсталятор від імені root. Цей процес займає 20–45 хвилин залежно від апаратного забезпечення:

cd /home && curl -o latest -L https://securedownloads.cpanel.net/latest && sh latest

Після завершення встановлення отримайте доступ до WHM за адресою https://your-server-ip:2087 та завершіть початковий майстер налаштування. Зверніть особливу увагу на:

• Ім’я хоста: Встановіть повністю кваліфіковане доменне ім’я (FQDN), яке розпізнається до IP-адреси сервера. Ім’я хоста, яке не розпізнається, спричиняє збої доставки пошти після міграції.
• Сервери імен: Налаштуйте імена хостів серверів імен та їхні IP-адреси, якщо ви плануєте розміщувати DNS на новому сервері.
• Обробники PHP: Встановіть ті самі версії PHP, що доступні на вихідному сервері, використовуючи WHM > MultiPHP Manager, щоб уникнути проблем сумісності застосунків.
• Версія MySQL/MariaDB: По можливості відповідайте версії рушія бази даних вихідного сервера або перевірте сумісність застосунків з новішою версією перед міграцією виробничих облікових записів.

Для команд, що керують кількома клієнтськими середовищами, VPS з cPanel надає попередньо налаштоване середовище, що повністю усуває фазу ручного встановлення.

Крок 2: Налаштування WHM Transfer Tool

WHM Transfer Tool є авторитетним методом масової міграції облікових записів. Він атомарно обробляє пакування, перенесення, розпакування та створення облікових записів для кожного з них.

2.1 Доступ до Transfer Tool

На цільовому сервері увійдіть до WHM та перейдіть до:

WHM > Transfers > Transfer Tool

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

2.2 Підключення до вихідного сервера

Введіть наступні дані підключення:

• Remote Server Address: IP-адреса або ім’я хоста вихідного сервера
• Remote SSH Port: За замовчуванням 22; використовуйте фактичний порт, якщо його було змінено (перевірте /etc/ssh/sshd_config на вихідному сервері для директиви Port)
• Метод автентифікації: Root-пароль або SSH-ключ (автентифікація за ключем настійно рекомендується з міркувань безпеки та надійності)

Щоб використовувати автентифікацію SSH за ключем, скопіюйте публічний ключ root цільового сервера на вихідний:

ssh-copy-id -i /root/.ssh/id_rsa.pub -p 22 root@source-server-ip

Після підключення Transfer Tool запитує вихідний сервер і повертає список усіх облікових записів cPanel, пакетів та конфігурацій реселерів.

2.3 Вибір облікових записів та обсягу перенесення

Ви можете вибрати всі облікові записи або їх підмножину. Окрім окремих облікових записів, Transfer Tool також пропонує:

• Пакети: Перенесення визначень тарифних планів хостингу, щоб облікові записи зберегли свої розподіли ресурсів
• DNS-зони: Копіювання всіх файлів зон, що є обов’язковим, якщо новий сервер виступатиме авторитетним сервером імен
• Привілеї реселерів та ACL: Збереження конфігурацій облікових записів реселерів та пов’язаних з ними дозволів

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

Два параметри тут мають значний операційний вплив:

Express Transfer автоматизує переключення DNS, оновлюючи DNS-зони на вихідному сервері, щоб вони вказували на IP цільового сервера одразу після копіювання кожного облікового запису. Це мінімізує вікно, протягом якого домен розпізнається до старого сервера. Використовуйте це лише якщо цільовий сервер готовий обслуговувати трафік негайно і ви підтвердили, що всі застосунки функціонують.

Mail Routing: Встановіть значення Automatic, якщо у вас немає конкретної причини примусово встановлювати локальну або віддалену маршрутизацію. Неправильна маршрутизація пошти є однією з головних причин збоїв доставки електронної пошти після міграції.

2.5 Ініціювання перенесення

Натисніть Copy, щоб розпочати процес. WHM виконає:

1. SSH-підключення до вихідного сервера
2. Запуск pkgacct для створення стисненого архіву кожного облікового запису
3. Перенесення архіву на цільовий сервер через SSH/SCP
4. Запуск restorepkg на цільовому сервері для розпакування та створення облікового запису
5. Запис результату для кожного облікового запису

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

Тривалість перенесення залежить від загального обсягу даних та пропускної здатності між серверами. Сервер з 50 GB даних облікових записів через канал 1 Gbps зазвичай завершує перенесення менш ніж за 30 хвилин. Через канал 100 Mbps закладайте 60–90 хвилин.

Крок 3: Стратегія переключення DNS

Управління DNS — це місце, де міграції найчастіше спричиняють тривалі простої. Розуміння механіки поширення є важливим для мінімізації впливу на користувачів.

3.1 Зменшення TTL перед міграцією

В ідеалі, за 24–48 годин до міграції зменшіть TTL для всіх A-записів розміщених доменів до 300 секунд (5 хвилин). Це гарантує, що після оновлення DNS-записів зміна поширюється глобально протягом хвилин, а не годин. Якщо ви не зробили цього заздалегідь, необхідно врахувати існуюче значення TTL як максимальне вікно поширення.

3.2 Оновлення DNS-зон

Якщо новий сервер є авторитетним сервером імен для доменів, оновіть A-записи в кожному файлі зони через WHM > DNS Functions > Edit DNS Zone, змінивши IP зі старої адреси сервера на нову.

Якщо домени використовують зовнішнього DNS-провайдера або DNS реєстратора, увійдіть до кожного реєстратора або панелі управління DNS та оновіть A-записи вручну. Для масових оновлень по багатьох доменах більшість реєстраторів пропонують API-доступ або імпорт CSV.

3.3 Оновлення glue-записів серверів імен

Якщо ви також переносите сервери імен (наприклад, ns1.yourdomain.com), необхідно оновити glue-записи у реєстратора домену — а не лише файл зони. Glue-записи — це відображення IP-адрес для серверів імен, зареєстрованих під тим самим доменом, якому вони служать. Невиконання оновлення glue-записів є поширеним упущенням, що спричиняє повний збій розпізнавання DNS для всіх розміщених доменів.

3.4 Перевірка поширення

Використовуйте dig для перевірки розпізнавання з кількох географічних місць:

dig A yourdomain.com @8.8.8.8
dig A yourdomain.com @1.1.1.1

Перехресно перевірте за допомогою веб-інструменту перевірки поширення. Повне глобальне поширення зазвичай завершується протягом 1–4 годин, коли TTL було попередньо зменшено, або до 48 годин, коли TTL не було зменшено заздалегідь.

Якщо ваші домени зареєстровані через Domain Registration, оновленнями серверів імен можна керувати безпосередньо з тієї самої панелі управління, що спрощує процес переключення.

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

Ніколи не оголошуйте міграцію завершеною, спираючись виключно на журнал успішного виконання Transfer Tool. Перевіряйте кожен рівень стека незалежно.

4.1 Функціональність веб-застосунків

Отримайте доступ до кожного перенесеного домену безпосередньо за IP за допомогою перевизначення файлу hosts (щоб обійти поширення DNS) та переконайтеся, що застосунок завантажується коректно:

# Add to /etc/hosts on your local machine temporarily
203.0.113.50  yourdomain.com www.yourdomain.com

Перевірте наявність помилок підключення до бази даних, відсутніх шляхів до файлів та зламаних конфігурацій застосунків. Сайти WordPress зазвичай не працюють, якщо облікові дані бази даних wp-config.php посилаються на localhost, але шлях до сокета MySQL відрізняється між серверами.

4.2 Цілісність бази даних

Увійдіть до cPanel для кожного облікового запису та переконайтеся, що бази даних існують і доступні. Для критичних баз даних виконайте перевірку цілісності:

mysqlcheck -u root -p --all-databases --check

4.3 Функціональність електронної пошти

Перевірте вхідну та вихідну електронну пошту для кожного облікового запису. Переконайтеся, що MX-записи розпізнаються коректно і що поштовий сервер приймає з’єднання на портах 25, 465 та 587. Перевірте /var/log/exim_mainlog на наявність помилок доставки:

tail -f /var/log/exim_mainlog

Для підприємств з виділеною поштовою інфраструктурою, Email Hosting надає ізольовані поштові середовища, на які не впливають міграції веб-сервера.

4.4 Перевірка SSL-сертифікатів

Переконайтеся, що SSL-сертифікати перенеслися коректно та активні. У WHM перейдіть до SSL/TLS > Manage SSL Hosts та переконайтеся, що кожен домен має дійсний, не прострочений сертифікат. AutoSSL має автоматично перевипустити сертифікати Let’s Encrypt для тих, що не перенеслися, але запустіть його вручну, щоб не чекати запланованого запуску:

/usr/local/cpanel/bin/autossl_check --all

Якщо ви керуєте сертифікатами незалежно, SSL Certificates можна встановити безпосередньо на новому сервері без залежності від процесу перенесення.

4.5 Завдання Cron та заплановані задачі

Завдання Cron переносяться як частина пакету облікового запису, але перевірте їх у cPanel > Cron Jobs для кожного облікового запису. Зверніть особливу увагу на завдання cron, що посилаються на абсолютні шляхи до файлів або специфічні для сервера змінні середовища, які можуть відрізнятися на новому сервері.

Крок 5: Очищення та зміцнення безпеки після міграції

5.1 Призупинення облікових записів на вихідному сервері

Після поширення DNS та завершення перевірки призупиніть усі облікові записи на вихідному сервері через WHM > List Accounts > Suspend. Не видаляйте їх поки що. Призупинення запобігає запису нових даних на вихідний сервер, зберігаючи його доступним як резервний варіант, якщо після міграції виникне критична проблема.

5.2 Резервне копіювання після міграції

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

/scripts/cpbackup --force

Переконайтеся, що резервні копії успішно завершуються та зберігаються в місці, окремому від самого сервера — в ідеалі в зовнішньому місці призначення резервних копій, налаштованому в WHM > Backup Configuration.

5.3 Моніторинг продуктивності

Відстежуйте використання ресурсів нового сервера протягом 72 годин після міграції. Ключові метрики для спостереження:

• Середнє навантаження CPU (при нормальному навантаженні має залишатися нижче кількості ядер CPU)
• Використання пам’яті та активність swap
• Час очікування дискового I/O (підвищений час очікування I/O вказує на вузькі місця сховища)
• Журнал повільних запитів MySQL для запитів, що погано виконуються на новій схемі або версії рушія

Використовуйте top, iostat та vmstat для моніторингу в реальному часі та перегляньте Resource Monitor cPanel у WHM для споживання ресурсів по кожному обліковому запису.

5.4 Виведення з експлуатації вихідного сервера

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

Міграція облікових записів cPanel: порівняння методів

Поширені помилки та як їх уникнути

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

Невідповідність привілеїв користувачів MySQL. restorepkg відтворює користувачів бази даних, але якщо ім’я користувача бази даних перевищує 32-символьний ліміт MySQL (поширена проблема зі застарілими обліковими записами), користувач створюється з усіченим ім’ям і облікові дані бази даних застосунку більше не збігаються. Перевірте довгі імена користувачів бази даних перед міграцією.

Залежності модулів Perl та нестандартного програмного забезпечення. Застосунки, що покладаються на нестандартно скомпільовані модулі Perl, пакети Python або системні бібліотеки, встановлені поза керованими шляхами cPanel, не перенесуться. Ці залежності необхідно встановити вручну на цільовому сервері.

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

/scripts/fixquotas

Конфлікти правил ModSecurity. Якщо на вихідному сервері були нестандартні правила ModSecurity або інша версія набору правил, ніж на цільовому, перенесені сайти можуть отримувати несподівані помилки 403. Перегляньте журнали ModSecurity за адресою /usr/local/apache/logs/error_log після міграції.

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

Для середовищ з високим трафіком, де допустимість простою близька до нуля, розгляньте можливість виконання міграції на Dedicated Server з виділеними ресурсами, що усуває ризик конкуренції за ресурси під час фаз перенесення та перевірки.

Матриця технічних рішень

Використовуйте цю матрицю для визначення підходу до міграції на основі характеристик середовища:

FAQ

Чи можна мігрувати облікові записи cPanel без root-доступу до вихідного сервера?

Ні. WHM Transfer Tool потребує root SSH-доступу до вихідного сервера для запуску pkgacct та читання всіх даних облікового запису. Якщо root-доступ недоступний, єдиною альтернативою є запит окремих файлів резервних копій cPanel (архівів .tar.gz) від адміністратора вихідного сервера та їх ручне відновлення за допомогою restorepkg на цільовому сервері.

Скільки часу займає повна міграція сервера cPanel?

Час перенесення залежить від загального обсягу даних та пропускної здатності мережі між серверами. Сервер зі 100 GB даних облікових записів через виділений канал 1 Gbps зазвичай переноситься за 15–30 хвилин. Через спільні або обмежені з’єднання ті самі дані можуть займати кілька годин. Поширення DNS додає ще 1–48 годин залежно від значень TTL.

Чи переносяться SSL-сертифікати автоматично?

SSL-сертифікати, встановлені через AutoSSL (Let’s Encrypt), не переносяться як дійсні сертифікати — вони перевипускаються AutoSSL на цільовому сервері, оскільки прив’язані до IP-адреси сервера та облікового запису. Комерційно придбані сертифікати, збережені в cPanel, переносяться як частина пакету облікового запису, але їх необхідно перевірити та повторно активувати після міграції.

Що відбувається з електронною поштою на старому сервері під час вікна міграції?

Електронна пошта, доставлена на старий сервер під час вікна міграції, зберігається в черзі пошти та поштових скриньках старого сервера. Вона не реплікується автоматично на новий сервер. Щоб запобігти втраті пошти, або тримайте поштові служби старого сервера запущеними до повного поширення DNS, або налаштуйте Exim старого сервера для ретрансляції вхідної пошти на IP нового сервера протягом перехідного періоду.

Чи може WHM Transfer Tool мігрувати облікові записи між різними операційними системами (наприклад, з CentOS на AlmaLinux)?

Так. Transfer Tool є незалежним від ОС на рівні застосунку — він переносить дані облікових записів cPanel, а не конфігурації рівня ОС. Міграції з CentOS 7 на AlmaLinux 8 або Rocky Linux 8 повністю підтримуються і є найпоширенішим сценарієм міграції після закінчення терміну підтримки CentOS 7. Переконайтеся, що будь-які нестандартні конфігурації системного рівня (політики SELinux, нестандартні модулі ядра, служби поза cPanel) вручну відтворені на цільовому сервері.