Как да преместите всички 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 Хостинг, потвърдете, че вашият 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 и завършете началния съветник за настройка. Обърнете особено внимание на:

• Hostname: Задайте напълно квалифицирано домейн име (FQDN), което се разрешава до IP адреса на сървъра. Неразрешимо hostname причинява грешки при доставка на поща след миграция.
• Nameservers: Конфигурирайте имената на вашите nameserver хостове и техните IP адреси, ако планирате да хоствате DNS на новия сървър.
• PHP handlers: Инсталирайте същите версии на 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 адрес или hostname на изходния сървър
• Remote SSH Port: По подразбиране е 22; използвайте действителния порт, ако е бил променен (проверете /etc/ssh/sshd_config на изходния сървър за директивата Port)
• Authentication method: 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 предлага и:

• Packages: Прехвърляне на дефиниции на хостинг планове, така че акаунтите да запазят своите разпределения на ресурси
• DNS Zones: Копиране на всички zone файлове, което е от съществено значение, ако новият сървър ще действа като авторитативен nameserver
• Reseller Privileges and ACLs: Запазване на конфигурациите на акаунтите на препродавачи и свързаните с тях разрешения

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 зони

Ако новият сървър е авторитативният nameserver за домейните, актуализирайте A записите във всеки zone файл чрез WHM > DNS Functions > Edit DNS Zone, като промените IP адреса от адреса на стария сървър към новия.

Ако домейните използват външен DNS доставчик или DNS на регистратора, влезте в панела за управление на всеки регистратор или DNS и актуализирайте A записите ръчно. За масови актуализации на много домейни, повечето регистратори предлагат API достъп или CSV импорт.

3.3 Актуализиране на Glue записи на Nameserver

Ако мигрирате и nameserver-и (напр. ns1.yourdomain.com), трябва да актуализирате glue записите при регистратора на домейна — не само zone файла. Glue записите са IP адресни съпоставяния за nameserver-и, регистрирани под същия домейн, който обслужват. Пропускането на актуализацията на 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 не е бил намален предварително.

Ако вашите домейни са регистрирани чрез Регистрация на домейни, актуализациите на nameserver могат да се управляват директно от същия контролен панел, опростявайки процеса на прехвърляне.

Стъпка 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 socket се различава между сървърите.

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

За бизнеси с dedicated пощенска инфраструктура, Имейл хостинг предоставя изолирани пощенски среди, които не се влияят от миграции на уеб сървъри.

4.4 Проверка на SSL сертификати

Потвърдете, че SSL сертификатите са прехвърлени правилно и са активни. В WHM навигирайте до SSL/TLS > Manage SSL Hosts и проверете дали всеки домейн има валиден, неизтекъл сертификат. AutoSSL трябва автоматично да преиздаде Let’s Encrypt сертификати за тези, които не са се прехвърлили, но го стартирайте ръчно, за да избегнете изчакване на планираното изпълнение:

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

Ако управлявате сертификати независимо, SSL сертификати могат да бъдат инсталирани директно на новия сървър без зависимост от процеса на прехвърляне.

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 сървър с dedicated ресурси, елиминирайки риска от конкуренция за ресурси по време на фазите на прехвърляне и валидиране.

Матрица за технически решения

Използвайте тази матрица, за да определите подхода си за миграция въз основа на характеристиките на средата:

ЧЗВ

Мога ли да мигрирам cPanel акаунти без root достъп до изходния сървър?

Не. WHM Transfer Tool изисква root SSH достъп до изходния сървър, за да изпълни pkgacct и да прочете всички данни на акаунтите. Ако root достъпът не е наличен, единствената алтернатива е да поискате отделни cPanel резервни файлове (.tar.gz архиви) от администратора на изходния сървър и да ги възстановите ръчно, използвайки restorepkg на целевия сървър.

Колко дълго отнема пълната миграция на cPanel сървър?

Времето за прехвърляне зависи от общия обем данни и мрежовата честотна лента между сървърите. Сървър със 100 GB данни на акаунти при dedicated 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 е OS-агностичен на ниво приложение — той прехвърля данни на cPanel акаунти, а не конфигурации на ниво OS. Миграциите от CentOS 7 към AlmaLinux 8 или Rocky Linux 8 са напълно поддържани и са най-честият сценарий за миграция след края на живота на CentOS 7. Проверете дали всички персонализирани конфигурации на системно ниво (SELinux политики, персонализирани kernel модули, услуги извън cPanel) са ръчно репликирани на целевия сървър.