rsync备份6分钟跑完，恢复时半个文件是空洞，退出码0为什么可能是最贵的谎言？

一、导语：一次“成功”的灾难

设想这样一个场景：一台承载业务数据库与日志归档的服务器，每晚用 rsync 做增量同步到备份卷。某天的备份日志显示，任务在 6 分 12 秒内完成，退出码 0，传输速率正常，没有报错。三个月后，主存储故障，运维按流程从备份卷恢复，却发现一个 40 GB 的数据库文件恢复后只有约 20 GB 的真实数据，其余部分是全零空洞；更糟的是，应用层读取这些空洞时并不报错，而是返回零值，直到业务校验失败才暴露问题。

这类故障的迷惑性在于：它不产生任何“错误信号”。rsync 的退出码 0 表示“程序按预期完成了它认为需要做的工作”，而不是“目标端数据与源端逐字节一致”。这两者在多数场景下近似等价，但在稀疏文件、部分传输、权限跳过、过滤规则误配等条件下会出现系统性偏离。本文评述：把退出码当作数据完整性的充分条件，是备份工程中最常见、也最昂贵的认知捷径。

本文的主线是：备份系统的“成功”语义与“可恢复”语义之间存在结构性缝隙，rsync 的退出码 0 恰好落在这条缝隙里。围绕这条主线，下文依次讨论退出码的定义边界、rsync 增量与稀疏文件机制、空洞的生成链路、可复现的检测方法，以及把恢复可证性纳入流水线的工程步骤。

二、问题定义：退出码 0 到底承诺了什么

2.1 退出码是控制流信号，不是数据质量信号

在 POSIX 进程语义中，退出码是进程向父进程报告“我如何结束”的整数。rsync 手册页对其退出码有明确定义：0 表示成功，1 表示语法或用法错误，2 表示协议不兼容，3 表示选择输入/输出文件时出错，4 表示请求的动作不被支持，5 表示启动客户端-服务端协议时出错，6 表示日志文件追加失败，10 表示 socket I/O 错误，11 表示文件 I/O 错误，12 表示协议数据流错误，13 表示诊断错误，14 表示 IPC 错误，20 表示收到 SIGUSR1 或 SIGINT，21 表示等待 pid 时出错，22 表示由 --max-delete 限制导致的删除，23 表示部分文件因错误未传输，24 表示部分文件在传输中消失，25 表示 --max-delete 限制了删除，30 表示数据发送/接收超时，35 表示连接超时。

关键在于：退出码 0 只说明 rsync 没有触发上述任何一类“它自己能感知的”异常。它不承诺目标端每个字节都与源端一致，也不承诺稀疏文件的空洞布局被正确重建，更不承诺被过滤规则排除的文件是可接受的。本文评述：退出码是“控制流信号”，而数据完整性是“内容属性”，二者之间需要额外的校验层来桥接。

2.2 三个容易混淆的“成功”层级

工程实践中，“备份成功”至少有三个层级：任务层成功（进程退出码为 0）、传输层成功（所有应传文件都完成了传输且校验和匹配）、恢复层成功（从备份介质恢复出的数据通过业务级校验）。rsync 的退出码只覆盖第一层，部分覆盖第二层（通过 --checksum 等选项），完全不覆盖第三层。多数事故的根因不是某一层出了问题，而是团队把第一层的信号当成了第三层的结论。

笔者认为，这张表应当成为每个备份方案评审的必备附件：它强迫团队回答“我们到底在验证哪一层”。如果答案只有第一层，那么“6 分钟跑完”就不是效率指标，而是风险指标。

2.3 稀疏文件：被忽视的语义载体

稀疏文件是指文件逻辑大小远大于实际占用磁盘块的文件，未写入的区域以“空洞”形式存在，读取时返回零，但不占用物理块。数据库预分配文件、虚拟机镜像、日志预留文件、容器镜像层都可能大量使用稀疏布局。rsync 提供 -S/--sparse 选项，用于在传输过程中把全零块转换为空洞，以节省目标端空间。问题在于：稀疏化是一种“有损的表示变换”——逻辑内容不变，但物理布局改变；而某些下游工具（如按块读取的校验工具、部分文件系统快照、某些备份代理）对空洞的处理并不一致。

本文评述：稀疏文件把“内容一致性”和“布局一致性”拆成了两个问题。rsync 的默认行为更关注前者，而恢复事故往往出在后者。理解这一点，是理解“半个文件是空洞”的前提。

三、原理拆解：rsync 增量算法与稀疏文件语义

3.1 滚动校验与增量传输的基本机制

rsync 的核心是 Andrew Tridgell 在 1990 年代提出的增量传输算法：接收端把目标文件切分为固定长度块，对每块计算弱校验（滚动校验，常用 Adler-32 类）与强校验（如 MD5 或 xxHash 类），把校验和列表发给发送端；发送端在源文件上滑动窗口，先用弱校验快速筛选候选块，命中后再用强校验确认，未命中的区段作为“字面数据”传输。这样只需传输差异部分，带宽与时间大幅下降。

该算法的前提是“接收端已有可用的基线文件”。如果基线文件本身是损坏的、稀疏布局错误的，或者校验和被错误复用，增量算法会在错误的基础上“高效地”传播错误。本文评述：增量备份的效率优势与正确性风险同源——它信任基线，而基线可能正是上一次事故的产物。

3.2 默认跳过逻辑：大小与 mtime 的脆弱契约

rsync 默认的“快速检查”依据文件大小与修改时间（mtime）判断是否需要传输，而不是逐字节比较。这在绝大多数场景下是合理的工程折中，但它建立在一个契约上：大小和 mtime 能代表内容变化。当应用以“原地覆写、保持大小、回拨 mtime”的方式修改文件时，契约被打破，rsync 会跳过实际已变化的文件。--checksum（-c）选项可以强制逐文件校验，但代价是全量读取，可能让“6 分钟”变成数小时。

笔者认为，这里存在一个典型的“效率-可信度”权衡曲线：校验越强，备份窗口越长；校验越弱，恢复风险越高。合理的做法不是二选一，而是分层——对关键数据集开启强校验，对可重建的冷数据保留快速检查，并用恢复演练来校准分层边界。

3.3 稀疏化与 --sparse 的行为边界

--sparse 的作用是：在写入目标文件时，检测全零块并 seek 跳过，从而在目标端形成空洞。它的收益是节省空间，代价是目标文件的物理布局与源端不同。某些场景下这是期望行为（如镜像仓库去重），但在需要“逐块可比对”的恢复验证中，稀疏化会让简单的 cmp 或校验和对比产生误判——因为逻辑内容相同，物理读取路径不同。

更微妙的是，稀疏化与增量传输叠加时，若基线文件本身存在非预期空洞，接收端的块校验可能把空洞区域当作“已匹配”而跳过，导致源端的真实数据没有被写入。本文评述：这不是 rsync 的 bug，而是“表示变换 + 增量假设”组合出的语义缝隙。工程上必须用独立于传输路径的校验来封堵这条缝隙。

3.4 退出码的生成路径

rsync 在结束时汇总各类错误计数，按优先级映射为退出码。部分文件传输失败会返回 23，文件在传输中消失返回 24，I/O 错误返回 11。但“逻辑上不该传的文件被过滤掉”“稀疏布局未按预期重建”“元数据未完整保留”这类问题，并不必然触发非零退出码。本文评述：退出码的覆盖面由实现者定义，而不是由数据完整性需求定义；把后者寄托于前者，是范畴错误。

四、失效链路：空洞是如何被“合法”制造出来的

4.1 链路一：基线稀疏布局错误 + 增量跳过

第一次备份时，源端文件是稀疏的，目标端因未开启 --sparse 而写成密集文件；第二次备份开启 --sparse，接收端以密集文件为基线计算块校验，发送端按稀疏逻辑处理，双方对“哪些块是全零”的认知不一致，部分真实数据块被误判为可跳过。结果是目标文件出现非预期空洞，而任务退出码仍为 0。这条链路的关键是“基线状态与当前选项不匹配”。

4.2 链路二：过滤规则与排除清单的静默生效

--exclude、--include、--filter 规则的优先级和匹配顺序容易误配。一个常见的错误是：先写 --exclude '*.log' 再写 --include 'important.log'，由于排除规则先匹配，重要日志被静默跳过。rsync 不会因此返回非零退出码，因为“按规则跳过”是预期行为。恢复时缺失的文件不会表现为空洞，而是表现为“文件不存在”，但同样属于“退出码 0 的谎言”。

4.3 链路三：权限与特殊文件的跳过

以非 root 用户运行 rsync 时，无法读取的文件、无法保留的属主/属组、无法复制的设备节点会被跳过或降级处理。部分场景下 rsync 会返回 23，但在某些组合（如 --ignore-errors 或特定过滤配置）下可能被吞掉。本文评述：权限问题是最容易被“成功日志”掩盖的一类，因为它不产生传输错误，只产生“少传了”。

4.4 链路四：网络中断后的“部分成功”

rsync 支持断点续传式的中断恢复，但中断发生时已写入的部分可能处于不一致状态。若重试逻辑只检查退出码而不校验内容，下一次增量会以这个不一致的文件为基线继续传播。本文评述：断点续传是效率特性，不是一致性特性；把两者混为一谈，等于把“能接着传”当成“传对了”。

4.5 失效链路的共同结构

把上述链路抽象，可以看到共同结构：某个“预期内的跳过/变换”与另一个“预期外的状态偏差”叠加，使错误落在退出码的感知范围之外。这解释了为什么事故往往在恢复时才暴露——恢复是第一次真正读取全部数据、并与业务语义对齐的时刻。

五、关键数据与案例：从社区报告到可复现实验

5.1 公开资料中的相关线索

rsync 官方手册页与 FAQ 对退出码、--sparse、--checksum、--ignore-errors 的语义有明确说明，是本文事实基线的主要来源。Samba/rsync 邮件列表与 GitHub issue 中，长期存在关于稀疏文件在增量场景下行为不一致的讨论；部分发行版 bug tracker 记录了 --sparse 与 --inplace 组合的边界问题。学术侧，Tridgell 的博士论文《Efficient Algorithms for Sorting and Synchronization》是增量同步算法的经典文献；近年关于备份可恢复性、勒索软件韧性的研究（如 USENIX 相关会议论文与 NIST 指南）反复强调“备份成功不等于可恢复”。

本文评述：公开资料足以支撑“退出码 0 不保证可恢复”这一结论，但具体到“半个文件是空洞”的量化比例，缺乏统一的公开数据集。因此下文涉及的比例数据均标注为模拟或整合数据，不作为普适统计结论。

5.2 一个可复现的最小实验设计

为验证失效链路，可设计如下最小实验（模拟数据，用于演示机制，不代表真实生产比例）：

# 1) 构造一个稀疏文件：逻辑 1 GiB，实际占用很小
truncate -s 1G src.img
dd if=/dev/urandom of=src.img bs=1M count=8 seek=100 conv=notrunc

# 2) 第一次备份：不开启 --sparse，目标端成为密集文件
rsync -a src.img dst1.img
du -h --apparent-size dst1.img; du -h dst1.img

# 3) 第二次备份：开启 --sparse，以密集文件为基线做增量
rsync -aS src.img dst1.img
echo "exit=$?"

# 4) 恢复验证：逐字节比对 + 稀疏块统计
cmp src.img dst1.img && echo "content-equal"
filefrag -v dst1.img | head -20

在该实验中，cmp 可能报告内容一致，但 filefrag 显示目标端空洞分布与源端不同；若把 dst1.img 再作为下一次增量基线，某些文件系统与 rsync 版本组合下会出现块匹配偏差。本文评述：这个实验的价值不在于复现某个特定 bug，而在于演示“内容一致”与“布局一致”可以分离，而恢复验证必须同时覆盖两者。

5.3 案例归纳：三类高发场景

上述比例若需量化，应以自有环境的恢复演练数据为准；本文不提供虚构的百分比。本文评述：案例归纳的意义在于建立“症状-机制-验证方法”的映射，而不是制造恐慌。

5.4 拓展阅读与工具链接

建议结合官方文档与社区讨论交叉验证：rsync 官方文档、rsync 手册页、RsyncProject GitHub、Linux 文件系统文档。视频类可参考 rsync 稀疏文件相关讲解（外部链接，内容以发布者为准）。

六、检测方法：把“可恢复”变成可测量的指标

6.1 指标设计：从任务指标到恢复指标

建议至少定义四个指标：任务成功率（退出码 0 占比）、传输校验覆盖率（开启 --checksum 的文件占比）、恢复抽检通过率（抽样恢复后通过业务校验的比例）、空洞偏差率（恢复文件与源文件的稀疏块分布差异比例）。前两个是过程指标，后两个是结果指标。本文评述：只有结果指标才能回答“备份是否可信”，过程指标只能回答“任务是否跑完”。

6.2 校验脚本：内容与布局双比对

#!/usr/bin/env bash
# verify_restore.sh —— 恢复抽检：内容哈希 + 稀疏布局
set -euo pipefail
SRC="$1"; DST="$2"
h1=$(sha256sum "$SRC" | awk '{print $1}')
h2=$(sha256sum "$DST" | awk '{print $1}')
[ "$h1" = "$h2" ] || { echo "CONTENT-MISMATCH"; exit 1; }
# 统计逻辑大小与实际占用，识别异常稀疏化
s1=$(stat -c '%s %b' "$SRC"); s2=$(stat -c '%s %b' "$DST")
echo "src(size,blocks)=$s1 dst(size,blocks)=$s2"
# 若逻辑大小相同但块数差异超过阈值，标记为需人工复核
awk -v a="$(echo $s1|awk '{print $2}')" -v b="$(echo $s2|awk '{print $2}')" \
  'BEGIN{ d=(a>b?a-b:b-a); if (d/a > 0.2) { print "SPARSE-DEVIATION"; exit 2 } }'
echo "RESTORE-OK"

该脚本演示了“内容哈希 + 块占用”的双重判定。阈值 0.2 是示例值，应根据文件类型校准。本文评述：校验脚本必须独立于备份路径实现，否则会继承同一套假设，失去发现偏差的能力。

6.3 恢复演练的抽样策略

全量恢复演练成本高，可采用分层抽样：按文件类型（数据库、镜像、日志、配置）分层，每层按大小加权抽样；对关键数据集每月至少一次完整恢复，对冷数据每季度抽检。抽样结果应回写到指标看板，形成“恢复可信度”趋势。本文评述：演练的价值不仅是发现故障，更是校准“哪些数据值得强校验”的决策依据。

七、工程路径：备份流水线的加固步骤

7.1 步骤一：明确数据分级与校验强度

把数据分为“不可重建”“可重建但成本高”“可重建且成本低”三级。不可重建数据强制开启 --checksum 与恢复演练；可重建高成本数据采用周期性强校验；低成本数据保留快速检查。分级结果写入备份配置模板，避免每次靠人记忆。

7.2 步骤二：统一稀疏文件处理策略

对稀疏文件，明确“是否保留稀疏布局”这一决策，并在全流水线一致执行：要么全程 --sparse 且恢复端支持空洞语义，要么全程密集化并接受空间成本。禁止“有时开有时不开”的混用，因为混用正是基线状态漂移的温床。本文评述：一致性比最优性更重要——一个始终密集的备份，比一个时疏时密的备份更可信。

7.3 步骤三：把退出码纳入更宽的判定上下文

不要只看退出码，而是构造一个判定函数：退出码 + 传输文件计数 + 跳过文件清单 + 校验覆盖率 + 恢复抽检结果。任一维度异常即告警。示例伪代码：

def backup_verdict(rc, sent, skipped, checksum_ratio, restore_ok):
    if rc != 0: return "FAIL"
    if skipped_critical(skipped): return "SUSPECT"
    if checksum_ratio < 0.8: return "WEAK-VERIFY"
    if not restore_ok: return "UNRECOVERABLE"
    return "TRUSTED"

这个函数的输出比单一退出码更接近“可恢复性”的真实状态。

7.4 步骤四：建立恢复演练的常态化机制

把恢复演练写进运维日历，指定负责人，记录演练报告。报告至少包含：抽样范围、校验方法、发现的问题、修复动作、下次演练计划。本文评述：没有演练报告的备份系统，其“可信度”只是信念，不是证据。

7.5 步骤五：保留审计线索与版本化配置

备份脚本、过滤规则、rsync 版本、文件系统类型都应版本化记录。事故复盘时，这些线索能快速定位“当时用的是哪套假设”。本文评述：备份系统的可解释性，与其可恢复性同等重要——无法解释的成功，无法被信任。

八、对比与局限：rsync 之外的选择与边界

8.1 与其他备份机制的对比

本文评述：rsync 的优势是通用、轻量、跨平台，劣势是它把一致性责任部分转移给了使用者。选择 rsync 不是错误，把 rsync 当成交付即用的强一致备份才是错误。

8.2 局限与反例

必须承认：多数 rsync 备份在多数场景下是可靠的；本文讨论的是边界条件，而非否定工具本身。反例包括：纯文本小文件、无稀疏布局、无过滤规则、每次全量校验的场景，退出码 0 与可恢复性高度一致。本文评述：工程判断的价值在于识别“何时不适用”，而不是制造普遍怀疑。

九、结论与展望：从“任务成功”到“恢复可证”

回到开头的问题：为什么退出码 0 可能是最贵的谎言？因为它用最低的成本给出了一个看似确定的信号，而这个信号覆盖的范围远小于团队对“备份成功”的期待。稀疏文件、增量基线、过滤规则、权限跳过，这些机制单独看都合理，叠加起来却在退出码的感知边界之外制造了系统性偏差。本文评述：治理这类问题的关键，不是寻找一个“更聪明的退出码”，而是建立独立于传输路径的恢复验证层。

展望未来，三个方向值得关注：其一，文件系统与备份工具对稀疏语义的标准化描述，使“布局一致性”成为可查询属性；其二，备份流水线内置轻量级恢复抽检，把验证成本分摊到日常；其三，以“恢复可证”为核心的备份可信度评估框架，替代单一的“任务成功率”指标。笔者认为，备份工程的成熟标志，不是备份跑得多快，而是团队能拿出多少条经过验证的恢复证据。