SSD Nodes Learn Hosting plans →
指南 Matt Connor作者: Matt Connor · 更新于 2026-08-22

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

Restic 可直接写入 S3 和对象存储,无需远端安装程序;Borg 需远端运行 Borg,通过 SSH 通常更快。本文附命令,比较两者的仓库模型、加密和部署取舍。

Restic 与 BorgBackup 的对比(一个段落)

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

其他差异都相对较小。两者都会使用按内容定义的分块方式拆分文件,因此一个发生了 200 MB 变化的 40 GB 目录,大约只会上传 200 MB。两者都会在客户端加密。两者都可以通过 FUSE(用户空间文件系统)挂载快照,以便复制出单个文件。截至 July 2026,restic 的版本为 0.19.1,Borg 的稳定版本系列为 1.4,当前版本为 1.4.5。Borg 2.0 多年来一直处于 beta 阶段,目前仍标记为仅供测试,因此现在应部署 1.4。

仓库模型才是真正的区别

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

Borg 仓库同样是磁盘上的文件,但 Borg 不会通过简单传输协议访问它。对于远程仓库,Borg 会通过 SSH 在远端启动 borg serve,并与该进程使用自有协议通信。服务器端会执行实际操作:保存仓库、应用事务,以及响应索引查询。这就是 Borg 没有 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;如果您更关注占用空间而不是处理时间,可以使用 zliblzmaauto 会针对每个数据块运行启发式判断,因此不会对已经压缩的数据再次压缩。

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

在仓库格式 2 之前,Restic 完全不支持压缩。仓库格式 2 需要 restic 0.14.0 或更高版本。现在,新建仓库默认使用格式 2,可通过 --compression 设置压缩级别,取值为 autooffmax。旧的格式 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 server 时,restic 才具备等效功能;该 server 支持仅允许追加的模式。对于普通 S3,可通过存储桶策略或对象锁实现相同效果。这属于提供商的功能,不是 restic 的功能。还应限制传输方式,因为 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 吗?

不能直接备份。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 会更改仓库格式,并提供文档化的升级路径,因此现在开始使用不会导致以后无法迁移。