旧服务器上的数据搬起来想要又快又稳，核心思路是“先规划后动手，能并行就别串行，先校验再切割”。很多人一上来就开个压缩包慢慢传，结果传到一半网络闪断，前功尽弃，真正靠谱的做法，是先摸清数据规模、业务容忍度，再选对工具和迁移窗口。
旧服务器数据迁移，最稳妥的步骤是什么？
别急着拷文件,我见过太多人跳过规划直接开干，最后要么丢数据，要么业务中断大半天，把迁移拆成五个阶段，每一步都留出校验时间，才是稳的根本。
第一步：盘点旧服务器上的数据资产
先搞清楚到底要搬什么,数据库、附件目录、配置文件、日志文件，它们的体积和变化频率完全不一样，用一条命令就能摸清家底：
du -sh /data/
这一步能让你知道哪些目录是大头,哪些可以最后处理，同时记录一下关键文件的修改时间，方便后续增量校验。
第二步：确认新服务器的环境兼容性
数据不是搬过去就能跑的,操作系统版本、数据库版本、PHP或Java环境，稍有差异就可能导致程序报错，建议提前在新服务器上装好同版本环境，并用测试脚本跑一遍核心接口。
第三步：选择迁移方式和工具
这是决定快慢的关键环节,如果旧服务器和新服务器之间走的是公网，带宽有限，那就别用scp硬传整个磁盘镜像，按数据类型拆开处理：
- 数据库：用
mysqldump或pg_dump导出，再导入新库。 - 静态文件：用
rsync，支持断点续传和增量同步。 - 大目录：先打包再传输，但一定要加校验参数。
第四步：执行全量+增量同步
全量同步适合数据量不大、业务可以暂停的场景，但业务不能长时间停的话，就先做一次全量，然后趁着业务运行再做增量的差异同步。rsync配合--delete参数，可以把源端删除的文件也同步过去，保证两边完全一致。
第五步：切换前做完整性校验
别急着改DNS或停旧服务器,先比对新旧两边的文件数量和总大小，再抽查几个关键文件的内容，数据库层面，比对行数或者CHECKSUM TABLE，确认无误后再切换流量。
旧服务器数据拷贝到新服务器，怎么缩短停机时间？
停机时间就是钱,多数情况下，业务不能让你慢慢传几个晚上，行业共识认为，缩短停机时间的关键在于“增量同步 + 平滑切换”的组合拳，而不是夜晚硬扛着传输。
用rsync做两轮同步，把停机窗口缩到分钟级
第一轮同步放在业务低峰期,先把绝大多数数据传过去，等真正要切换时，再做第二轮同步，这时候只有很少的增量数据，几分钟就能完成，命令示例：
rsync -avz --progress /data/ user@newserver:/data/
第二轮加个--delete，确保删除的文件也同步过去，两轮之间的时间间隔越短，切换窗口就越小。
数据库迁移用主从复制或在线导入
对于MySQL,可以提前搭好主从复制，让新服务器持续同步旧服务器的binlog，切换时只需要把写操作停掉，确认从库追平主库，再升级为主库即可，PostgreSQL可以用pg_basebackup或逻辑复制，原理类似。
需要停机时间的场景，选凌晨低峰期
凌晨三点到六点是绝大多数业务的真空期,把切换动作安排在这个时段，用户几乎感知不到，但要注意，别只预留传输时间，还要留出半小时的灰度验证时间。
计算迁移总耗时的简单公式
数据量除以实际带宽,再乘以安全系数，举个例子，100GB数据，20MB/s实际传输速度，理论耗时约1.5小时，加上校验和增量同步时间，总窗口建议预留3小时以上，别把理论值当实际值，网络抖动随时可能出现。
迁移过程中最常见的坑，以及对应的排查方法
数据搬完不等于万事大吉,很多坑是在迁移结束后才暴露的，提前知道能省掉不少返工。
文件权限和属主变了
用tar打包再解包,容易丢失特殊权限位，用rsync -a能保留权限、时间戳、软链接，如果已经丢了，用chown和chmod批量恢复，但前提是你提前记下了原始权限列表。
符号链接和硬链接被打散
大文件目录里经常有大量软链,比如日志目录指向另一个磁盘，用cp -a或rsync -a可以保留链接关系，如果已经传成普通文件了，那就需要重新建立链接，工作量不小。
数据库导入时出现字符集乱码
导出时指定字符集,导入前也要确认新库的默认字符集，MySQL常用--default-character-set=utf8mb4，PostgreSQL则要检查client_encoding配置，乱码一旦出现，往往要重导数据。
传输中断后没有校验机制
很多人传完文件就认为结束,结果新服务器上运行旧代码，缺了几个文件才傻眼，传输完成后用diff -r或者rsync -avn干跑一遍，能快速找出差异文件，注意-n是模拟模式，不会真的覆盖。
针对不同场景的迁移方案怎么选？
旧服务器数据迁移方案怎么选,取决于你的业务类型和预算，没有万能方案，只有最适合现状的做法。
同城机房之间迁移
内网带宽通常能跑满千兆甚至万兆,直接上rsync或者scp都没问题，如果数据量在几百GB以内，一个晚上足够，内网环境比较安全，可以同时开多个rsync进程并行传不同目录。
跨地域迁移，公网带宽有限
这种场景最考验耐心,建议先压缩再用rsync -z传输，能省不少流量，如果数据量超过1TB，就得考虑分卷传输，中途断了也能从断点续传，也可以考虑用专业的数据迁移服务，由专人负责网络调度。
云服务器之间的迁移
云厂商通常提供镜像迁移服务,比如AWS的SMC、简米云的SMC，这些工具能自动处理系统盘配置差异，但要注意，跨平台迁移（比如Linux到Windows）不适合用镜像，需要重新部署环境。
带数据库的完整业务迁移
这类迁移对一致性要求最高,先用逻辑备份导出数据，再导入新库，导入完成后跑一遍业务冒烟测试，比如登录、查询、写入一条记录，确认无误后，再切换配置文件的数据库连接地址。
关于旧服务器数据迁移的常见问题
旧服务器数据迁移需要多长时间？
没有标准答案,数据量、带宽、磁盘IO、数据库表结构复杂度都是变量，100GB以内的小站点，内网环境下2到3小时就能完成全量迁移，跨公网迁移1TB以上数据，可能需要数天甚至更久，最稳妥的办法是先跑一个10GB文件的传输测试，用实际速度推算总耗时。
迁移过程中旧服务器能不能继续运行？
可以,但要注意数据一致性，静态文件用rsync做增量同步时，旧服务器正常运行不会有影响，但数据库在导出期间如果有写入，导出的快照可能不完整，建议在低峰期做全量导出，切换到新服务器前再补一次增量同步。
怎么验证迁移后的数据完整？
文件层面用rsync -avnc比对差异，数据库层面比较表行数或CHECKSUM TABLE结果，还有一种更直接的验证方式：在新服务器上启动一套业务实例，连接新数据库跑一遍核心流程，看是否和旧服务器表现一致，这一步不能省，它能发现环境差异导致的各种诡异问题。
归根结底,旧服务器数据迁移从来不是“拷文件”那么简单，先把数据分类、选对工具、留足校验时间，再用增量同步把停机窗口压缩到最短，最后别忘了做完整性和业务双验证，按这个思路走，数据搬完之后不用提心吊胆。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/774822.html
