rdiff-backup 介绍与选型指南

目标：面向 Linux 运维工程师，讲清 rdiff-backup 的定位、反向增量原理与元数据机制，并与 rsnapshot、Duplicity、BorgBackup、Restic 做量化选型对比。文中原理性结论均溯源官方站点/仓库并标注查询日期（2026-10-22），快速开始示例已在 Ubuntu 22.04 + rdiff-backup 2.2.7 环境逐条实测通过。

一、环境信息

本篇为认知与选型篇，涉及两类环境信息：联网溯源环境与本地实测环境。

• 溯源环境：rdiff-backup 官网 rdiff-backup.net、GitHub 仓库 rdiff-backup/rdiff-backup、PyPI 仓库，版本与社区数据查询日期均为 2026-10-22（版本经 shields.io GitHub Release 徽章接口与 PyPI JSON 接口核对，未直连 GitHub API）；
• 实测环境：Ubuntu 22.04（x86_64，内核 6.8.0-138-generic，glibc 2.35）；
• 软件版本：rdiff-backup 2.2.7（本地实测版本，与 2026-10-22 查询到的 GitHub 最新稳定 Release 一致）；
• 运行时：Python 3.10.12（/usr/bin/python3，cpython）；
• 快速开始示例目录：源目录 /root/demo-src，备份目录 /root/demo-bak。

rdiff-backup info 的实测回显（可用来核实版本与运行时，逐行照抄）：

$ rdiff-backup info
---
exec:
  api_version:
    actual: 0
    default: 200
    max: 201
    min: 200
  argv:
  - /usr/local/bin/rdiff-backup
  - info
  parsed: null
  version: 2.2.7
python:
  executable: /usr/bin/python3
  name: cpython
  version: 3.10.12
system:
  fs_encoding: utf-8
  platform: Linux-6.8.0-138-generic-x86_64-with-glibc2.35
...

二、软件概述

rdiff-backup 的官方一句话定位是「Reverse differential backup tool, over a network or locally」（反向差分备份工具，可在本地或跨网络使用，来源：rdiff-backup.net 首页标题，查询日期 2026-10-22）。官方首页对其工作模型的描述为：备份目标目录最终是源目录的一份完整拷贝（镜像），同时在目标目录下一个特殊子目录中保存「反向差分（reverse diffs）」，因此仍然可以找回过去某个时间点丢失的文件；其设计意图是结合镜像与增量备份两者的优点（来源：rdiff-backup.net 首页 Introduction 节，查询日期 2026-10-22）。

关键身份信息（来源与查询日期标注在每行末尾）：

💡 说明：rdiff-backup 不是守护进程式备份服务，而是一次执行一次会话的 CLI 工具；定时备份由 cron/systemd timer 等外部机制驱动。它也不自带管理界面，社区项目 Minarca（基于 rdiff-backup）提供 Web 端集中管理。

三、核心架构

理解 rdiff-backup 只需要抓住四个机制：镜像 + 反向增量、librsync 差分、元数据独立存储、SSH 管道双端协作。

3.1 镜像 + 反向增量（reverse increments）

官方 features 页原文（来源：rdiff-backup.net/features.html，查询日期 2026-10-22）：备份目录会成为源目录的「几乎完全一致的拷贝」，唯一差别是备份侧多出一个子目录；镜像的好处是可以用 find/locate 等熟悉工具直接查找和拷贝文件，源盘损坏时把备份目录挂载回去即可近乎即时恢复。

增量方向与常见增量备份相反：普通增量备份保存的是「从旧版本到新版本」的正向差异，恢复旧版本时需要从全量开始逐层应用增量；rdiff-backup 的镜像永远是最新状态，rdiff-backup-data/ 子目录里保存的是把镜像回退到过去某个时点所需的反向差分与被删除/被替换文件的完整旧拷贝。因此：

• 「恢复到最新」= 直接读镜像（或拷贝镜像里的文件），不需要任何增量参与；
• 「恢复到过去」= 用反向增量从当前镜像往回退，由 rdiff-backup restore --at <时间> 完成；
• 每个 session 的变化记录在 rdiff-backup-data/increments/ 下，文件名带 UTC 时间戳（如 increments.2026-10-22T05:36:16Z.dir，见第五章实测回显）。

💡 技术拓展：「保留多个历史版本」的备份机制不止反向增量一种，主流方案对比——

机制	原理/特点	代表工具	适用场景
镜像+反向增量	镜像始终最新，历史靠反向差分回退	rdiff-backup	想直接浏览镜像、又要能回滚历史
硬链接快照	每轮完整目录树，未变文件硬链接到上一轮	rsnapshot/Bacula SD	快照直观、空间省，但依赖同盘符文件系统
全量+正向增量卷	周期全量 + 其间增量 tar 卷，恢复需逐层解	Duplicity/Bacula	需要加密上传云端的离线归档
去重仓库	内容分块去重写入仓库，按快照组织	BorgBackup/Restic	大量相似数据、需加密与远程仓库

rdiff-backup 实际采用「镜像+反向增量」：目标是让备份目录可直接当镜像用（服务器故障时最短时间切换），同时保留无限历史增量而不需要周期性重做全量（官网 History 节称其「unlimited incrementals with no need to space consuming regular full backups」的模型至今仍独特）。

3.2 librsync 差分引擎

官方 features 页原文（来源：rdiff-backup.net/features.html，查询日期 2026-10-22）：rdiff-backup 使用 librsync 库，实现了与 rsync 相同的高效 diffing 算法，且对二进制文件同样有效；rsync 与 rdiff-backup 严格来说不共享任何代码。对「每天只变一点点的大文件」（官方举例如数据库文件），普通增量备份每轮都要存一份完整拷贝，而 rdiff-backup 每轮只保存差异的一小部分。

对跨网络场景，同样的机制带来带宽收益：官方原文举例——大文件 A 略微修改成 A′，且 A 已在远端存在时，rdiff-backup 只需在网络上传输 A→A′ 的差分，而不必整份重传 A 或 A′；因此 rdiff-backup + SSH 的组合远比 ftp/scp 整文件传输省带宽（来源：features.html "Bandwidth efficient" 节）。

3.3 元数据独立存储

备份要「可还原」，数据之外的元数据同样重要。官方 features 页 "Preserves all information" 与 "ACL and EA support" 节（查询日期 2026-10-22）确认：

• 无论从镜像还是从历史增量恢复，文件都会按原样重现：硬链接恢复后仍是硬链接，权限、uid/gid 属主、修改时间、设备文件、fifo、符号链接全部保留；
• 当目标文件系统无法表达某些元数据时（例如属主无法复制、Windows 文件系统大小写不敏感且无属主概念），rdiff-backup 会把文件元数据记录到单独的元数据文件中，保证即使目标文件系统缺特性，信息也不丢失；
• POSIX ACL 与 user 级扩展属性（EA）依赖 Python 模块 pylibacl/pyxattr，模块与文件系统都支持时即自动保留（Mac OS X/Windows 不支持 POSIX.1e ACL）；
• 目标端文件系统特性自动探测：运行时自动检测两端文件系统是否支持大小写、属主变更、扩展属性、ACL、资源 fork 等，无需手工加 --acl/--ea 之类开关；以 -v4 及以上详细度运行可以看到探测结果。

3.4 SSH 管道双端协作

官方 features 页 "Easy to use" 节给出的两种形态：本地 rdiff-backup dir1 dir2；跨机 rdiff-backup dir1 user@system::/dir2，要求两端系统都安装 rdiff-backup。跨机运行时 rdiff-backup 通过 SSH 在远端拉起自己的服务端进程，两端进程经标准输入/输出管道通信，差分数据在管道中按需传输——这就是「带宽高效」的实现载体，也决定了双机部署时两端版本需要兼容（同一 2.2.x 线内互通良好，1.x 与 2.x 之间有破坏性变更，官方提供迁移文档 migration.html）。

四、功能特性

以下特性均以官方 features 页为源（查询日期 2026-10-22），并注明本地实测情况：

⚠️ 注意：rdiff-backup 不做静态加密（备份目录里的文件是明文镜像）也不做内容去重；这两点是与 Borg/Restic/Duplicity 的核心差距，选型时必须结合场景权衡（见第七章）。

五、快速开始（最小可用示例）

本节用一个最小示例走通「备份 → 查看镜像 → 变更 → 增量 → 恢复 → 校验」闭环，全部命令与回显均为 Ubuntu 22.04 + rdiff-backup 2.2.7 实测照抄（安装步骤见 《Ubuntu 22.04 安装 rdiff-backup 指南》）。

准备测试数据并执行首轮备份：

mkdir -p /root/demo-src/docs
echo "hello rdiff-backup" > /root/demo-src/README.md
printf "server {\n    listen 80;\n}\n" > /root/demo-src/docs/nginx.conf
head -c 2048 /dev/urandom > /root/demo-src/docs/blob.bin
rdiff-backup backup --print-statistics /root/demo-src /root/demo-bak

首轮备份实测回显（首轮从零建镜像）：

WARNING: Server will be called with deprecated command line interface to guarantee compatibility. It might lead to a deprecation warning from newer rdiff-backup versions. Use '--api-version 201' (or higher) to avoid it.
NOTE: Starting mirror from source path /root/demo-src to destination path /root/demo-bak
--------------[ Session statistics ]--------------
StartTime 1792647376.00 (Thu Oct 22 05:36:16 2026)
EndTime 1792647376.83 (Thu Oct 22 05:36:16 2026)
ElapsedTime 0.83 (0.83 seconds)
SourceFiles 5
SourceFileSize 2093 (2.04 KB)
MirrorFiles 1
MirrorFileSize 0 (0 bytes)
NewFiles 4
NewFileSize 2093 (2.04 KB)
DeletedFiles 0
DeletedFileSize 0 (0 bytes)
ChangedFiles 1
ChangedSourceSize 0 (0 bytes)
ChangedMirrorSize 0 (0 bytes)
IncrementFiles 0
IncrementFileSize 0 (0 bytes)
TotalDestinationSizeChange 2093 (2.04 KB)
Errors 0
--------------------------------------------------

💡 说明：开头的 WARNING 提示默认 API 版本（2.2.x 默认 api-version 200）以旧式命令行调用服务端进程，属兼容性提示而非错误，备份已正常完成；加 --api-version 201 即可消除。统计中的 TotalDestinationSizeChange 2093 表示备份目录本轮净增 2.04 KB，Errors 0 表示无错误。

列出镜像内容与历史增量：

rdiff-backup list files /root/demo-bak
rdiff-backup list increments /root/demo-bak

实测回显：

.
README.md
docs
docs/blob.bin
docs/nginx.conf

Found 0 increments:
Current mirror: Thu Oct 22 05:36:16 2026

💡 说明：镜像根下的 README.md、docs/ 等可以直接按普通文件访问；首轮备份还没有历史增量，Current mirror 即当前镜像对应的时间点。

修改文件后做第二轮备份，观察反向增量的产生：

echo "hello rdiff-backup v2" > /root/demo-src/README.md
rdiff-backup backup --print-statistics /root/demo-src /root/demo-bak
rdiff-backup list increments /root/demo-bak

实测回显（统计节选 + 增量列表全量）：

NOTE: Starting increment operation from source path /root/demo-src to destination path /root/demo-bak
--------------[ Session statistics ]--------------
StartTime 1792647377.00 (Thu Oct 22 05:36:17 2026)
EndTime 1792647377.04 (Thu Oct 22 05:36:17 2026)
ElapsedTime 0.04 (0.04 seconds)
SourceFiles 5
SourceFileSize 2096 (2.05 KB)
MirrorFiles 5
MirrorFileSize 2093 (2.04 KB)
NewFiles 0
NewFileSize 0 (0 bytes)
DeletedFiles 0
DeletedFileSize 0 (0 bytes)
ChangedFiles 2
ChangedSourceSize 22 (22 bytes)
ChangedMirrorSize 19 (19 bytes)
IncrementFiles 2
IncrementFileSize 81 (81 bytes)
TotalDestinationSizeChange 84 (84 bytes)
Errors 0
--------------------------------------------------

Found 1 increments:
    increments.2026-10-22T05:36:16Z.dir   Thu Oct 22 05:36:16 2026
Current mirror: Thu Oct 22 05:36:17 2026

💡 说明：第二轮只花 0.04 秒、目的地净增 84 字节——镜像只更新变化部分，旧版本被记录为反向增量。Found 1 increments 中出现的 increments.2026-10-22T05:36:16Z.dir 是首轮会话的快照壳目录，带 UTC 时间戳。

从镜像恢复单个文件到新位置并校验整库：

rdiff-backup restore --at now /root/demo-bak/README.md /root/restored-README.md
cat /root/restored-README.md
rdiff-backup verify /root/demo-bak

实测回显：

hello rdiff-backup v2

NOTE: All files verified successfully

💡 说明：--at now 表示恢复镜像当前状态（恢复历史时点则换成 --at 1D 这类时间表达式）；verify 对仓库内文件逐一做哈希校验。至此最小闭环走通：备份、浏览镜像、增量、按时间点恢复、校验。

六、适用场景与限制

6.1 适用场景

结合官方描述与实测特性，rdiff-backup 最契合以下场景：

1. 本机/机房内「磁盘到磁盘」镜像备份：备份盘可直接浏览，源盘损坏时把备份目录挂回去即可快速接管（官方 features 页原意），这是它相对「加密仓库型」工具（Borg/Restic/Duplicity）最直接的运维收益；
2. 大文件小改动的周期备份：librsync 差分让每天只变一点的数据库/虚拟磁盘文件每轮只存差分（官方举例场景，查询日期 2026-10-22）；
3. 跨机房低带宽远程备份：user@host::/path + SSH 管道只传差分，两端装同版本 rdiff-backup 即可；
4. 需要完整 POSIX 元数据的备份：权限/属主/ACL/EA/硬链接自动保留，目标文件系统缺特性时元数据落独立文件；
5. 以开源方案做集中式备份管理的底座：社区项目 Minarca 即以 rdiff-backup 为核心提供 Web 管理与集中备份服务器。

6.2 限制

• 无静态加密：镜像与增量在备份端均为明文（librsync 差分文件为 gzip 压缩），备份目标不可信时必须改用 Borg/Restic/Duplicity 这类客户端加密工具；
• 无内容去重：相同内容的多份文件各占各的空间，虚拟机镜像/邮件服务器这类高冗余场景 Borg/Restic 更省；
• 增量链完整性要求：历史恢复依赖镜像 + 反向增量链完整，删除增量（remove increments）后对应时点即不可恢复；备份会话中断后需要先 regress 修复仓库才能继续备份（命令篇有中断修复实测）；
• 两端版本兼容：跨机备份要求两端都装 rdiff-backup 且版本兼容，1.x 仓库与 2.x 不直接互通（官方提供 migration 文档）；
• Windows 支持有限：官方提供 Windows 安装包与专门说明文档（Windows-README.html），但 POSIX ACL 等特性在 Windows 不可用（features 页原文）。

七、同类选型对比

对比对象选取站内已发布介绍篇的四款开源备份工具：rsnapshot、Duplicity、BorgBackup、Restic。版本与社区数据来源统一标注：GitHub Release/Stars 数据取自 shields.io 徽章接口，Duplicity/Borg 版本另经 PyPI JSON 接口核对，查询日期均为 2026-10-22。

7.1 量化对比总表

7.2 版本节奏与兼容矩阵

• rdiff-backup：2.0（2020-03，Python 3 重写）→ 2.2.x 现行稳定线，2026-10-22 查询最新 Release 为 2.2.7，项目处于活跃维护状态（官网 History 节称近 20 年历史、当前由三位主要维护者负责）；仓库格式在 1.x → 2.x 间有破坏性变更，官方提供 migration 文档；
• rsnapshot：1.4.x 长期稳定线后进入 1.5.x（2026-10-22 查询最新 v1.5.1），配置文件驱动、依赖外部 rsync/ssh；
• Duplicity：0.8 线（站内安装篇实测的 apt 版本线）与 3.x 线并行维护，2026-10-22 PyPI 最新 3.2.1；
• BorgBackup：1.4.5（2026-10-22 查询）为 1.x 稳定线，另有 2.x 预览线（含仓库 v2 与多服务端特性）；
• Restic：0.x 线持续快速迭代，2026-10-22 查询最新 v0.19.1；仓库格式跨版本兼容性在官方文档中有明确承诺矩阵。

7.3 选型建议

• 如果备份目标是本机另一块盘/机房内备份服务器、希望备份目录当镜像直接用（灾备快速切换、用 find/cp 直接取文件），且无静态加密诉求 → 选 rdiff-backup；
• 如果只需要直观的快照目录 + 最低依赖（已有 rsync，脚本化定期快照）→ 选 rsnapshot（差异：硬链接快照不保存差分，小改动大文件的每轮成本高于 rdiff-backup 的反向增量）；
• 如果必须客户端加密后上传云对象存储（S3/B2/Swift 等）→ 选 Duplicity（或 Restic 原生云后端）；
• 如果数据冗余度高（虚拟机/邮件/代码仓库）且要加密+去重、可接受仓库型管理 → 选 BorgBackup（SSH 仓库形态）或 Restic（云后端/多平台）；
• 如果要在 rdiff-backup 之上要 Web 管理与集中备份服务器 → 评估社区 Minarca 项目。

八、参考链接

1. rdiff-backup 官网：https://rdiff-backup.net/（定位与 History，查询日期 2026-10-22）
2. 官方特性页：https://rdiff-backup.net/features.html（反向增量/librsync/元数据/ACL EA/统计，查询日期 2026-10-22）
3. 官方使用示例：https://rdiff-backup.net/examples.html
4. 官方 FAQ：https://rdiff-backup.net/FAQ.html
5. GitHub 仓库：https://github.com/rdiff-backup/rdiff-backup（Release v2.2.7 与星数经 shields.io 徽章接口核对，查询日期 2026-10-22）
6. 1.x → 2.x 迁移文档：https://rdiff-backup.net/migration.html
7. 站内相关篇目：《rsnapshot 介绍与选型指南》、《Duplicity 介绍与选型指南》、《BorgBackup 1.4 介绍与选型指南》、《Restic 0.19 介绍与选型指南》