把网站、数据库备份或业务数据从一台服务器搬到另一台，最怕的不是速度慢，而是搬完之后数据对不上：文件数量不一致、部分文件还是旧版本、权限丢失导致服务启动失败。rsync 正是解决这类问题的标准工具——它只传输源端与目标端的差异部分，支持加密通道、断点续传和基于内容的校验，是服务器之间数据搬迁与同步的可靠方案。这篇教程会按照真实迁移的顺序，带你完成从环境准备、首次全量传输、增量同步到最终一致性校验的完整流程。
为什么数据搬迁首选 rsync：增量传输的工作原理
先理解 rsync（远程同步工具）的工作方式，后面的参数选择才有依据。rsync 的核心机制是增量传输：它在传输前把源文件按块计算校验和，与目标端已有文件的校验和对比，只传输发生变化的块，而不是整个文件。举例来说，一个 20 GB 的数据库备份文件只改动了 100 MB，第二次同步时 rsync 只传输这 100 MB 对应的数据块，在跨机房带宽（比如 100 Mbps）环境下，耗时可能从 30 分钟级降到分钟级。
与 cp 或 scp 相比，rsync 的优势可以概括为三点，每一点都直接影响迁移结果：
- 只传差异块，重复执行不会重复传输全量数据，适合分批迁移和演练
- 原生保留权限、属主、属组、时间戳和软链接，搬完即可启动服务
- 支持
--delete、--exclude、--checksum等开关，可以精确控制目标端状态
如果目标只是临时拷贝几个小文件，scp 足够；但凡涉及整站目录、需要反复同步或要求迁移后文件属性不变，rsync 都是更稳妥的选择。如果你还在规划整个迁移项目，建议先读一读网站迁移 DNS 切换方案，把数据搬运和 DNS（域名解析系统）切换的时序安排好，避免新旧服务器数据分叉。
迁移前准备：账号、端口与目录基线
正式传输前要确认三件事：SSH（安全外壳协议）访问、磁盘空间和目录基线。假设源服务器为旧机器，目标服务器为新机器，操作账号建议直接使用 root，或至少是一个对数据目录有读权限、对目标目录有写权限的账号——rsync 保留属主信息时，需要相应权限才能在目标端写入 chown 结果，普通账号同步 root 文件会报 chown failed 或静默丢失属主。
在源服务器上先验证连通性与空间，这一步能拦住大部分低级错误：
ssh -p 22 root@新服务器IP date：确认 SSH 端口与密钥可用，时间输出一致也顺带排除了时钟漂移df -h /data /：分别确认源端待迁目录和新服务器目标分区的可用空间，目标空间应大于源目录实际占用du -sh /data/www：记录源目录基线大小和文件数（find /data/www | wc -l），迁移后的校验要拿这两个数对比
密钥认证建议提前配好。用 ssh-keygen -t ed25519 在源端生成密钥对，把公钥追加到目标端 /root/.ssh/authorized_keys，可以避免 rsync 每次交互式询问密码，也让 cron 自动化同步成为可能。端口如果不是默认 22，rsync 要用 -e "ssh -p 2222" 显式指定。
首次全量迁移：推荐命令与参数逐项解释
环境确认后，先做首次全量传输。下面这条命令是服务器之间目录搬迁的主力形态，建议原样保存到迁移工单里：
rsync -avzP --partial --delete \
-e "ssh -p 22" \
--exclude='*.tmp' --exclude='cache/' \
/data/www/ root@新服务器IP:/data/www/
每个参数都对应一个迁移需求，理解之后才能按场景增删：
-a归档模式，等价于-rlptgoD，递归保留权限、时间戳、属主、属组和软链接，是”搬完即用”的关键-v输出同步文件清单，-z传输时压缩，跨机房公网传输能明显减少流量，内网迁移可以去掉-P是--progress --partial的合体：显示进度，且中断后保留已传部分，重跑时从断点附近继续，不必从零开始--delete让目标端删除源端已不存在的文件，使两端目录完全一致；首次迁移目标为空目录时它无实际作用，但演练和正式切换阶段必须带上- 源路径写
/data/www/（末尾斜杠）表示同步目录内容到目标目录；写成/data/www会在目标下多套一层www，这是 rsync 最常见的路径陷阱
排除规则在这个阶段就要定稿。--exclude='cache/' 跳过缓存目录，--exclude='*.log' 跳过日志；规则较多时改用 --exclude-from='/root/rsync-exclude.txt'，一行一条，纳入版本管理，避免每次手敲遗漏。对于数据库文件，正确做法是先在源端 mysqldump 导出 SQL 或停写后打包，再同步这份一致性快照，直接同步正在写入的 .ibd 文件极易得到损坏副本。
全量传输耗时取决于数据量和带宽。100 GB 数据在 100 Mbps 带宽（约 12.5 MB/s）下理论上需要 2 小时出头，实际加上加密和小文件开销会更长。建议把首次全量安排在业务低峰，并在 screen 或 tmux 会话中执行，SSH 断线不会杀死传输进程。
增量同步与正式切换：收敛数据差异
首次全量完成后不要急着切换服务，因为业务还在往旧服务器写数据。正确的节奏是”全量打底、增量收敛、停写后终同步”：切换窗口前每隔一段时间跑一次同样的 rsync 命令，每次只传输这段时间内变化的文件；到正式切换窗口，先在旧服务器停应用或设为只读，再执行最后一次同步并带上 --delete，确保新服务器上的数据与停写时刻完全一致。每次增量重跑都是幂等的——已一致的文件会被跳过，命令本身不需要任何修改。
最后这次终同步建议加上 -c（--checksum）：默认情况下 rsync 用”大小 + 修改时间”判断文件是否变化，速度快；但两端时钟不同步等少数场景会出现漏判。-c 改为对两端文件整份计算校验和，更严格但更耗时，适合只在最终校验这一次使用，不适合每天例行同步。
切换窗口内还要同步处理两件容易被遗忘的事：一是 crontab 定时任务，用 crontab -l > cron-backup.txt 导出后在新服务器恢复；二是服务配置与防火墙规则，例如 Nginx 站点配置、SELinux 上下文。切换完成、DNS 指向新服务器后，保持旧服务器只读观察一至两周再下线，为回滚留出余地。
一致性校验：迁移完成的判定标准
“rsync 退出码是 0″不等于”数据完全一致”，最终验收要拿独立证据说话。最直接的方式是在目标端再跑一次反向校验，用 --dry-run 模拟同步，如果没有任何文件被列出，说明两端已经一致：
rsync -avnc --delete -e "ssh -p 22" /data/www/ root@新服务器IP:/data/www/ | grep -v '/$'
输出为空即通过；若列出文件，说明这些文件在源端与目标端存在差异，需要检查是传输遗漏还是时间戳问题。除了 dry-run，配合两个数量级核对更保险：
- 文件数对比：源端
find /data/www -type f | wc -l与目标端同命令结果应完全相等 - 校验和抽查：对关键文件执行
sha256sum 文件名，两端输出一致才算内容级一致；数据量大时至少抽查数据库备份、配置文件和入口脚本 - 目录大小对比：
du -s /data/www两端数值应在排除规则允许的范围内吻合，偏差过大说明有目录被意外排除或多余写入
迁移后的功能验证同样重要：在新服务器上启动 Web 服务，用 curl -I http://127.0.0.1/ 确认返回 200，检查应用日志无权限报错，再修改本地 hosts 把域名指向新服务器 IP 做真实访问测试。如果迁移过程中遇到时钟不一致导致校验和判断异常，可以参考这篇服务器时钟漂移排障实录先修复时间同步再重新校验。
高频问题与排查方向
实际操作中，下面几个问题出现频率最高，附上定位思路：
permission denied：目标端账号对目标目录无写权限，或源端文件属主在目标端不存在（UID 冲突），用ls -ln对比两端 UID 后修正- 同步后文件数不一致：优先检查排除规则是否误伤，
--dry-run加-v列出被跳过的路径即可确认 - 传输中途断开：
--partial已保留部分传输文件，直接重跑同一命令；频繁断开先排查 SSH 稳定性与两端dmesg中的网卡丢包记录 - 带宽跑满影响业务：加
--bwlimit=20480（单位 KB/s，示例约限 20 MB/s），把同步流量压到安全水位 - 目标端出现多余旧文件：说明某次执行漏了
--delete，补跑一次即可收敛
如果源站数据量持续增长、单靠手工同步吃力，也可以考虑把初始化工作交给自动化工具，例如用 Ansible 批量初始化服务器的思路，把同步命令固化成剧本，新购机器时一键完成数据与配置就位。
总结：把迁移做成可重复的流程
rsync 增量同步的价值不只是”搬得快”，而是把数据迁移变成一个可重复、可验证的流程：全量打底、增量收敛、停写终同步、dry-run 与校验和双重验收。建议你在实际操作中把这四个阶段的命令写进迁移清单，每次演练都按同一顺序执行，正式切换时就不会临场补漏。数据一致性确认后，也别忘了处理 DNS 解析切换与服务监控的迁移，让新服务器在流量切入前就被完整的观测覆盖。如果你正在为迁移挑选性能与带宽更有保障的目标环境，可以考虑 Hostease 的独立服务器或 VPS（虚拟专用服务器）方案，配合本文的同步流程完成平滑搬迁。