迁移前先做数据分级和容量评估，选择rsync或云迁移工具，规划好停机窗口并做增量同步，最后必须校验数据完整性并保留回滚方案，这样既快又稳。
服务器数据迁移到底难在哪
很多运维朋友一听到“迁移”两个字就头疼，旧服务器上跑着业务、存着数据库、堆着日志，还有一堆说不清用途的配置文件，直接拷贝吧，怕文件锁死；用压缩包吧，大文件传到一半断掉；找厂商帮忙吧,又担心数据安全。
说实话，迁移本身不复杂，复杂的是不确定性，你不知道哪些文件在变、哪些文件被占用、哪些依赖关系断了，所以整个迁移过程，本质上就是在跟“变化”赛跑。
数据搬家前的四项准备
动手之前，先花半小时把旧服务器的情况摸清楚，这一步做扎实了,后面能省一整天的麻烦。
- 盘点数据目录：用
du -sh /var/www、du -sh /opt这类命令，把每个主要目录的大小列出来，做到心里有数 - 识别数据类型：数据库文件、静态资源、日志、临时文件，不同类型用不同的搬运策略
- 确认服务依赖：哪些服务在跑、监听了哪些端口、依赖哪些系统库，用
systemctl list-units和ss -lntp查清楚 - 规划停机窗口：业务低峰期是几点，能接受多长的中断时间，这决定了你用冷迁移还是热迁移
有一位老运维跟我说过一句实在话：“迁移翻车的人，十有八九是栽在没看数据目录大小上。” 磁盘快满了才想起来搬,结果临时文件把新服务器也挤爆了。
迁移工具怎么选，得看你的场景
行业里没有万能工具，但每个场景都有最优解,下面按场景拆开说。
小数据量用rsync逐步同步
如果你要搬的数据在几十GB到几百GB这个量级，rsync是当之无愧的第一选择，它的优势在于断点续传和增量同步，第一次全量同步后，第二次只同步变化的部分,非常适合迁移前做预同步。
实际操作就三步：
rsync -avz --progress /data/ root@新服务器IP:/data/
第一次跑全量，跑完别急着切换，等业务低峰期，再跑一次增量，把期间变化的数据补上，最后停服务，跑第三次，这时候数据量极小，几十秒就能完成,停机时间压缩到最短。
大数据量用中转机加并行传输
数据超过1TB，直连传输就不太现实了，带宽跑不满、断线重来成本高、源服务器IO也被拖垮，多数情况下,建议找一台带宽充足的中转机和并行工具配合。
- 用
tar把数据分卷打包，每卷控制在5GB到10GB - 开多个
rsync进程并行传输，或者用gclone这类支持多线程的工具 - 旧服务器带宽有限的话，考虑先压缩再传输，CPU换带宽，划算
数据库迁移要用专用工具
文件拷贝解决不了数据库的一致性问题，MySQL在运行状态下直接拷贝数据目录，大概率得到一份损坏的数据，行业共识是,数据库迁移必须用官方工具。
| 数据库类型 | 推荐工具 | 适用场景 |
|---|---|---|
| MySQL | mysqldump、XtraBackup | 数据量小用前者，大库用后者 |
| PostgreSQL | pg_dump、pg_basebackup | 逻辑备份或物理备份二选一 |
| MongoDB | mongodump、MongoMirror | 单机或副本集迁移 |
| Redis | redis-cli --cluster import | 缓存数据快速迁移 |
千万注意：mysqldump在大数据量下效率很低，单表超过10GB，建议用XtraBackup做物理备份,恢复速度能快一个量级。
网站迁移服务器注意事项：别光顾着搬文件
网站迁移比纯数据迁移多一层复杂度，因为牵扯到域名解析、SSL证书、伪静态规则这些“看不见的配置”，很多人在这一块栽跟头，文件搬过去了，网站打不开,排查半天发现是Nginx配置没同步。
配置文件要单独打包
为什么不建议直接打包整个/etc目录？因为里面有大量无关紧要的缓存和临时文件，而且不同版本的系统配置路径有差异,比较稳妥的做法是：
- 单独备份
/etc/nginx、/etc/apache2、/etc/php这几个关键目录 - 用
tar -czpf保留文件权限和所有者，解压时用tar -xzpf还原 - 新服务器上先装同版本软件，再覆盖配置，最后
nginx -t测试语法
域名和证书切换有顺序
切换到新服务器之前，先把新服务器的防火墙、SELinux策略都调好，确保WEB服务能正常访问,然后按这个顺序操作：
- 修改DNS解析的TTL值，提前降到300秒，让解析快速生效
- 在DNS控制台添加新服务器IP的A记录，确认解析正常
- 等旧服务器上的流量明显下降后，再停掉旧服务
- SSL证书直接复制到新服务器对应目录，注意检查证书链是否完整
网站迁移后的三个验证步骤
光看页面能打开不算成功，真正要验证的是功能完整性，行业专家指出,多数迁移翻车事件都发生在验证环节做得不够细致。
- 功能冒烟测试：登录、上传、搜索、支付回调，核心功能逐个点一遍
- 日志检查：
tail -f /var/log/nginx/error.log，重点看有没有404和502 - 数据一致性比对：源库和目标库的行数、总大小是否一致，用
SELECT COUNT()抽查几张关键表
服务器搬迁哪家好，自建还是找服务商
这个问题得看你的实际情况，自建迁移省钱但费人，找服务商省心但费钱，两条路都有人走,关键是匹配自己的需求。
自建迁移的适用人群
如果你手上有两台服务器都在同一机房，或者旧服务器已经快到期了，不急着切回，那自建迁移完全够用，自己操作的优势是灵活，随时可以调整方案，劣势是一旦遇到问题,只能靠自己排查。
找服务商的适用场景
大型企业或者数据量特别大的场景，找服务商更靠谱，不少云厂商提供迁移评估和工具支持，比如简米云的“服务器迁移中心”、酷番云的“迁移服务平台”，这些工具能自动完成数据同步和校验,省去很多手工操作。
还有一点，服务商通常有专属迁移带宽，比普通公网带宽快得多，如果你的数据量在几TB以上，而且时间窗口很紧,找服务商是明智的选择。
迁移成本怎么控制
迁移成本不只是钱的问题，还有时间成本和风险成本，一次性迁移和分批迁移的成本结构完全不同,需要提前规划清楚。
- 时间成本：停机窗口越长，业务损失越大，所以尽量安排在凌晨或周末
- 带宽成本：公网传输有流量费用，同一云厂商内网迁移免费或价格更低
- 风险成本：迁移失败后的回滚成本，可能比迁移本身还高，所以必须预留回滚方案
迁移过程中的常见坑和填坑办法
不管你准备得多充分，迁移过程中总会冒出一些意外，下面这几个坑,几乎每个做迁移的人都踩过。
文件权限错乱
用rsync不带-a参数传输，会导致文件的所有者和权限丢失，新服务器上Web服务突然报403错误，大概率就是这个原因，解决方法是传输时加上-a参数保留属性，传输完成后用
find /data -type f -user www-data检查一遍关键目录的属主。
大文件传输中断
超过10GB的单个文件，在公网上传输很容易断线，rsync虽然支持断点续传，但中断后重跑一次增量同步，也可能因为文件被占用而失败，比较有效的做法是先把大文件用split拆成小块,传完再合并。
split -b 5G large_file.iso part_ rsync -avz part_ root@新服务器:/data/ cat part_ > large_file.iso
数据库字符集不一致
这是最隐蔽的坑，源库是utf8mb4，新库默认是latin1，导入后中文全部变成乱码，数据导出时,显式指定字符集：
mysqldump --default-character-set=utf8mb4 -u root -p database > backup.sql
导入前，先在新库执行SET NAMES utf8mb4;,再导入数据。
收尾工作别偷懒
迁移完成后，大部分人松了一口气，直接删掉旧服务器上的数据，这种做法风险极高，行业惯例是保留旧服务器数据至少一周,确认新服务器稳定运行后再做清理。
收尾的重点有几件事：
- 监控接入：确认CPU、内存、磁盘、带宽的监控告警都正常上报
- 备份策略：新服务器上配置好定时备份，别让数据再一次裸奔
- 文档记录：把迁移过程中的命令、修改的配置、踩过的坑记录下来，方便以后复盘
服务器数据迁移常见问题解答
迁移过程中业务不能停怎么办？
业务不能停，就要用热迁移方案，数据库层面用主从复制，先把数据同步到新库，然后切换读写；文件层面用rsync多次增量同步，最后在业务低峰期做一次秒级切换，整个过程可以在几分钟内完成,业务中断时间极短。
迁移后发现数据少了怎么办？
先别慌，检查是不是增量同步时漏掉了正在变化的文件，可以对比新旧服务器的文件总数和总大小，重点检查日志目录和临时文件目录，如果确认是传输遗漏，重新执行一次rsync增量同步，把缺失的文件补上，更稳妥的做法是迁移前就建立数据校验清单,对关键目录做MD5校验。
旧服务器的数据需要保留多久？
保守建议是保留一到两周，这个时间足够覆盖一个完整的业务周期，能发现大部分潜在问题，如果数据量很大，可以压缩打包后存到对象存储上，成本很低，但能买一份安心，数据安全这种事，宁可多留,不可少留。