写在前面：当你的VPS数据迁移跑完rsync，看着输出结尾的“sent 1234 bytes, received 456 bytes”心头一松，正准备把老服务器关机下线时——请先暂停一下。IO统计上的“成功” != 业务层的数据一致，这个道理在物理机同样成立，但在VPS上因为引入了一层虚拟化，坑会埋得更深。 轻云互联的老用户可能还记得去年那篇关于磁盘IO性能的分享。今天不谈速度，专门聊聊迁移中容易被忽视的静默数据损坏（Silent Data Corruption）问题。这些坑不报错、不告警，只会在特定场景下让新VPS上的MySQL打不开表，或者网站图片裂掉一半。 ---

坑一：rsync的“温柔”默认值，没给你复制扩展属性

新手迁移数据，命令行往往是这样的： ```bash rsync -avz /home/wwwroot/ root@新VPS_IP:/home/wwwroot/ ``` 看起来用了 `-a`（归档）选项，很安全。但注意，`-a` 在Linux上等同于 `-rlptgoD`，其中`D`代表设备文件和特殊文件。它不包含 `-X`（xattrs）和 `-A`（ACLs）。 你在旧VPS上如果用了`setfacl`给某个站点目录做过精细化权限控制，比如给某个FTP用户单独授予读写权： ```bash setfacl -m u:ftpuser:rwx /home/wwwroot/site2/ setfacl -m d:u:ftpuser:rwx /home/wwwroot/site2/ ``` 用上面的rsync命令迁移后，xattr信息丢失。迁移到新机器后，PHP-FPM运行用户`www`访问没问题，但一旦通过Samba或FTP工具操作目录，会提示权限不足——你还在新机器上反复chmod 777，甚至重装FTP服务排查半天，却不知道是ACL没过去。 **避坑操作：** 强制挂载xattr选项。 ```bash # 迁移ACL及xattr rsync -avzA -X /home/wwwroot/ root@新VPS_IP:/home/wwwroot/ ``` 如果迁移的是整个系统盘环境，务必加上`-H`参数保留硬链接。很多应用（例如邮件系统Maildir）硬链接文件多，不加此参数，迁移后你会在硬盘上莫名多出上百GB垃圾数据。

坑二：稀疏文件（Sparse file）的传输陷阱，导致磁盘空间翻倍

数据库dump文件或者虚拟机镜像在ext4等文件系统上，经常以稀疏文件形式存在。比如你的一个文件显示大小是`10G`，但实际占用磁盘只有`2G`，那`8G`全是“空洞”。 看一下这个实例： ```bash # 创建一个500M的稀疏文件，但实际只占1个块 dd if=/dev/zero of=sparse_test bs=1M count=0 seek=500 ls -lh sparse_test # 输出：-rw-r--r-- 1 root root 500M ... 文件大小显示500M du -sh sparse_test # 输出：0 实际占用为0 ``` 如果你迁移时严格遵循上述`-avz`参数rsync，rsync默认会识别稀疏文件，算是稍微放心的一点。但坑在于打包工具。如果你先执行了`tar -zcvf`打包再传输，gzip压缩管道会吃满这些空洞。 当你把打包的zip或tar.gz传输到新VPS上解压时，解压过程会重新展开这些空洞。此时VPS的统计磁盘使用率可能会瞬间飙升，甚至因为节点空间耗尽（inode用尽）报出“No space left on device”的诡异错误。 **避坑操作：** 用rsync同步时，显式指定`-S`选项处理稀疏文件： ```bash rsync -avzS /backup/docker_images/ root@新VPS_IP:/var/lib/docker/ ``` **数据校验要命处：** 迁移完，别用`ls -l`去看大小比对，那只能比对“逻辑大小”。要用`du`对比新旧VPS上同名文件的“物理占用大小”，以此判断空洞是否被意外的实体化（Materialized）了。

坑三：单引号地狱与Shell扩展，数据库备份集全体静默漏传

这里要说的不是文件权限，而是因为你的VPS有过往业务遗留的特殊命名故障。比如你为了省事，用`mysqldump`针对所有库导出文件，文件名带了库名，中间恰好包含了`$`符号。 真实的故障现场是这样的：数据库里有个库名为 `weird$db`（这是允许的）。你写了如下脚本： ```bash # 错误示范 rsync -avz /data/mysql/weird$db.sql root@新VPS_IP:/data/mysql/ ``` 在双引号或者无引号状态下，Shell会尝试展开`$db`变量。如果该变量未定义，这个文件在命令行里就变成了`/data/mysql/weird.sql`。 如果老VPS上恰好同时存在`weird$db.sql`和`weird.sql`（后者是某个历史遗留的废弃文件），即使命令行提示“sent xxxx bytes”，实际传输的是全空的废弃文件。迁完新库后，`weird$db`的数据全部丢失。 **避坑操作：** 永远对所有变量使用单引号是错的（单引号内变量不展开），正确用法是在rsync使用双引号，并对特殊字符转义，或者干脆用`--files-from`参数吃文件列表。 这是最推荐的方式，安全且直观： ```bash # 使用文件列表模式，规避shell解析问题 cat > /tmp/file_list.txt << "EOF" /data/mysql/weird$db.sql EOF rsync -avzS --files-from=/tmp/file_list.txt / root@新VPS_IP:/ ```

避坑的核心解法：别用IO状态判断，用“文件指纹”验证

在轻云互联的VPS运维实践中，判断数据迁移是否成功有着严格的铁律：即便看了rsync退出码是0，也必须进行文件指纹比对。 `rsync`在某些版本（如3.1.2之前）存在已知的数据同步竞态条件。另外如果你使用了`--partial`（保留部分传输）并因为网络中断后重连，新VPS上的文件已存在——第二次rsync可能因为文件时间戳被未正确刷新而跳过校验。 迁移完事后的终极验证： ```bash # 在旧VPS生成全量校验，发送到新VPS比对 cd /home/wwwroot && find . -type f -exec md5sum {} \; > /tmp/old_checksums.md5 scp /tmp/old_checksums.md5 root@新VPS_IP:/tmp/ # 在新VPS上执行 cd /home/wwwroot && md5sum -c /tmp/old_checksums.md5 > /tmp/check_result.log 2>&1 # 然后重点关注grep -v "OK"的结果 grep -v ': OK$' /tmp/check_result.log | wc -l ``` 如果输出的行数不为0，那才是真正需要你回滚和重新处理的地方。无论你的rsync之前跑得多么欢快。 --- **关于存量业务的迁移建议：** 如果你迁移的是高IOPS的数据库业务或站点文件，请一定记得先停写（业务只读），再去打快照或复制文件。上面提到的这些坑，在轻云互联基于NVMe阵列的VPS环境上基本可以规避底层硬件层面的偶发校验错误，但应用层逻辑和数据完整性是云厂商替不了你做的最后一道防线。迁移结束，跑一次真实业务的Smart Health Check，再决定是否释放旧VPS资源，这是老手与新手的最大差别。