旧服务器数据迁移，最快的路径不是复制粘贴，而是先规划再动手：用“镜像同步+增量校验”的组合拳，既能跑满带宽，又能保证数据零差错。
数据搬家这件事,最怕的不是慢，而是搬到一半发现丢了文件、乱了权限、坏了数据库，今天这篇内容，就围绕“旧服务器数据迁移”这个核心场景，把提速和稳住的实操方法一次讲透。
数据迁移前必须完成的3项检查
很多人一上来就敲rsync命令，结果传到一半发现磁盘空间不够、源目录里有隐藏文件没带上、数据库表还在写入，业内专家指出，迁移失败案例里，超过一半的问题出在准备阶段，所以动手前，花半小时做下面三件事。
盘点数据清单：哪些该搬，哪些该扔
先登录旧服务器,用du -sh /home /var /opt这类命令看看各目录体积，注意系统临时文件、缓存目录（/tmp、/var/cache）、日志文件（/var/log）通常不需要搬，如果旧服务器上跑着容器，还要用docker ps确认哪些镜像和卷是实际在用的。
- 列出所有数据目录的绝对路径
- 标注每个目录的用途（网站、数据库、附件、配置）
- 确认是否有定时任务（
crontab -l）依赖特定路径
确认新服务器环境兼容性
如果新旧服务器都是Linux,系统版本差异可能导致二进制文件无法执行，用cat /etc/os-release对比版本，如果是Windows迁Linux，路径分隔符、权限模型都要额外处理，数据库版本建议保持一致，跨大版本迁移（如MySQL 5.7到8.0）需要先做逻辑备份再导入，不能直接拷贝数据目录。
预留双倍临时空间
迁移过程中,新服务器既要接收完整数据，还要留出解压、校验的临时空间，如果采用打包传输，压缩包+解压文件会同时占用磁盘，建议至少留出数据总量1.5倍的可用空间，空间不够时，优先清理新服务器上的无用包缓存（apt clean或yum clean all）。
旧服务器数据传输方案怎么选才更稳
传输方案没有绝对最优,只有适不适合当前场景，下面的对比表帮你快速决策。
| 方案 | 适用场景 | 速度表现 | 稳定性风险 |
|---|---|---|---|
| rsync增量同步 | 文件型数据、持续运行的网站 | 中高，可增量续传 | 低，支持断点续传 |
| tar打包+scp/oss上传 | 一次性迁移冷数据 | 高，单个大文件传输 | 中，打包中断需重来 |
| 数据库逻辑导出 | 数据库版本升级或异构迁移 | 慢，导出+导入两段 | 低，逻辑一致性有保障 |
| 云平台迁移服务 | 跨云或同云换实例 | 快，走内网或专线 | 低，但需要付费或权限 |
rsync：最快最稳的增量同步工具
对于还在运行的旧服务器,直接rsync -avz --progress /源目录 用户@新IP:/目标目录就能开始第一次全量同步。-a保留权限、属主、时间戳，-v显示过程，-z压缩传输节省带宽，第一次同步后，服务先不停，等业务低峰期再跑一次增量同步，这段时间内新增/变更的文件量会很小，同步几秒到几分钟就能完成，然后切换流量，数据丢失率近乎为零。
如果跨机房走公网,建议加--bwlimit限速，防止占满带宽影响旧服务器对外服务，例如rsync -avz --bwlimit=20480限制为20MB/s。
打包传输：适合大文件和海量小文件
海量小文件（比如图片缩略图、日志切片）用rsync效率低，因为每个文件都要建立连接和校验，这种情况先在旧服务器上打包：tar czf data.tar.gz /data，压缩后传输单个文件，再在新服务器解压，注意，打包过程中源数据若有写入，备份会不一致，所以打包前要临时暂停服务，或使用tar --warning=no-file-changed忽略变更告警，但最好还是停写。
更稳妥的做法是配合snapshot特性：使用lvcreate -s创建LVM快照，然后对快照打包，业务完全不受影响。
数据库迁移：别直接用文件拷贝
MySQL的ibdata1、PostgreSQL的base目录直接拷贝到新服务器，大概率启动失败，正确姿势是：
- 旧服务器执行
mysqldump --single-transaction -u用户 -p 库名 > 库名.sql - 新服务器执行
mysql -u用户 -p 库名 < 库名.sql
PostgreSQL用pg_dump -Fc 库名 > 库名.dump，再用pg_restore导入，如果数据量特别大（上百GB），用mydumper并行导出配合myloader导入，速度比单线程mysqldump快数倍。
迁移过程中如何保证数据不丢不坏
即使方案选对了,执行过程中也可能遇到中断、带宽抖动、文件被占用等问题，下面这几个操作能大幅提升成功率。
校验环节必须做两遍
第一遍在传输完成后,用rsync -avz --checksum --dry-run对比源和目标目录的校验值，第二遍随机抽取关键文件，用
md5sum对比，如果使用的是云存储中转，对象服务通常会提供ETag校验，可以在上传后逐个比对。
数据库导入完成后,执行一条简单的计数查询，比如SELECT COUNT() FROM 核心表，对比旧服务器上的结果，数字对得上，基本可以确认迁移成功。
断点续传与任务守护
一旦网络闪断,rsync重跑不会重复传输已完成的文件，这是它的天然优势，但tar管道断了就得重新打包，所以大文件传输建议用rsync --partial保留部分传输的文件，或者改用nc（netcat）配合pv监控进度。
为了让长时间任务不因为SSH断连而中断,用screen或tmux起一个会话，把迁移命令放进去执行，命令示例：
screen -S migration rsync -avz /data 用户@新IP:/data
然后按Ctrl+A再按D脱离会话，任务继续在后台运行，随时可以用screen -r migration回来查看进度。
迁移期间数据写入不一致怎么处理
只要旧服务器服务还在运行,迁移同时就可能有新文件产生，两个解决办法：
- 先全量同步一次,然后停服，再增量同步一次（推荐）
- 不停服,但把旧服务器上的写入磁盘或数据库设为只读（需要应用层面配合）
多数情况下,选择凌晨低峰期执行“全量同步-短暂停服-增量同步-切换”是最稳的节奏。
常见场景下旧服务器数据迁移的操作路径
网站文件迁移：从旧服务器搬家到新服务器
假设旧服务器IP是0.113.10，新服务器IP是51.100.20，网站目录在/var/www/html。
# 旧服务器上执行全量推送 rsync -avz --delete /var/www/html/ root@198.51.100.20:/var/www/html/ # 同步完成后，在新服务器上设置正确的属主 chown -R www-data:www-data /var/www/html
接着改域名解析的A记录指向新IP,生效后（TTL时间）再跑一次增量同步，把期间的新文件补过去。
宝塔面板/云主机换机房时的搬家
使用宝塔面板的网站迁移功能,会先打包站点和数据库，然后传到目标服务器一键导入，但如果手动操作，注意数据库配置wp-config.php或.env文件里的DB_HOST要改成新环境的地址。
国内云厂商之间迁移,往往走内网或对象存储更快。先上传到同地域的OSS/COS，再从对象存储下载到新服务器，比直接公网scp快几倍，还省流量。
本地旧服务器迁移到云服务器的场景
本地服务器上云,除了数据传输，还要考虑安全组和防火墙规则，传输时可以用sshfs挂载远程目录，本地直接cp，但速度一般，更推荐用rclone配合对象存储，支持增量、加密、断点续传，命令相对简单。
注意,迁移到云服务器后要重新配置安全组，只开放必需的端口（如443、22），数据盘挂载确认/etc/fstab开机自动挂载。
数据迁移后验证清单与回退方案
不要切换完就以为大功告成,至少验证以下项目：
- 网站首页返回200,静态资源（CSS/JS/图片）全部能正常加载
- 数据库连接成功,读写正常
- 定时任务能正常触发,日志输出没有权限错误
- 文件时间戳和属主与旧服务器一致（rsync
-a保证） - 反向代理和SSL证书配置有效,没有证书域名不匹配
万一迁移失败如何快速回退
保留旧服务器至少1周再清理,这是铁律，切换后如果发现严重问题，只需将域名解析改回旧IP，同时旧服务器上保留迁移前的完整数据状态，我们做增量同步用的是rsync，旧服务器上的数据并没有被删除，所以回退很简单：把域名切回旧IP，再关掉新服务器上的服务即可。
要想数据库安全回退,迁移时不要执行任何DROP或TRUNCATE语句，逻辑导出文件本身是纯数据，适合回滚。
Q&A：旧服务器数据迁移常见问题
旧服务器数据搬到新服务器需要多久？
取决于数据量和网络带宽。100GB数据走内网千兆，理论时间约15分钟；走公网10Mbps带宽则需要22小时以上，建议用iperf3测试两端网络吞吐再估算，实际传输时间通常为理论值的70%左右。
rsync和scp哪个更适合服务器迁移大量数据？
rsync更适合,scp一次性传输，中断就得重来，且没有增量能力，rsync支持断点续传、增量对比、权限保留，是行业共识推荐的迁移工具，如果你只需传一个孤立的文件，scp方便，但涉及整个目录迁移，请用rsync。
迁移过程中可否继续让用户访问旧服务器？
可以,但要控制写入频率与并发，静态网站影响不大，动态站强烈建议在最后增量同步完成前，让运维人员将应用切换为只读维护模式，用户写入的数据如果产生在新增量同步之后，就会丢失，因此需要一段时间的只读窗口来收尾，如果你用的是LVM快照方式，可以先把数据打到快照点，然后正常读写，再单独处理增量，但复杂度更高，不适合新手操作。