Restic 与 BorgBackup 怎么选：S3、SSH 和备份速度

Restic 与 BorgBackup：用一段话说明区别

Restic 和 BorgBackup 的核心功能相同：为 Linux 服务器创建支持去重、加密和增量的备份。决定选择哪一个的关键在于备份存储位置。Restic 原生支持 S3 和其他对象存储 API，因此可以直接将存储桶作为目标，远端无需安装任何程序。稳定版 Borg 则要求在存放仓库的机器上安装 borg 程序，因为 Borg 仓库由进程提供服务，而不是由文件系统或 API 提供。如果目标是对象存储，答案已经明确。如果目标是由您控制的另一台 Linux 主机，则可以使用 Borg，而且通常速度更快。

其他差异都较小。两者都会根据内容进行分块，因此一个发生 200 MB 变化的 40 GB 目录，大约只需上传 200 MB。两者都在客户端执行加密。两者都可通过 FUSE（用户空间文件系统）挂载快照，以便复制出单个文件。截至 2026 年 10 月，Restic 版本为 0.19.1，Borg 的稳定系列为 1.4，当前版本为 1.4.5。Borg 2.0 多年来一直处于 beta 阶段，目前仍标记为仅供测试，因此今天应部署 1.4。

仓库模型才是真正的区别

restic 仓库是一个文件目录：config、keys/、snapshots/、index/ 和 data/，其中包含大量 pack 文件。读取仓库不需要其他组件。因此，restic 可以适配多种后端。任何能够存储、获取、列出和删除 blob 的存储，都可以保存 restic 仓库。这也是同一个二进制文件能够支持本地路径、SFTP、自带的 REST 服务器、S3、Backblaze B2、Azure、Google Cloud Storage，以及 rclone 可访问的任意存储的原因。

Borg 仓库同样是磁盘上的文件，但 Borg 不会通过简单传输协议直接访问它。对于远程仓库，Borg 会通过 SSH 在远端启动 borg serve，并与该进程使用自己的协议通信。服务器端会执行实际操作：保存仓库、应用事务，并响应索引查询。因此，稳定的 Borg 1.4 系列没有 S3 后端。因为无法在存储桶中运行进程。Borg 2 改变了这一点：它将存储移入名为 borgstore 的新层，其文档介绍了 sftp://、rclone:remote:path 和 s3: 或 b2: 仓库 URL。不过，Borg 2 目前仍处于 beta 阶段，项目方明确表示不要将其用于生产环境。因此，就当前的实际备份而言，S3 支持缺失的问题仍然存在。

这一项设计事实造成了下面大多数实际差异。

# restic: the repository is a URL, and the backend is part of it
restic -r /srv/restic-repo init
restic -r sftp:backup@198.51.100.20:/srv/restic-repo init
restic -r s3:s3.us-east-1.amazonaws.com/my-backup-bucket init

# borg: a local path, or user@host:path, with borg installed on that host
borg init --encryption=repokey-blake2 /srv/borg/vps1
borg init --encryption=repokey-blake2 backup@198.51.100.20:/srv/borg/vps1

加密：其中一种可以关闭

Restic 始终启用加密，不提供未加密模式。restic init 会要求输入密码，并使用 scrypt 从密码派生密钥；此后写入的每个 pack 文件都会经过加密和身份验证。密码丢失后，数据也会丢失，因为该设计不提供恢复途径。

Borg 在创建仓库时选择是否加密，并且该选择不可更改。borg init --encryption=repokey 会将加密密钥保存在仓库中，因此只需密码短语即可恢复。--encryption=keyfile 会将密钥保存在客户端的 ~/.config/borg/keys/ 中，因此即使有人窃取整个仓库，也无法获取数据；但您必须单独备份该密钥文件，否则归档将无法读取。每种模式都有一个 -blake2 变体，使用 BLAKE2b 而不是 HMAC-SHA256 进行身份验证。在不支持 SHA 硬件加速的设备上，前者速度更快。--encryption=none 也可用。如果仓库存放在您拥有的加密磁盘上，这是一个实际可行的选择。

实际规则是：普通服务器备份使用 repokey-blake2；仓库存放在您无法完全信任的位置时使用 keyfile；在租用的机器上绝不要使用 none。

压缩，以及为什么 restic 很晚才支持压缩

Borg 从一开始就支持压缩。默认值为 lz4，因为它的速度足够快，可以始终启用。zstd 接受 1 到 22 的级别，默认值为 3；zlib 和 lzma 适用于更关注占用字节数而不是耗时的情况；auto 会针对每个块运行启发式判断，因此不会再次压缩已经压缩的数据。

borg create --compression zstd,3 --stats --progress \
  /srv/borg/vps1::'{hostname}-{now}' /etc /home /srv

在仓库格式 2 之前，Restic 完全不支持压缩；使用该格式需要 restic 0.14.0 或更高版本。现在，新建仓库默认使用格式 2，可通过 --compression 将压缩设置为以下五个值之一：auto（默认值）、off、fastest、better 或 max。fastest 和 better 模式在 restic 0.19.0 中加入，因此较旧的二进制文件只能接受 auto、off 和 max。旧的格式 1 仓库在迁移之前会一直保持未压缩状态。因此，如果您的 restic 仓库早于 0.14 创建，且您从未迁移过它，那么文本、日志和数据库转储仍会占用完整大小的存储空间。

远程目标：S3 与 SSH

通常选择就在此处做出。

Restic 连接 S3 仅需在环境中配置凭据，无需在任何地方运行其他程序。同样的模式也适用于自托管的存储桶，这是一种常见的组合：运行 MinIO 以在您的 VPS 上提供 S3 API 并将 restic 指向它。

export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
export RESTIC_REPOSITORY=s3:https://objects.example.com/backups
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic init
restic backup /etc /home /srv --exclude-caches

Borg 连接远程仓库需要 SSH 以及远端安装的 Borg，且要求远端版本与客户端兼容。如果远端不由您控制，这会带来阻力。但如果远端是您管理的另一台服务器，这就不是问题，而且它能为您提供这两种工具中针对勒索软件最强的控制手段：仅追加（append-only）SSH 密钥。强制该密钥运行 borg serve，客户端即可添加归档但无法删除它们，因此即使客户端机器遭到入侵，也无法清除其自身的历史备份。

command="borg serve --append-only --restrict-to-path /srv/borg/vps1",restrict ssh-ed25519 AAAA...

Restic 仅在运行其自带的 REST 服务器时才具备等效功能，该服务器支持仅追加模式。对于普通的 S3，您可以通过存储桶策略或对象锁定实现同样的效果，这是服务提供商而非 restic 的职责。同时请锁定传输通道，因为 SSH 侧的安全与任何其他登录方式一样需要谨慎对待：对备份账户应用 仅限密钥的 SSH 并限制 authorized_keys 条目。

速度：每种设计意味着什么

两个项目都没有发布可用于您自己数据的可靠基准，因此应根据工作机制进行判断。

Borg over SSH 在高延迟链路上的速度很快，因为服务器端具备智能处理能力。客户端提出请求，远程 borg serve 进程从仓库索引中返回结果，并在同一端完成事务提交。每个小文件的分块查找不会分别产生网络往返。

Restic 使用对象存储时没有服务器端处理能力，因此必须通过 HTTP 获取索引文件和 pack 文件来构建数据视图。为控制请求数量，Restic 会在上传前将许多小分块打包到较大的 pack 文件中，并在 ~/.cache/restic 中保留本地缓存，使下一次运行无需重新获取完整索引。删除该缓存后，下一次备份会在重建缓存时变慢。在包含数百万个小文件的高延迟链路上，Restic 在处理相同数据时可能比 Borg 更慢。

在本地磁盘或高速 LAN 上，两者的差距通常会缩小。此时，两个工具的性能主要受读取和计算源数据哈希的速度限制。

锁定并备份多台计算机

Borg 1.4 会在整个操作期间独占锁定仓库。两个客户端不能同时向一个仓库写入：第二个客户端会等待，随后因锁超时而失败。受支持的模式是每个客户端使用一个仓库。这也意味着重复数据删除只在单台计算机的仓库内进行，因此 10 台几乎相同的服务器会存储 10 份相同的基础系统。

Restic 允许多个客户端同时备份到一个仓库，因为备份操作只获取共享锁，只有 prune 等维护操作才会获取独占锁。将 10 台相似的服务器指向同一个 restic 仓库后，它们会相互进行重复数据删除，第二台服务器及后续服务器通常只需存储很少的数据。代价是影响范围更大：所有数据集中在一个密码和一个仓库中，因此密码丢失会导致全部 10 台服务器的数据无法访问。

保留策略：先 forget 再 prune，还是先 prune 再 compact

这两个工具都会将“决定保留哪些内容”和“回收空间”分开处理，并且都要求您运行第二个步骤。

restic forget --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --prune
restic check

borg prune --list --glob-archives '{hostname}-*' \
  --keep-daily=7 --keep-weekly=4 --keep-monthly=6 /srv/borg/vps1
borg compact /srv/borg/vps1

两种工具中都存在同一个陷阱，必须明确说明。在 Borg 中，borg prune会删除归档，但不会自行释放磁盘空间。只有运行 borg compact 后，空间才会释放。因此，只执行 prune 而不执行 compact 的 cron 任务，会让仓库不断增长，即使归档列表一直很短。在 restic 中，不使用 --prune 执行 forget 只会删除快照引用，数据仍会保留，直到运行 prune。

在 prune 后运行 restic check。该命令会验证仓库结构，并报告是否存在损坏。这比在恢复过程中才发现问题要好得多。

恢复是唯一有效的测试

两个工具都会挂载快照，因此您可以浏览其中的内容。这是恢复单个文件最快的方法。

restic snapshots
restic restore latest --target /tmp/restore --include /etc/nginx
restic mount /mnt/restore

borg list /srv/borg/vps1
borg extract --list /srv/borg/vps1::vps1-2026-07-30T02:00:00 etc/nginx
borg mount /srv/borg/vps1::vps1-2026-07-30T02:00:00 /mnt/restore

注意 borg extract 中的路径格式。归档文件中的路径不包含开头的斜杠，因此 etc/nginx 是正确写法，而 /etc/nginx 不会匹配任何内容，也不会提取任何文件；命令不会报错说明原因。提取操作还会写入当前工作目录，因此应先切换到临时目录，否则旧文件可能覆盖正在使用的文件。

恢复过程即使无错误完成，也不能证明恢复成功，因为上层应用对完整恢复有自己的判断标准：从 Postgres 数据目录副本重建的 Immich 服务器，磁盘上虽然存在所有照片，但时间线为空。这正是 备份和恢复 Immich 必须解决的问题。

无论选择哪个工具，计划任务都只完成了一半。应定期将数据恢复到临时目录，并实际监控恢复过程，就像 VPS 的 restic 备份指南 中通过 systemd timer 执行完整演练一样。

哪种工具适合哪类任务

如果目标是对象存储，或者您希望只使用一个二进制文件、无需在远端安装软件，又或者需要让多台机器相互去重，请选择 restic。如果执行恢复的人员可能不是您本人，也应选择 restic。它是一个静态二进制文件，只需提供存储库 URL 即可使用。从运维角度看，这种方式很难超越。

如果目标是您控制的 Linux 主机，网络链路存在延迟且数据集包含数百万个小文件，或者您希望使用 append-only SSH key 防范勒索软件，又或者希望针对每项任务调整压缩设置，请选择 Borg。它是较早出现的工具，稳定版本系列更新缓慢；对于备份软件而言，这是优点。

两者都是正确选择。错误的选择是从未测试过的那个。如果您已经执行应用层转储，请继续保留这些转储：带数据库转储的 Nextcloud Docker 部署中的模式同样适用于这两种工具，因为在随机时刻复制正在使用的数据库文件，并不等于备份数据库。

FAQ

restic 和 BorgBackup 哪个更快？

在本地磁盘或高速 LAN 上，两者速度接近，最终都受源端读取速度和哈希计算速度限制。在延迟较高的 SSH 链路上处理大量小文件时，Borg 往往更快，因为远端的 borg serve 进程可以处理索引查询，不必为每个数据块进行一次网络往返。目标为对象存储时，restic 往往更快，因为稳定版 Borg 根本无法直接使用对象存储。

BorgBackup 可以备份到 S3 或 Backblaze B2 吗？

稳定版 1.4 系列不支持。Borg 1.4 仓库由 SSH 上的 borg serve 进程提供服务，而存储桶内不会运行此类进程。Borg 2 通过 borgstore 层增加了 s3:、b2: 和 rclone: 仓库 URL，但截至 2026 年 10 月，Borg 2 仍处于 beta 阶段，项目方表示不要将其用于生产环境。使用 1.4 时，可以通过 rclone 将对象存储挂载为文件系统来绕过这一限制。Borg FAQ 不建议将网络文件系统用于仓库存储，并警告 FUSE 和网络文件系统可能导致速度变慢或数据损坏。如果目前需要将对象存储用于生产备份，请使用 restic。

可以让两个工具处理同一份数据吗？

可以，有些人确实这样做：使用 Borg 备份到第二台服务器，以便快速进行本地恢复；使用 restic 备份到对象存储，作为异地副本。两者不共享任何数据，因此读取和哈希计算的开销会产生两次，并且需要安全保存两套密码。只有在测试过两种恢复流程后，才应采用这种方案。

如果丢失仓库密码，会发生什么？

使用这两个工具时，数据都将无法恢复。restic 使用 scrypt 根据密码派生密钥，并且没有绕过方法。Borg 在 repokey 模式下将加密密钥存储在仓库内，因此只需密码短语即可恢复；在 keyfile 模式下，还需要来自 ~/.config/borg/keys/ 的密钥文件。请将密码保存在不位于被备份服务器上的密码管理器中。如果使用 keyfile，请通过 borg key export 导出 Borg 密钥。

应该等 Borg 2.0 吗？

不应该。截至 2026 年 10 月，Borg 2.0 仍处于 beta 阶段，版本为 2.0.0b25（于 2026 年 9 月 27 日发布），项目方仅将其标记为测试版本。稳定系列是 1.4，目前版本为 1.4.5。现在即可开始使用 1.4。Borg 2 更改了仓库格式，并提供了文档化的升级路径（borg transfer --from-borg1），因此今天开始使用不会导致后续无法迁移。Borg 2 也是原生 S3、B2 和 rclone 支持的引入版本，但需等其稳定后再使用。