读书笔记 · 约 15,907 字 · 预计推送 2 部分

深度精读：数据备份与恢复演练 —— 3-2-1 原则、版本化、校验、灾备与恢复时间目标（结合 Google Drive 设计个人方案） 未开始

目录

题记与说明

检索方式说明：本次全程有网络。CISA PDF 与 Backblaze、rclone 通过网页抓取器读取全文；support.google.com 抓取器超时后改用内置浏览器（ZCode In-app Browser）逐页打开读取 DOM 快照，四篇 Google 官方帮助页均为实际读取到的当前版本页面内容。

一、来源精读与关键引述

1. CISA《Data Backup Options》——3-2-1 原则的正典出处

这是美国政府网络安全机构（原 US-CERT，CMU 卡内基梅隆生产）对个人和小机构备份的官方建议，也是"3-2-1"一词最常被引用的出处。论文脚注标明该规则源自摄影师Peter Krogh 2009 年的《The DAM Book: Digital Asset Management for Photographers》第 207 页——3-2-1 的血统是数字资产管理实践，后来才被安全界收编。

原文对规则的表述（逐字）：

"3 – Keep 3 copies of any important file: 1 primary and 2 backups.
2 – Keep the files on 2 different media types to protect against different types of hazards.
1 – Store 1 copy offsite (e.g., outside your home or business facility)."

这份文档最有价值的是它对每种介质逐项列出 Pros/Cons/Security，其中两段警告在今天依然精准：

"Rolling backups can silently propagate any corruption or malware in the primary files to the backup files. Worse, if your internal hard drive is damaged, stolen, or corrupted, you could lose both your primary and backup files."

（滚动备份会把主文件中的损坏和恶意软件"静默地"传染给备份——这解释了为什么版本化/快照是必要补充，而不是只有"最新一份备份"。）

对家庭用户的落点建议：

"Home users storing a relatively small amount of personal data should consider keeping primary files on the hard drive of their computer, with at least two backup copies on solid-state storage, optical storage (stored in jewel cases), or remote storage."

文中云存储部分的 Cons 提醒至今适用："you may become locked into one provider… users surrender most of their control over their own data"（供应商锁定、对数据的控制权让渡）——这正是个人方案必须保留一份独立于云的本地/离线副本的官方论据。

2. Backblaze——3-2-1 为何不够：3-2-1-1-0 与 4-3-2

Backblaze（云备份厂商，Backblaze B2 对象存储运营方）2021 年这篇是英文世界对"3-2-1 过时论"传播最广的阐述。开篇引海豹突击队的格言：

"Navy SEALs go by the rule that 'Two is one and one is none.' …but in the world of computer backup, even two is none."

核心论点：云备份让"off-site"变容易，却丢掉了磁带时代的 air gap（气隙）：

"While a 3-2-1 strategy with off-site copies stored in the cloud works well for events like a natural disaster or accidental deletion, it lost the air gap protection that tape provided. Cloud backups are sometimes connected to production networks and thus vulnerable to a digital attack."

驱动升级的威胁是勒索软件开始专打备份：

"Ransomware operators like Sodinokibi… are now going after backups in addition to production data."
"Cloud backups are sometimes tied to a company's active directory, and they're often not virtually isolated from a company's production network. If a hacker has Active Directory admin credentials all backups secured with that Active Directory are vulnerable."

并引用 Gartner 预测："at least 75% of IT organizations will face one or more attacks by 2025."

3-2-1-1-0 的完整定义（逐字）：

"- Maintain at least three copies of business data.
- Store data on at least two different types of storage media.
- Keep one copy of the backups in an off-site location.
- Keep one copy of the media offline or air gapped.
- Ensure all recoverability solutions have zero errors."

关键的"0"是可恢复性零错误，且明确要求演练：

"The 3-2-1-1-0 strategy goes a step further to require that backups are stored with zero errors. This includes data monitoring on a daily basis, correcting for any errors as soon as they're identified, and regularly performing restore tests."

离线/防篡改的现代化实现是对象存储的 Object Lock：

"Object Lock is a powerful backup protection tool that prevents a file from being altered or deleted until a given date. …no one can change them, including the file owner or whoever set the Object Lock and—most importantly—any hacker that happens upon the credentials of that person."

文末还有一个对个人方案极重要的清醒剂（大厂也会挂）：

"Hard drives fail. Good employees make bad mistakes. …whether it was the Amazon Web Services outage that took down a large swath of the internet or the Google Cloud Storage outage that affected platforms like Snapchat, Shopify, and Discord, even the biggest providers can let you down in your time of need."

3. Rubrik——RTO / RPO 的严格定义与成本权衡

Rubrik（企业灾备厂商）这篇 glossary 文章给出两个指标的标准定义：

"RTO is the goal your organization sets for the maximum length of time it should take to restore normal operations following an outage or data loss."
"RPO is your goal for the maximum amount of data the organization can tolerate losing. This parameter is measured in time: from the moment a failure occurs to your last valid data backup. For example, if you experience a failure now and your last full data backup was 24 hours ago, the RPO is 24 hours."

要点：RPO 决定备份频率（丢多少数据可容忍），RTO 决定恢复架构（多久能恢复可用），两者都按应用重要性分层：

"The more mission-critical the application, the lower (closer to zero) the RTO and RPO should be. …you can divide your systems into tiers based on levels of criticality and institute appropriate recovery objectives for each tier."

以及核心成本定律：

"The more stringent the RTO and RPO, the more expensive achieving them can be."

（个人版翻译：你愿意花多少钱买"丢失更少、恢复更快"。RPO 靠增加备份频率，RTO 靠准备"即插即用"的恢复路径——镜像、缓存副本、演练熟练度。）

4. Google Drive 官方文档——回收站、版本化、Takeout 的真实行为

这部分是我做个人方案的事实底座，四篇均为当前在线页面（浏览器实测读取）。

（a）回收站只有 30 天（https://support.google.com/drive/answer/14933051 ，逐字）：

"将文件或文件夹移至回收站后，它们会在回收站中保留 30 天。
• 30 天后，您的文件将被永久删除。
• 如果您手动清空回收站，则里面的文件会被立即永久删除。
• 回收站中的内容会占用 Google 云端硬盘中的存储空间，直到它们被永久删除。"

含义：回收站是"撤销缓冲区"，不是备份，更不是版本历史。误删后你的窗口固定为 30 天。

（b）Drive 二进制文件的版本机制（https://support.google.com/drive/answer/2409045 ，逐字）：

"保存并恢复近期版本：除非点击「永久保留」，否则您只能保存旧文档的最新版本。"
"Google 文档、表格和幻灯片的版本记录不同于云端硬盘中存储的 .pdf 文件、图片和其他文件的历史记录。"

即：非 Google 格式文件（pdf/jpg/zip…）默认只保留最新一版；可以通过"管理版本 → 永久保留/上传新版本/删除先前版本"手动管理。这直接否定"我把文件放 Drive 就等于有版本备份"的常见误解。

（c）Google Docs 原生版本历史（https://support.google.com/docs/answer/190843）：

（d）Google 导出/Takeout——账号级"逃生舱"（https://support.google.com/accounts/answer/3024190 ，逐字）：

"您可导出和下载与您所用 Google 产品相关的数据，例如：电子邮件、文档、日历、照片…若要留存记录或将数据用于另一服务，您可创建归档文件。"
"重要提示：下载您的 Google 数据并不会导致这些数据从 Google 服务器上删除。"
"该文件可能不包含从您请求下载到系统创建归档文件期间发生的数据更改。"
"此过程可能需要几分钟到几天不等，具体时间取决于您帐号中的信息量。"

交付方式与参数（页面实测）：电子邮件发送下载链接 / 添加到云端硬盘 / Dropbox / OneDrive / Box；导出类型：一次性或定期导出；文件类型 ZIP 或 Tgz；归档大小上限可调，超过则拆分成多个压缩包。

5. rclone Google Drive 后端文档——校验与自动化的事实细节

rclone 是个人方案里"可脚本化、可校验"的关键工具，其 drive.md（2026-09-03 更新）给出了 Drive 生态里最硬的技术事实：

校验和（这是"校验"环节的核心依据）（逐字）：

"Hash algorithms MD5, SHA1 and SHA256 are supported. Note, however, that a small fraction of files uploaded may not have SHA1 or SHA256 hashes especially if they were uploaded before 2018."
（Limitations 一节重复强调）"All files have MD5 hashes, but a small fraction of files uploaded may not have SHA1 or SHA256 hashes especially if they were uploaded before 2018."

含义：Drive 在 API 层给每个普通文件提供 MD5（全量）、SHA1/SHA256（部分文件缺失），rclone check、rclone md5sum、rclone hashsum 可直接做源-目的哈希比对——个人方案可以做到企业级的"备份后校验"，不必花钱买工具。

Drive 服务端修订策略（逐字）：

"Google drive stores revisions of files. When you upload a change to an existing file to google drive using rclone it will create a new revision of that file. Revisions follow the standard google policy which at time of writing was
- They are deleted after 30 days or 100 revisions (whatever comes first).
- They do not count towards a user storage quota."

注意这补充了官方帮助页没细说的硬参数：服务端修订保留"30 天或 100 个版本"（先到为准），且不占配额；--drive-keep-revision-forever 可保头部修订永久。再次确认：Drive 自带版本化是"浅版本化"，30 天窗口，不能当长期历史。

其他行为细节（逐字摘取）：

二、七维提取

1. 核心问题（problem）

数据丢失的风险来源（硬件故障、误删、勒索软件、云账号被锁/被黑、大厂宕机）彼此不同，单一备份对其中几种必然失效。核心问题是：个人用户如何用一套便宜、可自动化、可验证的体系，覆盖所有常见丢失场景，并且——在真正需要时——能在承诺时间内把数据恢复回来？ 特别地，当个人以 Google Drive 为主要在线存储时，Drive 的真实行为（30 天回收站、浅版本化、账号级单点）决定了哪些风险它兜得住、哪些必须由体系外的副本兜底。

2. 主要主张（claim）

  1. 3-2-1 是底线而非终点：3 份副本、2 种介质、1 份离站（CISA 官方表述，源自 Peter Krogh 2009）。
  2. 云时代的正确姿势是 3-2-1-1-0：加一份离线/气隙或不可变副本，做到"零恢复错误"；因为勒索软件已把备份列为首要打击目标，云备份连着生产网络不算隔离（Backblaze）。
  3. RPO 决定备份频率，RTO 决定恢复架构，都要分层；指标越严格越贵，个人方案应按数据关键性分层定义这两个数（Rubrik）。
  4. "放了云端 ≠ 有了备份"：Google Drive 回收站固定 30 天后永久删除；非 Google 格式文件默认只留最新版本；Docs 版本历史可能合并修订。Drive 的版本能力是浅的、窗口是短的。
  5. 校验必须可执行且可复核：Drive API 层提供全量 MD5（SHA1/SHA256 部分缺失），rclone 可直接做源-目的哈希校验和 manifest 固化（rclone 官方文档）。
  6. 恢复演练不是可选项：3-2-1-1-0 的"0"内含"regularly performing restore tests"（Backblaze）；未经演练的备份等价于未知状态的备份。

3. 方法（method）

4. 数据与证据（evidence）

断言证据（出处均为本次实读原文）
3-2-1 的官方定义CISA PDF 逐字三条规则；脚注指向 Krogh《The DAM Book》p.207（2009）
滚动备份会传染损坏/恶意软件CISA："Rolling backups can silently propagate any corruption or malware…"
勒索软件瞄准备份、云备份不隔离Backblaze：Sodinokibi 攻击案例、AD 凭据一锅端论证；Gartner 预测 75% IT 组织 2025 前遭遇攻击
3-2-1-1-0 五条定义Backblaze 逐字列表，含 "Ensure all recoverability solutions have zero errors"
Object Lock 防篡改语义Backblaze："prevents a file from being altered or deleted until a given date… including the file owner"
RTO/RPO 定义与成本定律Rubrik：两处逐字定义 + "The more stringent the RTO and RPO, the more expensive…"
Drive 回收站 30 天Google 帮助 answer/14933051 逐字四条（含"清空立即永久删除""占用配额"）
Drive 非 Google 文件仅存最新版本Google 帮助 answer/2409045："除非点击「永久保留」，否则您只能保存旧文档的最新版本"
Docs 版本历史可能合并修订Google 帮助 docs/answer/190843："系统可能偶尔会合并文件的修订版本"
Takeout 是快照式导出、可能缺近期更改、耗时数天Google 账号帮助 answer/3024190 两处逐字 + 交付选项（邮件链接/Drive/Dropbox/OneDrive/Box，ZIP/TGZ，一次性/定期）
Drive 校验能力rclone drive.md："Hash algorithms MD5, SHA1 and SHA256 are supported…" + "All files have MD5 hashes"
Drive 修订硬参数rclone drive.md："deleted after 30 days or 100 revisions (whatever comes first)"
rclone 实操坑drive.md：默认进回收站、Docs size -1、约 2 文件/秒限速、重复文件需 dedupe、共享 client_id 2026 年停用

证据充分性评估：规则类断言（3-2-1/3-2-1-1-0/RTO/RPO）来自官方与行业权威，相互一致；Drive 行为类断言全部落在当前官方页面与 rclone 官方文档，交叉印证（如 30 天回收站同时出现在 Google 帮助与 rclone 的 trash 描述中）。缺一层的是定量实测：本方案未经我在本机跑通演练（下文局限中明示）。

5. 结论与效果（conclusion）

规则本身收敛成一句话：任何"只有一份、只有一种介质、只有在线、从未恢复过"的方案，都只是删除延迟器。有效方案 = 3-2-1 打底（多副本/异介质/离站）+ 一份离线或不可变（防勒索与误操作）+ 哈希校验闭环（证明备份可读）+ 分层 RPO/RTO（把期望变成数字）+ 定期恢复演练（把纸面承诺变成肌肉记忆）。

对 Google Drive 的结论：Drive 可以胜任"第二副本 + 版本缓冲 + 多设备同步"，但由于 30 天回收站、浅版本化、账号单点三重限制，它必须 paired 一份不依赖 Google 账号的离线副本，否则 3-2-1 的"1"（离站）名义上满足了，抗账号级灾难的能力实际为零。

6. 局限（limits）

7. 对我的启发（relevance）

  1. 立即修正一个认知错误：我此前默认"文件在 Drive 里 = 有版本"。事实是回收站 30 天、非 Google 文件只留一版——凡我认为重要的文件，必须主动"管理版本/永久保留"或靠外部版本化，不能指望 Drive。
  2. 把 RPO/RTO 从企业概念降维成两张个人数字：与其追求"万无一失"，不如给自己写死——"关键文档最多丢 24 小时（RPO=24h），单文件恢复 5 分钟内（RTO=5min）"，然后反推备份频率和恢复路径是否真的支撑这两个数。Rubrik 的成本定律提醒：数字每收紧一档，成本上一台阶，够用即停。
  3. "0 错误"是个人方案最容易被省略也最便宜的一环：Drive 白送全量 MD5，rclone check 一条命令就能把"备份是否真的可读"变成可执行事实；每次备份后校验 + manifest 存档，成本几乎为零。
  4. 演练要排期而不是"有空再做"：Backblaze 把 "regularly performing restore tests" 写进规则定义。把"每季度随机抽 5 个文件恢复 + 每年一次整机恢复"写进日历，演练记录本身就是数据资产的一部分。
  5. 对供应商锁定的制度化防御：CISA 的云锁定警告 + Backblaze 的大厂宕机案例 + Google 单点风险，共同指向一条个人铁律——至少一份副本不登录任何 Google 服务也能读（外接盘 + 标准 zip/文档格式 + 本地 sha256 清单）。

三、结合 Google Drive 的个人 3-2-1(-1-0) 方案（基于以上来源设计）

以下为本次研究的设计产出，标注 [来源依据] 的均有上文引述支撑；未经实机验证的部分已用"待验证"标出。

3.1 数据分层与 RPO/RTO 目标（Rubrik 分层法的个人版）

层级内容RPORTO理由
L1 关键工作文档代码仓库、写作稿、笔记库、证件扫描≤ 24h（实时同步 + 每日快照）单文件 ≤ 5min；全量 ≤ 4h改动频繁、不可再生
L2 媒体库照片、视频≤ 7 天单文件 ≤ 10min；全量 ≤ 1 天体量大、改动少
L3 可再生物系统环境、下载缓存、软件安装包丢失可接受重建 ≤ 1 天有官方渠道可重下

3.2 副本矩阵（3-2-1-1-0 对号入座）

数字承载介质类型位置依据
3 副本一本地工作盘PC 内置 SSD本机CISA：主副本
3 副本二Google Drive（rclone sync 上推）云端 HDD 型介质（与 SSD 异介质 ✓）离站 ✓CISA"2 种介质+离站"；Backblaze"云作 off-site"
3 副本三外接 USB 硬盘月度归档（restic/robocopy 快照式）外置 HDD（第三种介质）平时断电断连=离线 ✓，必要时异地存放Backblaze 3-2-1-1-0 的第 2 个"1"（offline/air-gapped）
0 错误每次同步后 rclone check + 年度 manifest 固化——Backblaze "Ensure all recoverability solutions have zero errors"

3.3 版本化策略

3.4 校验闭环（具体命令）

# 1) 上传后校验源与 Drive 的一致性（Drive 全量 MD5 支持）
rclone check D:\work gdrive:backup-work --one-way --combined check.log

# 2) 固化本地 manifest（年度/每次大归档）
rclone md5sum D:\work > manifests\work-2026Q4.md5

# 3) 外接盘恢复抽样校验
sha256sum -c manifests\work-2026Q4.sha256 --quiet && echo OK

注意事项（全部来自 rclone drive.md 实读）：2018 年前上传的部分文件可能缺 SHA1/SHA256，校验一律以 MD5 为主；Drive 限速约 2 文件/秒，海量小文件分批跑；出现重复文件用 rclone dedupe；共享 client_id 将于 2026 年停用，必须自建 OAuth client_id。

3.5 恢复演练日历（把 3-2-1-1-0 的"0"变成日程）

频率动作验收标准
每周rclone sync + check 自动跑check.log 零 mismatch
每月外接盘增量归档快照目录时间戳更新
每季度随机抽 5 个文件，分别从 Drive 与外接盘恢复到临时目录并比对哈希5/5 哈希一致；记录耗时=实测 RTO
每年整机恢复演练（恢复到备用目录/虚拟机）+ Takeout 全量导出存离线全量可打开；更新本方案
待验证声明：以上命令与耗时目标为设计值，首次季度演练后应以实测数据修正 RTO/RPO 表。

3.6 本方案明确不覆盖的风险

四、本次学到什么

  1. 备份规则是威胁模型的速记：3-2-1 每个数字各防一类灾难，3-2-1-1-0 补的是"云连接时代备份自身会被打"这一新威胁；规则演进史就是威胁模型变迁史。
  2. SaaS 的"内置备份"要按最坏参数理解：查官方文档拿到硬数字（30 天回收站、30 天/100 版本修订、只留最新版本），而不是相信"放云端就安全"的直觉。
  3. 校验和是备份体系的"证明义务"：Drive 白送 MD5 意味着个人可以零成本闭环"备份可读"的证明——有 manifest、有 check 日志，备份才从" hope "变成" fact"。
  4. RTO/RPO 让方案可测试：不可测的"安全"不可维护；写出数字，然后用演练实测去逼近或修正它。
← 资料库今日播报 →