网站搬家最怕的不是停机，而是搬完之后发现数据不一致：某个数据库文件传输中断了、某张图片没有同步过去、新旧服务器上的文件权限对不上。如何解决这些问题？核心结论是：只要用对 rsync（远程同步工具）的几个关键参数，把”校验”和”续传”内建到迁移流程里，你就能把数据迁移从”碰运气”变成可验证、可中断重来的标准操作。这篇文章会带你走完从预同步、正式切换到迁移后验证的完整流程，每一步都给出可以直接复用的命令。
为什么迁移服务器数据首选 rsync 增量同步
服务器迁移的常见做法有三种：打包 tar 后整包传输、FTP 逐个文件下载上传、rsync 增量同步。前两种在数据量小的时候问题不大，但一旦站点文件超过几个 GB，缺点就会暴露出来：tar 整包传输中途断线就要从头再来；FTP 既不校验内容也不保留权限，搬完后经常出现图片 403、脚本无法执行的问题。
rsync 的思路完全不同。它先对比源端和目标端文件的大小与修改时间（加 --checksum 后还会逐字节比对校验值），只传输有差异的部分。一个 10GB 的站点目录，如果第二次同步时只有 200MB 的文件发生了变化，实际传输量就是这 200MB。这意味着你可以放心地反复执行同一条同步命令：中断了重跑、切换前再跑一遍兜底，成本都很低。
对于网站数据迁移来说，这种特性带来两个直接好处。第一，预同步可以在业务不中断的情况下提前完成 90% 以上的传输工作，真正停机切换时只需要增量补一次差量，停机窗口从小时级压缩到分钟级。第二，每一次同步都是一次完整的对账，源端有而目标端没有的文件会被补齐，两边都有的文件会被校验，不需要你手工核对成千上万个文件。
如果你正准备把站点搬到新的 VPS（Virtual Private Server，虚拟专用服务器）主机或独立服务器上，下面的参数配置和流程可以直接套用。
一致性校验：别让”看起来传完了”骗过你
rsync 默认使用”快速检查”：只要文件大小和修改时间一致，就认为两边相同，跳过传输。这在大多数场景下够用，但在迁移这种不容出错的场景里，有一个经典坑：某些文件系统的时间戳精度不同，或者传输过程中文件被改动过，快速检查会误判”已同步”。等业务切换过去才发现数据不一致，排查起来非常痛苦。
解决方法是让 rsync 做真正的内容校验：
rsync -avzc --delete /var/www/html/ root@new-server:/var/www/html/这里的 -c（即 --checksum）会让 rsync 对每个文件计算校验和再决定是否传输。代价是需要读取两边所有文件的内容，速度慢于默认模式，所以我们建议把它用在迁移收尾的”对账”阶段，而不是每一次同步。实际操作节奏是：平时用快速模式反复增量同步，最后切换前用 -c 跑一次全量校验，确认两边完全一致后再改 DNS（Domain Name System，域名系统）解析。
判断校验是否通过也有明确的信号：命令执行结束后 rsync 会输出本次传输的文件数量与字节数，收尾校验那次如果列表为空、只剩目录项扫描，说明没有差异文件。对要求更严的场景，可以在新旧两台服务器上分别对同一目录树计算哈希并比对：
find /var/www/html -type f -exec md5sum {} \; | sort > /tmp/site.md5
# 新旧服务器各执行一次，diff 两个清单文件即可定位差异文件这种方式多花几分钟，但能把”大概没问题”变成”逐文件确认一致”，特别适合订单数据、用户上传文件这类不能出错的内容。
断点续传与限速：应对不稳定网络和大文件
跨境迁移或网络质量一般的环境里，几个 GB 的大文件传到 80% 断线是最常见的场景。rsync 默认会把未传完的文件直接删掉重来，相当于断点作废。加上 --partial 参数后，传了一半的文件会被保留，下次同步从这个文件的差量位置继续，而不是整个文件重传。配合 --progress 还能实时看到每个文件的传输进度。
--bwlimit 限速，例如 --bwlimit=20000 限制为每秒 20MB，避免同步流量挤占正常访客可用的带宽（单位时间内可传输的数据容量）。把这些参数组合起来，一条适合长距离迁移的命令如下：
rsync -avzP --partial --bwlimit=20000 -e "ssh -p 22" \
/home/backup/site/ root@new-server:/home/backup/site/其中 -P 等价于 --partial --progress。迁移数据库场景下还有一点要特别注意：正在写入的数据库文件（如 InnoDB 的数据文件）直接同步可能得到一个损坏的副本。正确做法是同步前先停止数据库服务或执行一次完整的逻辑导出，等文件静止后再同步（自建 Git 仓库与代码发布的配套做法可参考 Gitea 部署与自动发布）。我们建议的顺序是：先同步静态文件和代码，数据库导出文件单独打包传输，校验通过后再在新服务器导入。
对于虚拟主机用户没有 SSH 权限的情况，可以退而求其次用面板的文件打包功能先导出，再在具备 rsync 条件的中转环境里完成后续增量同步；如果你在选型阶段，可以了解 Hostease 虚拟主机方案是否带 SSH 功能，这会直接影响迁移工具的选择空间。
完整迁移流程：从预同步到切换验证
把前面两个环节串起来，一次可回滚的服务器迁移分为五个阶段。核心思路是”先赶量、再对账、后切换”：
- 预同步（业务不中断）：用快速模式做第一次全量传输，这一步耗时最长，可能有几十分钟到几小时，但因为不影响线上服务，可以慢慢跑。
- 反复增量：之后每隔一段时间重跑同一条命令，每次只传输变化的文件，让新服务器的数据持续追平源端。
- 收尾对账：宣布维护窗口前，用
--checksum模式做最终校验，必要时用 md5 清单逐文件比对。 - 切换：短暂停止源站服务（防止切换期间再产生新数据），最后增量同步一次，然后修改 DNS 解析指向新服务器。
- 验证与保留回滚：解析生效后检查页面、登录、下单等核心流程，源服务器数据保留至少一周再做下线处理。
迁移后的验证别只看首页能打开。至少检查这几项：文件权限和属主是否正确（-a 参数会保留权限，但如果新旧服务器的运行用户不同，需要在新服务器上执行 chown 调整）；crontab -l 的定时任务是否已经迁移；PHP 版本、数据库版本等运行环境是否与代码兼容；HTTPS 证书是否已经部署并正常续期。此外，源服务器上 crontab 里的定时备份任务也要在新服务器重建，否则迁移一周后你会发现备份悄悄断掉了。
如果你想系统了解迁移前的准备工作与服务器初始化，可以参考我们之前整理的 静态网站部署 完整流程，其中服务器准备部分与迁移是同一套思路。
常见问题与排查思路
实际迁移中，以下几个问题出现频率最高，对应的排查方法都比较直接：
- 同步时报 “rsync: connection unexpectedly closed”：多数是 SSH 端口不通或密钥未配置。先用
ssh -p 端口 root@新服务器手工测试连通性，确认免密登录正常后再跑 rsync。 - 目标端出现大量带
.~tmp~前缀的残留文件：这是--partial的临时文件，属于正常现象，下次同步会自动续用；切换完成后可安全清理。 - 同步后网站图片 403、脚本无法执行：通常是文件权限问题。检查新旧服务器运行 Web 服务的用户是否一致，不一致时在新服务器上批量
chown -R www:www /var/www/html。 - 传输速度远低于带宽上限：先确认是否加了
-z压缩（对已压缩文件反而降速），再检查是否触发了--bwlimit限速值。 - 定时备份任务在迁移后失效：服务器选型阶段就应该确认备份与运维能力是否齐备，可参考这份 服务器配置与优化 分类下的实践文章。
还有一个容易被忽略的细节：rsync -a 会同步软链接本身而不是链接指向的内容。如果你的站点目录里存在指向站点外的软链接，同步过去之后这些链接可能是断的。用 -L 参数可以把链接指向的真实文件同步过去，按实际情况选择。
总结：把迁移做成可验证的流程
回顾一下整篇文章的核心：rsync 增量同步之所以适合服务器数据迁移，是因为它把”只传差异”、”内容校验”、”断点续传”三件事内建进了同一条命令。-a 保留属性、-z 压缩传输、-c 内容级校验、--partial 断点续传、--bwlimit 保护线上带宽，这几个参数组合起来，配合”预同步 → 增量追平 → 收尾对账 → 切换 → 验证”的五阶段流程，迁移失败的风险就被压缩到了很小的范围。
我们的建议是：不管站点规模大小，都先在测试目录上完整演练一遍这条流程，确认每个阶段的行为符合预期，再对生产数据动手。如果你需要一台数据盘充裕、网络稳定的新服务器作为迁移目标，可以考虑 Hostease 的 VPS 主机 或 独立服务器 方案，并让机房协助确认迁移期间的带宽与工单支持；迁移前多做一次备份校验，永远比迁移后补救数据便宜得多。