Как перенести все аккаунты 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 ГБ данных аккаунтов при канале 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)
• Использование памяти и активность подкачки
• Ожидание дискового ввода-вывода (повышенное ожидание 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 ГБ данных аккаунтов при выделенном канале 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) вручную воспроизведены на целевом сервере.