如何将所有 cPanel 账户从一台服务器迁移到另一台服务器
在服务器之间迁移所有 cPanel 账户是将每个托管域名、其文件、MySQL 数据库、电子邮件账户、DNS 区域、SSL 证书和 cron 任务从源 WHM 实例传输到目标 WHM 实例的过程——通常通过经过身份验证的 SSH 连接使用内置的 WHM Transfer Tool。正确执行时,此过程无需手动复制文件,并完整保留所有账户元数据。
本指南涵盖生产级别的完整迁移工作流程:预检、Transfer Tool 配置、DNS 切换策略、迁移后验证和清理——包括在实际环境中导致静默失败的边缘情况。
前提条件和迁移前检查清单
跳过准备工作是导致 cPanel 迁移失败或不完整的最常见原因。在操作任何一台服务器之前,请验证以下每一项。
两台服务器的 root 访问权限。 WHM Transfer Tool 通过 SSH 以 root 身份对源服务器进行身份验证。如果源服务器在 /etc/ssh/sshd_config 中设置了 PermitRootLogin no,您必须临时启用它,或为 root 预先配置基于 SSH 密钥的身份验证。
兼容的 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,并与源服务器 WHM 的 List Accounts 视图中显示的账户总磁盘使用量进行比较。
允许服务器间 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安装完成后,在 https://your-server-ip:2087 访问 WHM 并完成初始设置向导。特别注意以下几点:
- 主机名: 设置一个可解析到服务器 IP 的完全限定域名(FQDN)。无法解析的主机名会导致迁移后邮件投递失败。
- 域名服务器: 如果您计划在新服务器上托管 DNS,请配置域名服务器主机名及其 IP 地址。
- PHP 处理程序: 使用 WHM > MultiPHP Manager 安装与源服务器相同的 PHP 版本,以避免应用程序兼容性问题。
- MySQL/MariaDB 版本: 尽可能匹配源服务器的数据库引擎版本,或在迁移生产账户之前测试应用程序与新版本的兼容性。
对于管理多个客户端环境的团队,带 cPanel 的 VPS 提供预配置环境,完全省去手动安装阶段。
步骤 2:配置 WHM Transfer Tool
WHM Transfer Tool 是批量账户迁移的权威方法。它为每个账户原子性地处理打包、传输、解压和账户创建。
2.1 访问 Transfer Tool
在目标服务器上,登录 WHM 并导航至:
WHM > Transfers > Transfer Tool
这是一个让许多管理员感到困惑的关键点:Transfer Tool 始终从目标服务器运行,从源服务器拉取账户——而不是反过来。
2.2 连接到源服务器
输入以下连接详情:
- 远程服务器地址: 源服务器的 IP 地址或主机名
- 远程 SSH 端口: 默认为
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 区域以指向目标服务器的 IP,自动化 DNS 切换。这最大限度地缩短了域名解析到旧服务器的时间窗口。仅当目标服务器已准备好立即提供流量服务,且您已确认所有应用程序正常运行时,才使用此选项。
邮件路由: 除非您有特定原因强制本地或远程路由,否则将其设置为自动。不正确的邮件路由是迁移后电子邮件投递失败的首要原因之一。
2.5 启动迁移
点击 Copy 开始该过程。WHM 将:
- SSH 进入源服务器
- 运行
pkgacct为每个账户创建压缩存档 - 通过 SSH/SCP 将存档传输到目标服务器
- 在目标服务器上运行
restorepkg以解压并创建账户 - 记录每个账户的结果
仔细监控实时迁移日志。单个账户的错误不会停止整体过程——一个账户可能静默失败,而其他账户成功。迁移完成后查看完整日志,并单独重新运行失败的账户。
迁移持续时间取决于总数据量和服务器间带宽。在 1 Gbps 链路上,拥有 50 GB 账户数据的服务器通常在 30 分钟内完成。在 100 Mbps 链路上,预计需要 60–90 分钟。
步骤 3:DNS 切换策略
DNS 管理是迁移中最常造成长时间停机的环节。了解传播机制对于最大限度减少用户影响至关重要。
3.1 迁移前降低 TTL
理想情况下,在迁移前 24–48 小时,将所有托管域名的 A 记录 TTL 降低到 300 秒(5 分钟)。这确保一旦您更新 DNS 记录,变更将在几分钟内而非几小时内在全球传播。如果您事先没有这样做,则必须将现有 TTL 值作为最大传播窗口来考虑。
3.2 更新 DNS 区域
如果新服务器是域名的权威域名服务器,请通过 WHM > DNS Functions > Edit DNS Zone 更新每个区域文件中的 A 记录,将 IP 从旧服务器地址更改为新服务器地址。
如果域名使用外部 DNS 提供商或注册商 DNS,请登录每个注册商或 DNS 管理面板并手动更新 A 记录。对于跨多个域名的批量更新,大多数注册商提供 API 访问或 CSV 导入功能。
3.3 更新域名服务器胶水记录
如果您还在迁移域名服务器(例如 ns1.yourdomain.com),您必须在域名注册商处更新胶水记录——而不仅仅是区域文件。胶水记录是在其所服务的同一域名下注册的域名服务器的 IP 地址映射。未能更新胶水记录是一个常见疏漏,会导致所有托管域名的 DNS 解析完全失败。
3.4 验证传播
使用 dig 从多个地理位置检查解析情况:
dig A yourdomain.com @8.8.8.8
dig A yourdomain.com @1.1.1.1与基于 Web 的传播检查工具交叉验证。当 TTL 已预先降低时,完整的全球传播通常在 1–4 小时内完成;当 TTL 未提前降低时,最长可能需要 48 小时。
如果您的域名通过 域名注册注册,域名服务器更新可以直接从同一控制面板管理,简化切换过程。
步骤 4:迁移后验证
切勿仅凭 Transfer Tool 的成功日志就宣布迁移完成。独立验证堆栈的每一层。
4.1 Web 应用程序功能
通过 hosts 文件覆盖(绕过 DNS 传播)直接通过 IP 访问每个迁移的域名,并验证应用程序是否正确加载:
# Add to /etc/hosts on your local machine temporarily
203.0.113.50 yourdomain.com www.yourdomain.com检查数据库连接错误、缺失的文件路径和损坏的应用程序配置。如果 wp-config.php 数据库凭据引用了 localhost,但两台服务器之间的 MySQL socket 路径不同,WordPress 站点通常会失败。
4.2 数据库完整性
登录每个账户的 cPanel,验证数据库是否存在且可访问。对于关键数据库,运行完整性检查:
mysqlcheck -u root -p --all-databases --check4.3 电子邮件功能
测试每个账户的入站和出站电子邮件。验证 MX 记录是否正确解析,以及邮件服务器是否在端口 25、465 和 587 上接受连接。检查 /var/log/exim_mainlog 中的投递错误:
tail -f /var/log/exim_mainlog对于拥有专用邮件基础设施的企业,电子邮件托管提供隔离的邮件环境,不受 Web 服务器迁移的影响。
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 核心数)
- 内存使用率和交换活动
- 磁盘 I/O 等待(I/O 等待升高表明存储瓶颈)
- MySQL 慢查询日志,用于在新架构或引擎版本上性能较差的查询
使用 top、iostat 和 vmstat 进行实时监控,并查看 WHM 中 cPanel 的 Resource Monitor 以了解每个账户的资源消耗。
5.4 停用源服务器
在没有报告问题的最短 7 天观察期后,您可以停用源服务器。在终止旧服务器之前,将最终备份存档到冷存储。此存档作为法律和运营记录,保留成本极低。
cPanel 账户迁移:方法比较
| 方法 | 最适合 | 需要源服务器 Root 权限 | 保留所有数据 | 速度 | 风险级别 |
|---|---|---|---|---|---|
| — | — | — | — | — | — |
| WHM Transfer Tool | 完整服务器迁移、批量账户移动 | 是 | 是 | 快速(可并行迁移) | 低 |
| `pkgacct` / `restorepkg` | 单账户迁移、脚本化工作流程 | 是(源服务器) | 是 | 中等 | 低 |
| R1Soft / Acronis 镜像备份 | 完整服务器克隆到相同硬件 | 否(基于代理) | 是(完整磁盘) | 不定 | 中 |
| 手动 rsync + 数据库转储 | 自定义迁移、部分数据移动 | 否(SSH 用户即可) | 部分(需手动操作) | 慢 | 高 |
| 第三方迁移插件 | 特定 CMS 迁移(例如 WordPress) | 否 | 仅 CMS 数据 | 快速 | 中 |
常见陷阱及如何避免
账户迁移静默失败。 Transfer Tool 即使在单个账户失败时也会继续处理。务必阅读完整的迁移日志——不要因为工具完成而未停止就假设成功。
MySQL 用户权限不匹配。 restorepkg 会重新创建数据库用户,但如果数据库用户名超过 MySQL 的 32 字符限制(旧版账户中的常见问题),用户将以截断的名称创建,应用程序的数据库凭据将不再匹配。迁移前审查较长的数据库用户名。
Perl 模块和自定义软件依赖项。 依赖于自定义编译的 Perl 模块、Python 包或安装在 cPanel 管理路径之外的系统库的应用程序将不会被迁移。这些依赖项必须在目标服务器上手动重新安装。
磁盘配额差异。 cPanel 的磁盘配额系统使用文件系统级配额。迁移后,在配额重新计算脚本运行之前,配额可能无法准确反映:
/scripts/fixquotasModSecurity 规则冲突。 如果源服务器有自定义 ModSecurity 规则或与目标服务器不同的规则集版本,迁移的站点可能会收到意外的 403 错误。迁移后查看 /usr/local/apache/logs/error_log 中的 ModSecurity 日志。
经销商账户权限缺口。 经销商 ACL 和套餐分配会被迁移,但如果目标 WHM 配置了不同的功能列表,经销商可能会发现其账户的功能比预期少或不同。迁移后审查经销商配置。
对于停机容忍度接近零的高流量环境,考虑在拥有专用资源的独立服务器上运行迁移,消除迁移和验证阶段资源争用的风险。
技术决策矩阵
使用此矩阵根据环境特征确定您的迁移方法:
| 场景 | 推荐方法 |
|---|---|
| — | — |
| 少于 10 个账户,数据量小 | WHM Transfer Tool,单次迁移,手动 DNS 更新 |
| 10–100 个账户,流量级别混合 | 禁用 Express Transfer 的 WHM Transfer Tool;在 DNS 切换前验证 |
| 超过 100 个账户或总数据超过 500 GB | 按账户大小分批迁移;在非高峰时段迁移最大的账户 |
| 源服务器有非标准 SSH 端口或受限 root 登录 | 预先配置 SSH 密钥认证;在启动迁移前更新防火墙规则 |
| 关键任务应用程序,零停机要求 | 运行并行环境;使用应用层流量切换(负载均衡器或 DNS 故障转移) |
| 源 cPanel 版本明显旧于目标版本 | 先测试一个账户;在批量迁移前验证应用程序兼容性 |
常见问题
我可以在没有源服务器 root 访问权限的情况下迁移 cPanel 账户吗?
不可以。WHM Transfer Tool 需要对源服务器的 root SSH 访问权限才能运行 pkgacct 并读取所有账户数据。如果 root 访问不可用,唯一的替代方案是向源服务器管理员请求单个 cPanel 备份文件(.tar.gz 存档),并在目标服务器上使用 restorepkg 手动恢复它们。
完整的 cPanel 服务器迁移需要多长时间?
迁移时间取决于总数据量和服务器间的网络带宽。在 1 Gbps 专用链路上,拥有 100 GB 账户数据的服务器通常在 15–30 分钟内完成迁移。在共享或受限连接上,相同数据可能需要数小时。DNS 传播还需要额外 1–48 小时,具体取决于 TTL 值。
SSL 证书会自动迁移吗?
通过 AutoSSL(Let’s Encrypt)安装的 SSL 证书不会作为有效证书迁移——它们由目标服务器上的 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 服务)是否在目标服务器上手动复制。
