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 年 7 月，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 server、S3、Backblaze B2、Azure、Google Cloud Storage，以及 rclone 能访问的任何存储。

Borg 仓库同样是磁盘上的文件，但 Borg 不会通过简单传输协议访问它。对于远程仓库，Borg 会通过 SSH 在远端启动 borg serve，并与该进程使用自有协议通信。服务器端会执行实际操作：保存仓库、应用事务并响应索引查询。这就是 Borg 没有 S3 后端，以及项目没有添加 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 或 max。旧的格式 1 仓库在迁移前仍不会压缩。因此，如果您的 restic 仓库早于 0.14，且您从未迁移过，那么文本、日志和数据库转储仍会占用完整大小。

远程目标：S3 与 SSH

通常需要在这里做出选择。

restic 访问 S3 时，只需要在环境中提供凭据，不需要在其他位置运行任何服务。同样的模式也适用于您自行托管的存储桶。这是一种常见组合：运行 在您自己的 VPS 上提供 S3 API 的 MinIO，然后将 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。远端的版本还必须与客户端兼容。如果远端不属于您，这会增加配置难度。如果远端是您已经管理的第二台服务器，则不会带来额外问题。此方案还提供了两种工具中针对勒索软件最强的控制措施：仅允许追加的 SSH 密钥。强制该密钥运行 borg serve 后，客户端可以添加归档，但不能删除归档。因此，即使机器遭到入侵，也无法清除自身的历史备份。

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

只有运行 restic 自己的 REST 服务器时，restic 才具有等效功能。该服务器支持仅允许追加的模式。对于普通 S3，可以通过存储桶策略或对象锁实现相同效果。这属于服务提供商的功能，不是 restic 的功能。还应限制传输通道，因为 SSH 端同样需要像其他登录方式一样谨慎处理：对备份账户应用仅允许密钥登录并限制 authorized_keys 条目。

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

两个项目都没有发布值得您直接用于自身数据的基准测试，因此应根据工作机制进行判断。

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

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

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

锁定以及备份多台计算机

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

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

保留策略：先忘记再清理，还是先清理再压缩

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

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 后，空间才会被回收。因此，只执行清理而从不压缩的 cron 任务，会导致存储库不断增长，而归档列表仍然很短。在 restic 中，仅运行 forget 而不运行 --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 不会匹配任何内容，也不会提取任何文件；命令不会报错说明原因。提取操作还会写入当前工作目录，因此请先切换到临时目录，否则旧文件会覆盖正在使用的文件。

无论选择哪个工具，计划任务都只完成了一半工作。请定时将恢复操作执行到临时目录，并实际监控该任务，就像 VPS 的 restic 备份指南完整演示的那样，使用 systemd timer。

哪个工具适合哪种任务

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

如果目标是您控制的一台 Linux 主机，或者链路延迟较高且数据集包含数百万个小文件，或者您希望使用仅允许追加的 SSH key 来防御勒索软件，又或者希望按任务调整压缩设置，请选择 Borg。它是较早的工具，稳定系列的更新速度较慢；对于备份软件而言，这是一个优点。

两者都是正确的选择。错误的选择是从未测试过的那个。如果您已经生成应用级转储，请继续保留这些转储：带数据库转储的 Docker Nextcloud 设置中的方法适用于这两种工具，因为在随机时刻复制一个正在使用的数据库文件，并不能得到数据库备份。

FAQ

restic 和 BorgBackup 哪个更快？

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

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

不能直接备份。Borg 仓库由 SSH 上的 borg serve 进程提供服务，而存储桶内部不会运行此类进程。用户通常会使用 rclone 将对象存储挂载为文件系统，但 Borg 项目不建议这样做，因为挂载点如果在事务执行过程中断开，可能损坏仓库。如果需要使用对象存储，请使用 restic。

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

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

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

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

应该等待 Borg 2.0 吗？

不应该。截至 July 2026，Borg 2.0 仍处于 beta 阶段，版本为 2.0.0b22，项目将其标记为仅供测试使用。稳定版本系列为 1.4，目前版本为 1.4.5。现在即可开始使用 1.4。Borg 2 更改了仓库格式，并提供了文档化的升级路径，因此现在开始使用不会导致之后无法迁移。