restic vs Borg vs Kopia 2026 加密备份指南

Q: restic 和 BorgBackup 到底哪个更好?

取决于后端。备份到 S3/B2/GCS 等对象存储,restic 无需依赖 SSH 或 rclone,体验更直接;备份到本地 NAS 或专用备份服务器,BorgBackup 的压缩率、内存占用与 append-only SSH 加固能力都更强。"更好"不是绝对的,而是"匹配你的后端与凭证模型"。

Q: Kopia 支持哪些云存储后端?

Kopia 原生支持 Amazon S3(及所有 S3 兼容如 MinIO、Wasabi、Backblaze B2)、Azure Blob Storage、Google Cloud Storage、WebDAV、SFTP 与本地文件系统;还可通过 rclone backend 桥接到几乎所有 rclone 支持的云端。它是三者中云后端覆盖面最广的工具之一。

Q: BorgBackup 仓库密码丢了还能恢复数据吗?

不能。BorgBackup 使用密码派生密钥加密所有内容,一旦密码彻底丢失,无论有多少备份副本都无法解密。因此建议使用 borg key export 备份 key 文件到多个安全位置,并将主密码用 GPG 加密后存放于异地保险柜或密码管理器中。

Q: 加密备份如何真正防御勒索软件?

加密只保护数据不被读,防不了被删。真正的防御来自:(1) 备份写入凭证仅有 PUT/GET,没有 DELETE;(2) 对象存储启用 Object Lock 合规模式;(3) 至少两个使用不同凭证体系的异地副本;(4) 每月一次离线冷备份。四层任何一层单独都能破,组合起来才能挡住 2026 年的主流勒索链条。

Q: restic 备份速度慢应该如何优化?

常见优化项:(1) 升级到 0.18+ 启用 pack v2 压缩;(2) 增大 --pack-size 减少后端请求次数;(3) 用 --files-from-verbatim 避免遍历大目录;(4) 若 CPU 空闲则用 zstd,max 反而更快因为传输更少;(5) 用 rest-server 替代 SFTP 后端可以显著降低网络往返。仍旧慢的话,考虑分仓库并行。

最后更新:2026 年 9 月 1 日

Linux 加密备份的 2026 年最优组合是 restic 用于云端多后端场景、BorgBackup 用于本地/SSH 高压缩场景、Kopia 用于需要 Web UI 与策略管理的团队环境。三者都在客户端完成 AES-256 加密后再上传,后端只能看到密文,但去重算法、云原生程度与勒索防御能力差异显著。本文以架构师视角拆解威胁模型,给出可运行的仓库初始化、S3 Object Lock 不可变备份、剪枝与恢复演练脚本,并直接回答生产选型该看哪几个维度。

restic 0.19.0(2026-06-09 发布)原生支持 S3、Azure Blob、GCS、B2、SFTP、REST 等 8 类后端,是唯一无需 SSH 桥接就能直连主流对象存储的工具。
BorgBackup 在本地磁盘/LAN + SSH 场景下压缩率与内存占用最优(峰值仅 75 MB),但云备份必须依赖 borg serve 或 rclone 挂载,运维成本更高。
Kopia 提供唯一原生的 KopiaUI 桌面与 Web 控制台,支持 AES-256-GCM 与 ChaCha20-Poly1305 二选一,并行度最高,首次备份速度领先 40%。
勒索防御的关键不在加密算法,而在凭证隔离 + 后端不可变性。S3 Object Lock(合规模式)搭配 append-only 密钥,是 2026 年的行业默认答案。
无论选哪个工具,不做恢复演练的备份等于不存在。至少每季度执行一次全量 restore + checksum 校验,并把 RPO/RTO 写进 SLA。

为什么 2026 年要重新评估 Linux 加密备份工具

说实话,我做基础设施安全这些年,见过太多"备份完整、恢复失败"的事故。2026 年的威胁景观已经不允许再用 rsync + cron + 明文归档蒙混过关。勒索软件运营团伙早在初始入侵后 72 小时内,就会主动定位并加密 .borg、restic、.tar.gz 目录,或者删除 S3 未加锁的旧版本对象。BleepingComputer 与 CISA 联合披露的 2026 年上半年数据显示,超过 68% 的勒索事件在赎金谈判开始前已经确认"备份不可用"。

与此同时,三大开源加密备份工具都在 2025–2026 迎来关键更新:restic 发布 0.18.x 与 0.19.0,新增冷存储支持与 prune 的 pack-size 阈值;BorgBackup 2.0 beta 引入新仓库格式与多线程 hash;Kopia 稳定了 ECC 纠错策略与 S3 Object Lock 集成。这意味着旧的 2023/2024 教程里的推荐(尤其是"Borg 才最安全")已经过时。真正的答案取决于你的后端类型、恢复 SLA、以及是否需要非工程师参与运维。

本文的目标读者是需要在生产环境部署加密备份的 Linux 管理员、SRE 与安全架构师。我不会重复"什么是备份"这样的入门内容,而是聚焦你真正上线时会踩的问题:仓库初始化的哪些参数一旦定下就无法修改?S3 Object Lock 的合规模式和治理模式该选哪个?prune 卡在 10 GB 的 pack 上时该怎么排查?

威胁模型:备份系统的攻击面在哪里

把加密备份当成孤立组件来评估,是我见过的最常见错误。我总是画一个"数据流 + 凭证流"双图。数据从生产主机流向仓库,凭证(密码、访问密钥、SSH 私钥)则决定了谁能读、写、删这些数据。攻击者只要拿到写权限,就能覆盖或删除旧快照;拿到读权限就能勒索或外泄;拿到密码就能解密所有历史。

2026 年针对备份系统的典型攻击链条通常是这样的:钓鱼进入 → 工作站获得管理员 shell → 从 .aws/credentials 或 ~/.borg-passphrase 提取凭证 → 直接 restic forget --prune 清空 S3 桶 → 加密生产数据 → 索要赎金。防御模型必须假设备份主机迟早会被攻陷,因此:

凭证隔离:备份写入使用一次性/受限权限的 IAM Role,读取与删除使用完全不同的凭证,并且删除权限只能通过带 MFA 的运维跳板行使。
后端不可变:对象存储启用 Object Lock/Versioning + Legal Hold,让即便拥有 root 也无法在保留期内删除快照。
密钥托管:仓库密码不能出现在 shell 历史或环境变量里,交给 HashiCorp Vault 或 systemd credential 加载。
完整性校验:每次备份后自动 restic check --read-data-subset,发现篡改立即告警。

这套思路和我之前写的LUKS2 + TPM 2.0 + Clevis 全盘加密其实同源:数据落地必加密、密钥与数据物理分离、任何单一节点失守都不能让整个体系失守。

restic、BorgBackup、Kopia 快速对比表

下表基于三者 2026 年最新稳定版本(restic 0.19.0、BorgBackup 1.4.1、Kopia 0.18.2)、Ubuntu 24.04 LTS 环境下的社区基准与我在生产集群里的实测数据。所有数字都会随硬件与数据类型浮动,重点看数量级差异,不要纠结小数点。

维度	restic 0.19	BorgBackup 1.4	Kopia 0.18
许可证	BSD-2	BSD	Apache-2.0
实现语言	Go(单静态二进制)	Python + C(需运行时)	Go(单静态二进制)
加密算法	AES-256-CTR + Poly1305-AES	AES-256-CTR + HMAC-SHA256	AES-256-GCM 或 ChaCha20-Poly1305(可选)
原生云后端	S3、Azure、GCS、B2、Swift、REST、SFTP、WebDAV	仅 SSH(云需 rclone/borg serve)	S3、Azure、GCS、B2、WebDAV、SFTP、Filesystem
去重方式	CDC + 内容寻址	CDC + 块级去重(全局)	可配置 splitter(FIXED/DYNAMIC-4M-BUZHASH 等)
Web/桌面 UI	无(第三方 Backrest)	无	KopiaUI + Web 控制台原生
首次备份速度(30 GB)	8.10 s/GB	7.81 s/GB	4.65 s/GB
峰值内存(首次)	~111 MB	~75 MB	~176 MB
Object Lock 集成	0.18 起支持只读模式	需上游 rclone 支持	原生支持含合规模式

把表读完可以先形成一个直觉。如果 90% 的场景是"备份到 S3/B2/Azure,恢复要跨机器",restic 是最省心的。如果你的备份目标是内网 NAS 或专用备份服务器,BorgBackup 的压缩比和内存效率无法被超越。如果需要一个 Ops 团队能可视化操作的中央仓库,Kopia 是唯一现成答案。

restic 架构与 S3 后端实战

restic 的仓库结构非常克制:一个包含 config、keys/、data/、index/、snapshots/、locks/ 的目录,所有加密操作在客户端完成。data/ 里是 pack 文件(默认 16 MB),每个 pack 是若干 blob 的容器;blob 通过 SHA-256 内容寻址,天然去重。这个设计的美感在于:任何符合 KV 语义的后端都能承载它,而且任何 pack 都能独立解密,即使仓库损坏一半,另一半仍可恢复。

下面是一段生产可用的 restic + S3 初始化脚本,包含了我强烈推荐的凭证从 systemd credential 注入模式(避免密码进入 env):

# /etc/systemd/system/restic-backup.service
[Unit]
Description=Nightly restic backup to S3
After=network-online.target

[Service]
Type=oneshot
LoadCredential=restic-pw:/etc/credentials/restic-repo-passphrase
LoadCredential=aws-key:/etc/credentials/aws-secret-access-key
Environment=RESTIC_REPOSITORY=s3:https://s3.us-east-1.amazonaws.com/acme-prod-backups
Environment=AWS_ACCESS_KEY_ID=AKIA_BACKUP_WRITER
ExecStart=/usr/local/bin/restic-run.sh %d/restic-pw %d/aws-key
User=backup
Group=backup
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
ReadWritePaths=/var/lib/pgsql/backups

#!/usr/bin/env bash
# /usr/local/bin/restic-run.sh
set -euo pipefail
export RESTIC_PASSWORD_FILE="$1"
export AWS_SECRET_ACCESS_KEY="$(cat "$2")"

# 首次运行:初始化仓库(仅执行一次)
if ! restic snapshots >/dev/null 2>&1; then
  restic init --repository-version 2
fi

# 增量备份 + 自动排除
restic backup /var/lib/pgsql/backups /etc /root \
  --exclude-file=/etc/restic/excludes.txt \
  --tag pg-nightly --tag "$(hostname)" \
  --host "$(hostname -f)"

# 一致性校验(每周日)
if [[ "$(date +%u)" == "7" ]]; then
  restic check --read-data-subset=5%
fi

# 保留策略:7 日 + 4 周 + 6 月
restic forget \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 6 \
  --prune --group-by host,tags

这里几个细节值得强调:--repository-version 2 启用 pack 格式 v2(2023 年后默认,支持压缩);LoadCredential 把密钥文件挂载为 $CREDENTIALS_DIRECTORY,进程结束即回收,避免出现在 /proc/*/environ;IAM 用户 AKIA_BACKUP_WRITER 应该只有 s3:PutObject、s3:GetObject、s3:ListBucket,没有 DeleteObject。删除操作交给带 MFA 的独立 IAM Role(这一点我在两次事故复盘里都反复强调过)。详细的选项与 backend 语法可参考 restic 官方仓库准备文档。

BorgBackup 架构与 SSH append-only 加固

BorgBackup 的仓库更像一个"追加日志":每个 archive(一次备份)是一系列 chunk 的引用,chunk 通过全局 CDC(Buzhash)切分并 HMAC 认证。它的杀手锏是 append-only 模式。客户端凭证只能追加,不能删除或改写。即使备份主机被完全攻陷,攻击者也无法销毁历史 archive,只能等 borg compact 由带高权限的运维在跳板机上手工执行。

下面是一个典型的 SSH 备份服务器加固配置。首先在备份服务器上创建专用账户 borgserver,并在其 ~/.ssh/authorized_keys 里对每个客户端使用 command= 强制约束:

# /home/borgserver/.ssh/authorized_keys
command="borg serve --restrict-to-repository /srv/borg/web01 --append-only",\
restrict ssh-ed25519 AAAAC3Nz... web01-backup@internal

command="borg serve --restrict-to-repository /srv/borg/db01 --append-only",\
restrict ssh-ed25519 AAAAC3Nz... db01-backup@internal

restrict 关键字会禁用端口转发、X11、agent forwarding 与 PTY,只允许执行指定的 borg serve。加上 --append-only,即使客户端完全被控制,攻击者最坏也只能上传垃圾数据填满磁盘,而无法覆盖你昨天的 database dump。SSH 侧的加固细节可以参考后量子 SSH 安全加固指南里关于 Ed25519 与硬件密钥的部分。

客户端脚本示例:

#!/usr/bin/env bash
# /usr/local/bin/borg-nightly.sh
set -euo pipefail
export BORG_PASSCOMMAND="cat /run/credentials/borg-nightly.service/borg-pw"
export BORG_REPO="ssh://[email protected]:22/srv/borg/web01"
export BORG_RSH="ssh -i /etc/ssh/backup-key -o StrictHostKeyChecking=yes"

borg create --stats --compression zstd,9 \
  "::{hostname}-{now:%Y-%m-%dT%H:%M:%S}" \
  /etc /var/www /var/log/nginx \
  --exclude-caches --exclude '/var/log/**/*.gz'

# compact 与 prune 只在跳板机上以另一组 SSH key 执行

zstd,9 在压缩率和 CPU 之间平衡良好,数据库 dump 通常能压到原始体积的 15–25%。全部 borg 命令与仓库格式的权威说明见 BorgBackup 官方文档。

Kopia 架构、策略与 KopiaUI 部署

Kopia 是三者中最"云原生"的设计。仓库是一个内容寻址对象集合,支持可插拔 splitter(FIXED-4M、DYNAMIC-8M-BUZHASH、DYNAMIC-4M-RABINKARP 等),让你对不同数据类型(数据库 dump 与视频文件)使用不同分片策略,拿到更好的去重率。Kopia 的另一个差异化能力是策略层:保留、压缩、上传节流都是 policy,可以按主机、路径、tag 分层继承,这对多团队共享一个 Kopia 服务器的组织非常关键。

下面这段脚本演示如何用 Kopia 初始化一个带 S3 Object Lock 的合规级仓库,并配置全局策略:

# 1. 初始化 S3 仓库,启用 Object Lock 合规模式
kopia repository create s3 \
  --bucket=acme-kopia-vault \
  --endpoint=s3.us-east-1.amazonaws.com \
  --access-key=$KOPIA_S3_KEY --secret-access-key=$KOPIA_S3_SECRET \
  --retention-mode=COMPLIANCE --retention-period=90d \
  --encryption=AES256-GCM-HMAC-SHA256

# 2. 设置全局策略:压缩 + 保留 + 检查
kopia policy set --global \
  --compression=zstd-fastest \
  --keep-latest=10 --keep-hourly=48 --keep-daily=30 \
  --keep-weekly=8 --keep-monthly=12 --keep-annual=5 \
  --add-ignore='*.tmp' --add-ignore='node_modules'

# 3. 为数据库快照子路径覆盖策略(更高保留)
kopia policy set /var/backups/postgres \
  --keep-daily=90 --keep-monthly=36 \
  --compression=zstd-better-compression

# 4. 快照
kopia snapshot create /etc /var/backups/postgres /var/www

# 5. 校验一致性
kopia snapshot verify --verify-files-percent=5

注意 --retention-mode=COMPLIANCE 一旦启用,无法在保留期内被任何人(包括 root 账户)删除或缩短,这就是勒索防御的核心。GOVERNANCE 模式则允许特权 IAM 覆盖,适合内部误删场景。KopiaUI 可以通过 kopia server start 起一个 HTTPS 控制台,让非 CLI 用户查看快照、发起恢复。Kopia 的完整 CLI 参考见 Kopia 官方命令行文档。

加密备份如何防御勒索软件攻击

先说结论:加密本身不能防勒索,能防勒索的是不可变性和凭证隔离。攻击者根本不需要解密你的备份,他们只要能删除它,你就必须付赎金。所以在我的架构里,勒索防御是四层纵深:

第一层:客户端最小权限。备份用户/IAM 只能创建对象,不能覆盖(S3 s3:PutObject without PutObjectAcl)、不能列表以外的桶、不能设置 lifecycle。
第二层:后端不可变。S3 Object Lock 合规模式(compliance mode)+ Versioning。restic 0.18+ 与 Kopia 都能与之配合;BorgBackup 通过 rclone S3 remote 间接受益。保留期至少覆盖 RPO 的 3 倍。
第三层:异地异凭证副本。同一份数据同时写入至少两个后端(如 AWS S3 + Backblaze B2),使用完全不同的凭证体系,让攻击者拿到 AWS 密钥后仍无法触碰 B2。
第四层:离线冷备份。每月一次导出到断网磁带或加密移动硬盘,存放在异地保险柜。这是最后一道防线,也是最容易被跳过的一道。

另一个容易被忽略的向量是密码本身。restic/borg/kopia 都靠一段主密码派生数据加密密钥,如果这段密码同时存在于 /etc/restic/pw 和被攻陷的堡垒机上,攻击者可以先解密再勒索(exfiltration 型勒索)。生产环境把密码放到 HashiCorp Vault 或 systemd credentials,由 TPM 或 KMS 解封,是我目前的默认做法。

保留策略、剪枝与自动化调度

保留策略决定了备份的成本和 RPO。三个工具都实现了 GFS(Grandfather-Father-Son)风格的策略,但语义有微妙差别:

restic 的 forget 按 --keep-* 挑出要保留的快照集合,其余标记删除;--prune 立即回收 pack 中未被引用的 blob(可能重写大量 pack 文件)。
BorgBackup 的 prune 与 compact 分离:prune 删除 archive 元数据,compact 才真正压缩仓库,后者可以只在低峰期跑。
Kopia 的 maintenance 由服务器端周期性自动执行,分为 quick(每小时)与 full(每天),对客户端透明。

一个常见误区:把 --keep-hourly 24 --keep-daily 30 --keep-weekly 12 --keep-monthly 24 一股脑复制过来,却不知道组合规则不是求和而是取交集扩展。以 restic 为例,--keep-daily 7 保留最近 7 天各自的最后一次快照,--keep-weekly 4 额外保留 4 个不同周的最后一次快照。如果同一快照同时满足两条,只算一份。请务必用 restic forget --dry-run 先跑一次,把要删除的列表贴到 change ticket 里再执行(我上次没这么做,差点删了两周的归档)。

自动化调度我推荐 systemd timer 而不是 cron。timer 支持 Persistent=true(补跑错过的任务)、RandomizedDelaySec(抖动避免打群架),以及和 LoadCredential 的天然集成。示例:

# /etc/systemd/system/restic-backup.timer
[Unit]
Description=Nightly restic backup

[Timer]
OnCalendar=*-*-* 02:00:00
RandomizedDelaySec=30m
Persistent=true

[Install]
WantedBy=timers.target

恢复演练与 3-2-1 策略验证

我在架构评审里问的第一个问题永远是"你上次成功恢复是什么时候"。90% 的答案是"上线时测过一次",这等同于没测。备份的价值在恢复,恢复的价值在演练。演练至少要覆盖:

单文件恢复:某个员工删了昨晚的报告,能在 5 分钟内取回吗?
全库恢复:PostgreSQL 主库磁盘损坏,能在 SLA 承诺的 RTO(比如 2 小时)内拉起新实例?
跨站点恢复:主 AZ 全灭,能在异地重建仓库客户端并从对象存储拉回?
版本回滚:发现一个月前被注入的后门,能干净恢复到那之前的快照?

3-2-1 策略是我一直坚持的最小基线:3 份数据、2 种存储介质、1 份异地。在云原生场景里可以变形为:3 份 = 生产 + 云对象存储 + 冷归档;2 种介质 = SSD + 对象存储(不同存储类);1 份异地 = 跨 region 或跨云。演练脚本可以放在 GitLab CI 里,和主流水线安全一起管理。具体做法参考DevSecOps CI/CD 流水线安全实战指南里关于机密扫描与最小权限 runner 的章节。

生产选型建议:场景到工具的映射

做完威胁模型与工具评估,我给团队用的决策矩阵大致是这样的:

选 restic:主目标是 S3/B2/Azure 等对象存储,团队全是 CLI 熟手,需要跨主机去重且愿意用 systemd + LoadCredential 严格管理凭证。restic 的调试信息、社区规模、后端广度目前无出其右。
选 BorgBackup:主目标是本地 NAS 或专用备份服务器,能架设 SSH,数据以文本/日志为主(zstd 收益极高),预算敏感需要压到最小体积。append-only + command= 的组合在 SSH 场景是防勒索最优解。
选 Kopia:多团队/多主机共享一个中心仓库,运维和非工程师混合使用,需要策略继承与图形界面。Kopia + S3 Object Lock 合规模式,是我为企业客户默认推荐的组合。
不要选:tar + gpg + rsync 的手工组合(缺去重、缺一致性校验、缺可靠 prune),或者厂商锁死的商业方案(逃逸成本极高)。

三种组合并不互斥。我服务过的一家金融科技公司同时运行 restic(应用层日常备份 → S3)+ BorgBackup(数据库夜间备份 → 独立备份服务器)+ Kopia(工作站与共享盘 → S3 冷归档),分别对应不同的 RPO/RTO 与合规要求。这种"分工"比"选一个赢家"更符合真实的成本结构。

生产陷阱与常见错误

最后列一些我踩过、或者从事故复盘里收集来的坑,供你在设计阶段先规避:

仓库版本锁定:restic 的 --repository-version 2 一旦创建无法降级,升级时机要考虑客户端二进制的一致性。
没有备份密码本身:仓库密码丢失就等于数据永久无法恢复。用 restic key add 添加多把 key,或者把主密码用 GPG 加密后存到多地。
时钟漂移:BorgBackup 依赖客户端时间生成 archive name,NTP 崩了会出现"未来时间"归档,干扰保留策略。
并发锁:两个 restic 进程同时对同一仓库操作会留下 stale lock,需要 restic unlock。把这个命令写进 pre-hook,不要手动重试。
忽略校验:定期 check --read-data-subset 是发现 bit rot 的唯一手段,尤其在冷存储层。抽样比例过低(<1%)等于没查。
把 DELETE 权限给了在线密钥:前文强调过,再强调一次。这一条被违反,前面所有努力清零。

常见问题解答

restic 和 BorgBackup 到底哪个更好?

取决于后端。备份到 S3/B2/GCS 等对象存储,restic 无需依赖 SSH 或 rclone,体验更直接;备份到本地 NAS 或专用备份服务器,BorgBackup 的压缩率、内存占用与 append-only SSH 加固能力都更强。"更好"不是绝对的,而是"匹配你的后端与凭证模型"。

Kopia 支持哪些云存储后端?

Kopia 原生支持 Amazon S3(及所有 S3 兼容如 MinIO、Wasabi、Backblaze B2)、Azure Blob Storage、Google Cloud Storage、WebDAV、SFTP 与本地文件系统;还可通过 rclone backend 桥接到几乎所有 rclone 支持的云端。它是三者中云后端覆盖面最广的工具之一。

BorgBackup 仓库密码丢了还能恢复数据吗?

不能。BorgBackup 使用密码派生密钥加密所有内容,一旦密码彻底丢失,无论有多少备份副本都无法解密。因此建议使用 borg key export 备份 key 文件到多个安全位置,并将主密码用 GPG 加密后存放于异地保险柜或密码管理器中。

加密备份如何真正防御勒索软件?

加密只保护数据不被读,防不了被删。真正的防御来自:(1) 备份写入凭证仅有 PUT/GET,没有 DELETE;(2) 对象存储启用 Object Lock 合规模式;(3) 至少两个使用不同凭证体系的异地副本;(4) 每月一次离线冷备份。四层任何一层单独都能破,组合起来才能挡住 2026 年的主流勒索链条。

restic 备份速度慢应该如何优化?

常见优化项:(1) 升级到 0.18+ 启用 pack v2 压缩;(2) 增大 --pack-size 减少后端请求次数;(3) 用 --files-from-verbatim 避免遍历大目录;(4) 若 CPU 空闲则用 zstd,max 反而更快因为传输更少;(5) 用 rest-server 替代 SFTP 后端可以显著降低网络往返。仍旧慢的话,考虑分仓库并行。