服务器迁移怎么做？整机搬家的完整流程与三个必踩的坑

服务器迁移怎么做？整机搬家的完整流程与三个必踩的坑

换云、换机房、把老物理机搬上云——服务器迁移这件事听起来就是"把数据拷过去"，真做起来才发现，麻烦的从来不是拷贝，是拷完之后那一堆"为什么起不来"。

我把整机迁移的完整过程跑了一遍，包括几个只有踩过才知道的细节。

先分清楚一件事：你要迁的到底是"数据"，还是"整台机器"。这两件事的做法完全不同，混着做会浪费大量时间。

一、两条路：文件级迁移 vs 整机迁移（服务器迁移方案）

判断标准很简单：如果能在一台新机器上从零把服务重新跑起来，就走文件级；如果说不清这台机器上到底装过什么、改过什么配置，老老实实走整机迁移。

后者就是本文要讲的。

二、服务器迁移用多久？先算时间，再排窗口

排停机窗口之前，先把传输时间算出来，别拍脑袋。

迁移工具给出的估算逻辑是：

剩余同步时间 = (总数据量 – 已传输数据量) / 传输速度

这里有个容易看错的地方：控制台显示的速度是压缩前的数据量速度。如果你在创建任务时设了压缩率，显示速度会高于实际的网线传输速度——所以别拿显示速度去反推带宽够不够。

影响时间的主要是三个变量：

• 数据量：这是大头，先看源机实际用了多少（不是磁盘标称容量）
• 带宽：源服务器出网带宽通常是瓶颈
• 压缩率：CPU 换带宽，源机 CPU 有余量时可以开高一点

我的建议是：先做一次演练，拿到真实速度再定窗口。迁移工具一般都带演练功能，演练会提前暴露驱动、分区、权限这些真问题，比事后救火便宜太多。

如果演练出来速度实在不够，临时提一下源机和目标机的固定带宽是最直接的办法。

三、服务器整机迁移的完整流程

以阿里云的服务器迁移中心（SMC）为例，整机迁移一共四步。工具本身免费，但迁移过程中会用到少量中转资源，这部分是按量计费的。

👉 服务器迁移中心 SMC　|　SMC 控制台　|　SMC 官方文档

第一步：准备账号与源机环境

1、准备一个专用的 RAM 子账号，只给它迁移需要的权限，别用主账号的 AccessKey。这是最容易被忽略、也最不该省的一步。

2、在源机上检查两样东西：

• rsync 在不在。多数主流系统是预装的，没有的话客户端会提示你装。
• SELinux 是不是开着。开着的话客户端会提示禁用。

3、确认源机磁盘实际使用量，目标机的系统盘必须大于这个数——不是大于磁盘容量，是大于实际数据量。

第二步：导入迁移源

在源服务器上下载并运行迁移客户端：

wget https://p2v-tools.oss-cn-hangzhou.aliyuncs.com/smc/Alibaba_Cloud_Migration_Tool.zip
unzip Alibaba_Cloud_Migration_Tool.zip

解压出来会有多个平台的包，按 uname -a 的结果挑对应的那个（Linux x86_64 通常选 go2aliyun_client*_linux_x86_64）：

unzip go2aliyun_client2.x.x_linux_x86_64.zip
cd go2aliyun_client2.x.x_linux_x86_64
chmod +x go2aliyun_client
./go2aliyun_client

运行后按提示输入凭证。这里有两种方式：

• 激活码（推荐）：在控制台生成，一次性、可设有效期，用完即弃
• AccessKey：长期凭证，泄露风险高

导入成功的回显长这样：

Import Source Server [s-bp1xxxxxxxxxxx] Successfully!

看到这行，控制台的迁移源列表里才会出现这台机器，且状态为在线——不在线是没法建迁移任务的。

第三步：控制台创建迁移任务

1、在迁移源列表里找到刚导入的机器，点「创建迁移任务」。

2、目标类型有三个选项，选错会很麻烦：

3、几个值得调的参数：

• 迁移演练：开。演练会提前把驱动、分区、权限的问题报出来
• 压缩率：源机 CPU 有余量就开高，用 CPU 换时间
• 传输限速：迁移不能把业务带宽吃干净，限一下
• Checksum 验证：开着，牺牲一点时间换数据完整性

4、一个容易出错的选项：块复制。

• 开着：传输速率稳、分区结构一致，但不能调整目标分区大小
• 关掉：可以调整目标分区大小

Linux 上想缩盘，就必须关掉它。另外如果源机的快照驱动没装成功，也得关掉块复制，否则任务会失败。

第四步：验证

任务状态变成「已完成」之后，别急着切流量。

• 目标类型是镜像 → 用镜像开一台新实例，登上去看服务起不起来
• 平台一般也提供自动验证，会用编排模板自动开一台实例验证能不能正常启动

验证这一步省不得。我见过迁完状态显示成功、结果登上去服务起不来的情况。

四、三个必踩的坑

坑一：迁移途中把客户端关了

这是最高频的翻车方式，没有之一。

客户端一旦关闭，迁移源就和控制台断开了，迁移任务直接失败。所以：

• 别在 SSH 里前台跑完就关终端，用 screen / tmux 挂着
• 别在迁移过程中重启源机
• 客户端日志一般在安装目录的 Logs 下（默认安装目录通常是 /root/smc/），出问题先看这里

坑二：迁完之后 IP 变了

这个坑不复杂，但一定会被忘。

迁移后新机器的公网 IP 是新的，所以：

• 配置文件里写死的 IP（数据库连接串、内网服务地址、白名单）要改
• 域名要重新解析到新 IP
• DNS 的 TTL 要提前调小。迁移前一天把 TTL 调到几分钟，切的时候才能快速生效；否则用户那边可能缓存一两天

坑三：迁移出错后，中转资源还在计费

迁移过程中会在目标账号下自动创建一台临时中转实例（按量付费）和一块中转云盘。

• 迁移成功 → 中转实例会自动释放，不用管
• 迁移出错 → 中转实例不会自动释放，会一直挂着产生费用

所以任务报错之后，要么修完点「重试」（系统会从上次中断的地方继续），要么确认不用了就去手动清理迁移任务，把中转实例释放掉。这个不处理，几天下来账单会很难看。

五、迁完之后必须检查的几件事

• 数据完整性：文件数量、数据库记录数对一遍，别只看服务起来了
• 服务能不能起：尤其是开机自启的服务，迁移后经常丢失
• 时间与时区：跨地域迁移时容易错，日志时间对不上会误导后续排查
• 商业软件的授权：部分授权绑定硬件指纹，换机器后会失效，迁移前先确认
• 监控与备份：新机器别忘记重新挂上

六、什么时候不该做整机迁移

说清楚边界，免得用错力气：

• 只是迁一个网站 → 重新部署 + 导数据库更快，整机迁移是把整个系统的问题一起搬过来。目标机可以直接用 轻量应用服务器 起一个新的，比搬一台老的干净得多；要是本来就打算上生产环境，那就看 云服务器 ECS
• 源系统太老（比如已经停止维护的老版本） → 别迁，借这个机会重装，否则老问题一个不少地跟过来
• 源机上有硬件绑定的授权 → 迁过去大概率失效，先跟授权方确认
• 你有完整的部署文档和自动化脚本 → 走"新建 + 部署"，不要走"复制"。复制出来的是一台没人敢碰的黑盒

顺序总结一下：先演练拿速度 → 算窗口 → 迁 → 验证 → 切流量 → 清理中转资源。

迁移这事的难点从来不是"能不能拷过去"，而是拷过去之后还有一堆状态要收拾。把上面三个坑提前处理掉，剩下的基本就是等传输进度条走完。

说明：文中涉及的产品能力、参数选项、计费规则均为发文时信息，具体以产品官网当期文档与控制台显示为准。 说明：文中链接为官方地址，介意者可自行进入官网搜索对应页面。