如果生产服务器能够写入备份 NAS（网络附加存储），控制了这台服务器的攻击者也就控制了你的备份。经典 3-2-1 备份规则一直没有解决这个缺口：它统计副本数量，将副本放在不同介质和地点，却没有规定谁能够删除它们。勒索软件团伙往往先攻击备份仓库，然后才开始加密数据。

本文比较厂商文档和审计中常见的三种策略：基础的 3-2-1、扩展的 3-2-1-1-0，以及不可变副本，包括 S3 Object Lock（对象锁）、只追加服务器和离线介质。下面会说明每一层防护针对什么风险、近期勒索软件调查如何描述备份恢复，以及如何为自己的环境选择方案。实验部分记录的是 2026 年 10 月在两台 Ubuntu 26.04 虚拟机上进行的测试，使用 restic 0.18.1 和只追加模式的 rest-server；文中的错误消息和耗时均来自该实验。

3-2-1 备份规则及其防护范围

3-2-1 备份规则要求：重要数据保留三份副本，即主数据加两份备份；使用两种不同介质；其中一份放在异地。US-CERT 的《Data Backup Options》（2012 年）以同样的方式定义了这一规则，并将其归功于摄影师 Peter Krogh 的《The DAM Book》（2009 年）。这项规则针对硬件故障、火灾和盗窃而提出，因此每个数字都描述存放位置，没有一个描述访问权限。

实际应用中，每个数字对应一种设计时考虑的故障：

• 三份副本：单个磁盘损坏或一次备份任务生成坏数据，不会让你失去全部可用副本。
• 两种介质：固件缺陷或一批有问题的硬盘不应同时影响两份副本。无论包含多少块磁盘，ZFS 镜像都只算一种介质；ZFS RAID 级别说明中也解释了这一点。
• 一份异地副本：发生洪水、火灾或整个机架被盗后，其他地点仍有一份数据。

这三个条件都没有回答事件响应人员首先关心的问题：入侵者能否删除备份。假设备份服务器使用某个密钥写入云存储桶，而这个密钥也能删除对象。存储桶位于异地、使用不同介质，满足 3-2-1，但密钥被盗后，一次 API 调用就可能清空它。本文后续所有措施都围绕这个缺陷展开。

勒索软件事件中的备份恢复数据

备份会影响勒索软件受害者是否支付赎金，而调查表明，真正需要恢复时，副本常常不可用。Sophos《The State of Ransomware 2026》报告发现，数据被加密的组织中有 66% 通过备份恢复，高于 2025 年报告的 54%；后者是六年来的最低水平。同一时期，支付赎金的比例降至 48%，赎金中位数从 100 万美元降至 76.9 万美元。

应观察趋势，而非只看某一年。通过备份恢复的比例在 2022 年报告中达到 73% 的峰值，随后连续三期下降。同一阶段，支付赎金并取回数据的比例在 2024 年报告中升至 56%。2025 年报告中，支付金额超过攻击者最初要求的组织有 38% 给出了相同理由：“我们的备份失败或无法正常工作。”备份在纸面上存在，但关键时刻恢复失败。 图中每年的比例依据相应年份的 Sophos 调查；受访者可以使用不止一种恢复方式，因此两项比例不能相加视为 100%。图中 2020 至 2023 年数值引用自 2025 年报告，图表资料还包括 2024 年报告。

Veeam 的调查也指向相同问题。《2024 Ransomware Trends》报告发现，攻击平均影响 41% 的数据，而这些数据仅有 57% 得到恢复。受访组织中有 81% 支付赎金，付款者仍有三分之一无法恢复。Veeam《Data Trust and Resilience Report 2026》进一步揭示了信心与结果之间的差距：90% 的组织认为自己能够恢复，但业务或数据受到勒索软件影响的组织中，仅 28% 恢复了全部受影响数据。CISA 的《#StopRansomware Guide》用一句话解释了原因：“许多勒索软件变种会尝试寻找可访问的备份，随后删除或加密它们。”

3-2-1-1-0 规则：一份不可变副本，恢复验证零错误

3-2-1-1-0 保留 3-2-1 的全部要求，并增加两个条件：至少一份副本不可变、物理隔离或离线；恢复验证没有错误。Veeam 将其描述为自己对该规则的扩展：“在 Veeam，我们把规则扩展为 3-2-1-1-0。”依次解释这些数字：

1. 3 份数据副本，包含生产数据。
2. 2 种介质，避免一个硬件故障毁掉两份副本。
3. 1 份异地副本，应对整个站点损失。
4. 1 份不可变或离线副本，生产环境凭据无法修改或删除它。
5. 自动化或定期恢复测试完成后，0 个错误。

第四个数字回答“谁能删除它”，第五个数字回应前述 Sophos 调查：从未恢复过的备份，其可用性仍然只是一个假设。应把“零错误”落实为定期执行的任务。每月将一部分样本恢复到临时虚拟机，并与源数据比较哈希，可以在事件发生前发现凭据过期、路径变化或挂载点被排除等静默失败。

不可变、只追加与离线副本

“不可变”包含多种机制，它们的信任模型差别很大，这些差异决定了谁仍然能够毁掉副本。对每一种机制，都必须知道哪个账户能在保留期限到期前删除数据，以及攻击者需要攻陷什么才能使用该账户。

合规模式是大多数团队能够购买的最强锁定机制，但也存在陷阱。CISA 明确提醒：“谨慎使用不可变存储，因为它不满足某些法规的合规标准，而错误配置可能造成显著成本。”Backblaze B2 允许设置 1 至 3,000 天保留期；误设为 3,000 天，就会产生无法取消的账单。应将保留期设为略长于发现入侵所需的时间，先在临时存储桶上测试，并为存储桶设置配额。

只追加服务器成本更低，适合自行托管的环境，但其保证只针对客户端。BorgBackup 文档说明，在只追加模式下，borg delete 和 borg prune 仍会运行，只是不能释放空间；服务器管理员可以通过事务日志回滚仓库。必须先执行回滚，因为被攻陷客户端记录的删除操作，会在管理员下一次不使用只追加模式执行 borg compact 等写操作时生效。Proxmox Backup Server（PBS）的“protected”快照标记也属于这一类工具：它阻止对该快照进行清理和手动删除，但只是快照标记，并非存储层锁定。因此，如果需要满足第四个数字，应为 PBS 配合离线磁带或 Object Lock 存储桶。Proxmox Backup Server 主机构建说明介绍了数据存储一侧的配置。

实验：清空攻击后只追加副本仍然存活

为比较可修改副本与只追加副本，实验搭建了两台虚拟机。应用主机 app-eu-west-1a 保存 324 MB 样本数据，共 9,051 个文件，通过 restic 备份到两个仓库：本地 /backup/local-repo，以及 backup-vault-1b 上的远端仓库。后者运行 rest-server v0.14.0，只追加模式已启用。模拟攻击者获得应用主机 root 权限、仓库密码文件和两个仓库地址；真实勒索软件读取备份脚本后，通常也能获得这些信息。

只追加行为完全由备份主机上的 rest-server 服务单元实现。启动前，需要把 GitHub 发布的 rest-server 二进制放入 /usr/local/bin，创建拥有 /srv/restic 的 restic 系统用户，并在 /srv/restic/.htpasswd 创建 bcrypt 密码文件。实验使用 htpasswd -B 为名为 app01 的用户创建密码，以匹配仓库路径。rest-server 默认启用身份认证并读取该文件。打开服务单元文件：

sudo vim /etc/systemd/system/rest-server.service

实验运行的就是下面这份服务单元。--private-repos 将每个 htpasswd 用户限制在与其用户名匹配的仓库路径；加固配置让服务只能在 /srv/restic 下写入。实验在私有网络中使用明文 HTTP；在实验环境之外，应增加 --tls、--tls-cert 和 --tls-key，避免基本认证密码以明文在网络上传输：

[Unit]
Description=restic rest-server (append-only)
After=network-online.target
Wants=network-online.target

[Service]
User=restic
Group=restic
ExecStart=/usr/local/bin/rest-server --path /srv/restic --listen :8000 --append-only --private-repos
Restart=on-failure
NoNewPrivileges=true
ProtectSystem=strict
ReadWritePaths=/srv/restic
PrivateTmp=true

[Install]
WantedBy=multi-user.target

两个仓库首次备份相同数据都用了不到 9 秒，本地 8.9 秒，远端 6.8 秒，压缩后存储 284 MiB。第二次备份包含一个修改的文件和一个新增的 5 MiB 文件，分别耗时 1.5 秒和 2.6 秒。此时每个仓库都有两份快照。应用主机上的模拟攻击者使用 openssl 加密数据库文件，删除其他数据，然后攻击备份。下面的截图是节选；root shell 中的 LOCAL 和 REMOTE 保存两个仓库位置，RESTIC_PASSWORD_FILE 指向窃取的密码文件：

一次 rm -rf 就让本地仓库消失，所有生产凭据能触及的备份都面临这种结局。远端 forget --prune 在删除快照时收到 403 Forbidden，但继续规划和重新打包；随后删除索引也被拒绝，最终以退出码 1 结束。之后仍能列出两份快照。直接发送 HTTP 请求也没有成功：对快照或数据包执行 curl -X DELETE 返回 403；POST 覆盖已有快照对象返回 403；DELETE 仓库根路径返回 405 Method Not Allowed。

restic 0.18 的 forget 收到“403 Forbidden”后仍返回 0

有一个结果会影响所有编写保留策略脚本的人。Ubuntu 26.04 的 restic 0.18.1 对只追加仓库执行普通 restic forget <id> 时，打印了 403 和“unable to remove”，退出码却为 0；forget --prune 则返回 1。restic 0.19.0 变更日志修复了这个问题：forget 无法删除快照时，现在返回退出码 3。下面的单快照操作展示了旧行为：

restic -r $REMOTE forget b69a9d65; echo exit=$?

屏幕上出现错误，但 shell 看到的是成功：

[0:00] 0.00%  0 / 1 files deleted
Remove(<snapshot/b69a9d650b>) failed: unexpected HTTP response (403): 403 Forbidden
unable to remove snapshot/b69a9d650b9a10fb7c2bc85753e08a3d7f6cb33d689809f77fc4e15858236b60 from the repository
exit=0

在 0.18.x 及更早版本中，只检查退出码的 cron 任务会把没有删除任何数据的保留操作报告为成功，仓库持续增长直到磁盘写满。如果继续使用这些版本，需要用 grep 检查输出中的“unable to remove”。升级后，应将退出码 3 视为失败。

无论使用哪个版本，保留策略都应由可信主机执行。在备份主机上，针对本地路径 /srv/restic/app01 执行 forget --keep-last 1 --prune --dry-run 成功，并计划移除一份快照，但这个按数量保留的策略只是冒烟测试。restic 文档提醒，能够向只追加仓库添加垃圾快照的攻击者，可以挤掉 --keep-last 计数范围内的真实快照。因此，实际策略应使用 --keep-within。以 restic 服务用户执行，确保真正清理时写入的数据包和索引文件仍归 rest-server 的运行账户所有。该用户还需要自己的密码文件，以及位于 rest-server 数据路径 /srv/restic 之外的缓存目录。实验在备份主机上创建了这两项，并通过标准输入提供仓库密码：

sudo install -d -o restic -g restic -m 700 /var/cache/restic-maint
sudo install -o restic -g restic -m 600 /dev/stdin /etc/restic-maint.pass

准备完成后，可以以服务用户执行保留策略的试运行：

sudo -u restic RESTIC_PASSWORD_FILE=/etc/restic-maint.pass restic -r /srv/restic/app01 --cache-dir /var/cache/restic-maint forget --keep-within 30d --prune --dry-run

实验中的两份快照都只有几分钟，因此基于时间的策略会保留它们，不计划删除任何数据：

Applying Policy: keep all snapshots within 30d of the newest
keep 2 snapshots:
ID        Time                 Host            Tags        Reasons     Paths         Size
------------------------------------------------------------------------------------------------
0e1d9c6c  2026-10-31 03:09:34  app-eu-west-1a              within 30d  /srv/appdata  297.795 MiB
b69a9d65  2026-10-31 03:09:44  app-eu-west-1a              within 30d  /srv/appdata  302.795 MiB
------------------------------------------------------------------------------------------------
2 snapshots

注意，正如输出所示，restic 的 --keep-within 以最新快照的时间戳为基准，因此真正清理前要检查快照列表中是否有异常时间戳。只追加模式也不阻止写入：失败的清理在 DELETE 被拒绝前，仍重新打包了一个数据包并写入新索引，留下了重复索引条目。

恢复与零错误验证

恢复使用备份主机上的副本。实验将最新快照恢复到临时路径，然后依据攻击前生成的 SHA-256 清单比较每个文件：

restic -r $REMOTE restore latest --target /srv/restore
cd /srv/restore/srv/appdata && sha256sum -c --quiet /root/appdata.sha256; echo mismatches=$?

全部 9,052 个文件在 4.5 秒实际经过时间内恢复，清单核验没有发现不匹配：

restoring snapshot b69a9d65 of [/srv/appdata] at 2026-10-31 03:09:44.912865153 +0000 UTC by root@app-eu-west-1a to /srv/restore
Summary: Restored 12665 files/dirs (302.795 MiB) in 0:03
mismatches=0

上面的恢复测试验证了 3-2-1-1-0 中的“0”。另一半验证是完整读取每个数据包的仓库检查，而非只检查索引。实验中的 restic check --read-data 耗时 2.8 秒；对于数 TB 的仓库，可以用 --read-data-subset 将读取工作分散到多次定时运行中。这次检查先报告了攻击者清理失败留下的 21 条“pack contained in several indexes”警告，随后无错误地结束：

Duplicate packs are non-critical, you can run `restic repair index' to correct this.
check all packs
check snapshots, trees and blobs
[0:00] 100.00%  2 / 2 snapshots
read all data
[0:01] 100.00%  22 / 22 packs
no errors were found

restic 0.18.1 打印的这些警告，本身也有取证价值：在无人进行过清理的仓库中出现重复索引，可能说明某个客户端尝试过清理；不过，可信主机上的清理被中断，也会留下相同痕迹。Linux 不可变备份指南还介绍了该测试的 Object Lock 和 Borg 只追加版本。

比较 3-2-1、3-2-1-1-0 与仅一份不可变副本

三种方案真正的差别体现在攻击者持有管理员凭据时。下表基于前述机制和实验结果，列出每种方案能够应对的故障：

应根据最可能遇到的威胁，以及能够接受的恢复时间来选择：

• 家庭实验室或单台工作站：采用 3-2-1，并将外置磁盘拔下后保存，就已经接近 3-2-1-1-0，因为断开连接的磁盘属于离线副本。Linux 备份外置磁盘说明介绍了这一环节。
• 只有一个机房的小企业：采用 3-2-1-1-0，将不可变副本放在 Object Lock 存储桶中，避免人工轮换介质。
• 受监管数据，如金融和医疗：采用带合规模式保留策略的 3-2-1-1-0。AWS 和 Azure 已由 Cohasset 按 SEC 17a-4 对相关机制进行评估。
• 预算只够增加一份副本：先配置不可变副本，条件允许后再增加快速的本地副本。

如果恢复时间目标短于一天，建议避免“仅一份不可变副本”的设计，因为经广域网取回数 TB 数据往往是恢复停滞的原因。用本地副本保证速度，用不可变副本保证存活，才能同时覆盖这两项需求。

相关工具与能力

下列产品覆盖 3-2-1-1-0 中的一个或多个条件。每项介绍其能力，并非排名；本次实验只运行了 restic 和 rest-server。Borg、restic 与 Kopia 的基准比较另有三款开源工具的测量数据。

• restic 与 rest-server：开源去重备份客户端，本文撰写时发布版本为 v0.19.1；配套 HTTP 服务器的 --append-only 参数“阻止删除和修改现有备份”。
• BorgBackup：通过 SSH 执行去重备份，稳定版本为 1.4.5；borg serve --append-only 让客户端运行清理时，服务器仍保留已经提交的数据。BorgBackup 与 Borgmatic 配置说明介绍了其用法。
• Kopia：开源备份客户端，文中版本为 v0.23.1；可通过 --retention-mode 和 --retention-period 为数据对象设置 S3 Object Lock 保留策略。Kopia 与 Backblaze B2 配置说明介绍了设置过程。
• Proxmox Backup Server：为 Proxmox VE 的虚拟机和容器提供去重备份，文中为 4.2 系列；包含验证任务、受保护快照、磁带支持，以及在 4.2 中结束技术预览阶段的 S3 数据存储后端。
• Veeam Backup & Replication：Veeam Data Platform 的备份引擎，文中产品页面版本为 v13.1；支持不可变仓库和用于自动化恢复验证的 SureBackup。
• Amazon S3 Object Lock：提供 WORM（一次写入、多次读取）存储，包含治理模式和合规模式；合规模式下，到达保留日期前任何用户都不能删除对象。
• Backblaze B2：兼容 S3 的对象存储，提供治理或合规模式的 Object Lock，保留期可设为 1 至 3,000 天。
• Wasabi：兼容 S3 的存储，支持 S3 Object Lock API，不额外收取 API 请求费用，并列明了对 Veeam Backup & Replication 的验证支持。

无论选择哪种产品保存不可变副本，都要为它配置生产环境永远接触不到的凭据。实验表明，只有能删除该副本的凭据始终不落入攻击者手中，副本才能存活。

每季度进行一次恢复演练

3-2-1-1-0 中的“0”需要有人定期验证才能成立。建议每季度针对不可变副本执行以下演练并计时，让下一次事件拥有可信的恢复时间依据：

1. 从不可变副本恢复到无法路由至生产环境的临时虚拟机，假设本地副本已经丢失。
2. 比较哈希或记录行数，依据备份时生成的清单进行核对，方法类似实验中的 sha256sum -c。
3. 运行完整的数据完整性检查，例如 restic check --read-data、PBS 验证任务或 Veeam SureBackup，并阅读每条警告。
4. 使用生产凭据尝试删除，确认删除失败；从未测试过的锁定仍然只是一个假设。
5. 记录实际经过时间，从开始到数据验证完成，并与恢复时间目标比较。

如果第 4 步成功，副本就不是不可变的，无论厂商宣传如何称呼，这个方案仍然只是基础 3-2-1。要为演练提供文件系统一致的数据源，可使用 LVM 快照，让备份工具获得繁忙服务器上冻结的数据视图。

资料与实验环境

• Ruggiero 与 Heckathorn，《Data Backup Options》，US-CERT，2012 年：3-2-1 定义及其与 Krogh 的渊源。
• Veeam，《3-2-1 Backup Rule Explained》：3-2-1-1-0 的定义与 SureBackup。
• Sophos，《The State of Ransomware 2026》：66% 通过备份恢复、48% 付款、赎金中位数 76.9 万美元。
• Sophos，《The State of Ransomware 2025》：54% 通过备份恢复、超额付款者中 38% 的备份失败，以及 2020 至 2023 年图表数据。
• Sophos，《The State of Ransomware 2024》：68% 通过备份恢复、56% 付款。
• Veeam，《2024 Ransomware Trends Report》新闻稿：41% 数据受影响、57% 得到恢复、81% 付款。
• Veeam，《Data Trust and Resilience Report 2026》新闻稿：90% 有恢复信心、28% 完全恢复。
• CISA，《#StopRansomware Guide》：离线加密备份，以及对不可变存储的提醒。
• AWS，《Locking objects with Object Lock》；Backblaze，《Object Lock》；Microsoft，《Azure Blob immutable storage》；Wasabi，《S3 Object Lock》。
• restic rest-server README、restic v0.19.1 发布说明、v0.19.0 发布说明（forget 退出码 3），以及快照移除文档（只追加模式的安全注意事项）；BorgBackup 只追加说明；Kopia 勒索软件防护文档。
• Proxmox Backup Server 文档与路线图；Veeam Backup & Recovery 产品页面。
• 实验环境：2026 年 10 月，两台 Ubuntu 26.04.1 虚拟机，restic 0.18.1（Ubuntu 26.04 软件包）与 rest-server v0.14.0；截图随原始采集记录保存。

赞赏