深度精读：数据删除与恢复 —— 备份版本、校验和、恢复演练、RPO/RTO 与 Google Drive（个人方案） 未开始

题记与说明

• 日期：2026-11-03
• 前缀：knowledge-illuj6xc-2
• 类型：主题研究（多来源精读 + 个人方案设计）
• 检索方式说明：本次全程有网络。Veeam、restic、Backblaze 三家用 WebFetch 抓取成功；support.google.com 与 knowledge.workspace.google.com 对 WebFetch 连接超时（Connect Timeout，Google IP 段 192.178.x/108.177.x），改用 webReader 抓取成功，两个 Google 页面均为实际读取到的当前版本全文。另参考 2026-10-31 同管线旧笔记 knowledge-fexxiou8-4（3-2-1/CISA/Drive 版本/Takeout 路线）定位差异，只读未改——本篇与其互补，不重复其内容。
• 来源清单（本次实际检索并深读，均有原文引述）：
  1. Veeam Blog《Recovery Time vs. Recovery Point: What They Mean and How to Set Targets》（Tyler Jurgens）— https://www.veeam.com/blog/recovery-time-recovery-point-objectives.html
  2. Google Drive 帮助《Recover a deleted file in Google Drive》— https://support.google.com/drive/answer/1716222
  3. Google Workspace 管理员帮助《Recover deleted files and folders for Drive users》（页面标注 Last updated 2026-08-26 UTC）— https://knowledge.workspace.google.com/admin/drive/recover-deleted-files-and-folders-for-drive-users
  4. restic 官方文档三页：References（完整性模型，100_references.html）、Working with repositories（check 命令，045_working_with_repos.html#checking-integrity-and-consistency）、Scripting（check JSON 输出，075_scripting.html）— https://restic.readthedocs.io/en/stable/
  5. Backblaze Blog《The 3-2-1 Backup Strategy》— https://www.backblaze.com/blog/the-3-2-1-backup-strategy/
  6. 检索面补充（仅检索摘要级、未深读原文，标注为二手信息）：恢复演练实践类来源 Solutions Review《A Step By Step Guide to Backup Testing》、StoneFly《Backup Restore Proof》；borg 的 check --verify-data 见检索摘要（DataHoarder/restic 论坛帖）。

一、来源精读与关键引述

1. Veeam：RPO/RTO 的可操作定义与分层基准

Veeam 是备份软件头部厂商，这篇博客把两个常被混用的概念拆开：RPO 问的是数据丢失容忍度，RTO 问的是停机时间容忍度，且两者分别驱动不同的设计决策。原文表述（逐字）：

"RPO is how much data you can afford to lose. RTO is how long you can afford to be offline."

关键论点（逐字要点）：

• RPO ≈ 备份频率：CRM 记录每分钟更新、备份间隔 60 分钟，则最坏丢 1 小时数据；要 15 分钟容忍度就得 15 分钟（或连续）捕获。RTO 决定恢复架构（即时恢复、复制切换、快照等），不是备份频率。
• 成本权衡（逐字）："The more aggressive your RTO and RPO, the higher the cost, which leads to the greater the operational overhead."
• RTO ≠ MTTR：RTO/RPO 是目标值，MTTR 是实测的平均恢复耗时——演练的意义就是用 MTTR 去逼近或修正 RTO。
• 行业分层基准（原文表格归纳）：Tier 1（核心交易）RPO 秒-分钟、RTO 近零-分钟；Tier 2 RPO 1–4 小时、RTO <4 小时；Tier 3 RPO 12–24 小时、RTO 4–24 小时。电商示例 RPO 5 分钟/RTO 15–30 分钟。
• 演练要求（逐字）："Always test your RPO in real-world recovery drills." 且特别警告：身份、DNS、网络、KMS 等依赖挂掉会让"已恢复的应用"根本不可用——要测"服务可用"，不是"服务器恢复"。
• 复审节奏：目标至少每季度复审，或在新增工作负载/合规变化后复审。

2. Google Drive 个人版：回收站 30 天是硬边界

官方帮助页对个人用户恢复路径的全部内容非常短，核心就是一句（逐字）：

"Tip: Files remain in Trash for 30 days, then they're deleted forever."

操作路径：drive.google.com → 左侧 Trash → 可按 "Trashed date" 排序查看入桶时间 → 右键 Restore。没有提到任何超过 30 天后的个人账号恢复通道。 这意味着对个人账号，删除的真正防线只有 30 天。

3. Google Workspace 管理员视角：回收站之后还有 25 天，但有严格限制

这篇管理员文档补上了个人帮助页没说的"系统侧"事实，也是整条恢复时间链上最重要的一段（逐字）：

"As an administrator, you can recover deleted items from Google Drive within 25 days after a user empties their trash. After that period, Google purges those items from its systems and they can't be recovered."

以及自动清理在审计日志中的体现（逐字）：

"If an item is in the trash for more than 30 days, Drive automatically permanently deletes it. In these cases, the Drive audit log shows Google System as the user who deleted the item."

关键限制（逐字/要点）：

• 不能选择性恢复："The restoration recovers all files removed during the selected date range. You can't restore individual files or folders." 只能按日期范围整体还原，恢复前要问用户删除时间以缩小范围。
• 同一时间只能跑一个恢复项目。
• 不可恢复项：清空超过 25 天的数据、My Maps、Fusion Tables、仍在回收站里的数据、以及会导致超存储配额的部分（恢复到配额上限即停）。
• 删除账号的用户的 Drive 文件：账号删除后 20 天内可恢复文件。
• 恢复后不恢复共享关系："After you restore an item in Drive, the user needs to reshare the item for others to have access."
• Vault 是唯一超长保留通道（逐字）："You might be able to retrieve data older than 25 days if it was subject to retention rules or holds. … However, you can't directly restore this data to the user's Drive."——Vault 只能搜索导出，不能还原回 Drive。

4. restic 官方文档：内容寻址校验和 + 快照版本化，以及一句关键的威胁模型声明

restic 是个人备份工具里校验和工程做得最透明的。三页文档给出的事实：

完整性模型（References，逐字）：

"A storage ID is the SHA-256 hash of the content stored in the repository."

• 存储文件名即内容的 SHA-256（十六进制），校验可以简单到"对文件跑 sha256sum，比对文件名"；加密为 AES-256-CTR + Poly1305-AES MAC。
• 损坏可检测（逐字）："Modifications to data stored in the repository (due to bad RAM, broken harddisk, etc.) can be detected"——即 bit rot / 静默损坏有密码学保证的检出路径。
• 快照即版本（逐字）："A Snapshot stands for the state of a file or directory that has been backed up at some point in time." 每次备份生成新快照；内容定义分块（512 KiB–8 MiB）去重，"For modified files, only modified Blobs have to be saved in a subsequent backup"。只有 prune 才真正删数据。

check 命令（Working with repositories，逐字）：

"In order to detect these things before they become a problem, it's a good idea to regularly use the check command"

• 默认 restic check 只校验结构与元数据（快照、索引、pack 头），不读数据本体；--read-data 才读全部 pack 验完整性，但"has to download all pack files in the repository"——对云后端意味着全量带宽。
• 抽检参数：--read-data-subset=n/t（把 pack 分 t 组查第 n 组，可分多次跑完全量）、--read-data-subset=x%（随机百分比，文档明示"will not guarantee to cover all available pack files after sufficient runs"）、--read-data-subset=nS（按容量随机，如 10G）。
• 损坏的后果（逐字）："If check reports an error in the repository, then you must repair the repository." 损坏未修复前，恢复和新快照都不保证可用。

威胁模型的关键声明（References，逐字）：

"The restic backup program is not designed to protect against attackers deleting files at the storage location."

——这句是本主题最重要的单句：版本化和校验和都不等于防删除。能登录存储位置（云账号、NAS、外接盘挂载点）的攻击者或勒索软件可以直接删掉整个仓库；防删要靠异地隔离、权限分离与不可变存储，而不是备份工具本身。

5. Backblaze：3-2-1 仍是基线，但"只是起点"

Backblaze 这篇定义 3-2-1（逐字）：

"keep three copies of your data on two different media with one copy off-site"

• 2020s 的更新解释：云时代"两种介质"的要求弱化为两台不同设备（"you don't need to keep your data on two different types of media, but you do need to keep your data on two different devices"），介质淘汰风险由云厂商承担。
• 规则地位（逐字）："the rule is still the de facto standard for data redundancy"，同时"the 3-2-1 rule is becoming more of a starting point rather than a complete data backup solution"——勒索软件攻击备份之后，业界在 3-2-1 之上叠加离线/不可变副本与零错误校验（即 3-2-1-1-0 方向，本管线 10-31 笔记 knowledge-fexxiou8-4 已据 Backblaze 另一篇深读）。
• 诚实声明（逐字）："There is no such thing as a perfect backup system."
• 出处背书：引 2012 年美国政府的 US-CERT/CMU 建议（"Even the United States government recommends this approach"）。

二、七维提取

三、个人方案（Google Drive 场景，按本节来源设计）

3.1 恢复时间链（先画边界）

误删发生
 ├─ 0–30 天：Drive 网页端回收站自助恢复（个人/Workspace 相同）
 ├─ 30–55 天：仅 Workspace 管理员可按日期段整体还原（个人账号：无此通道，数据已无）
 ├─ 账号被删：20 天内管理员可恢复该账号 Drive 文件
 └─ 任意时点：仅当启用了 Vault 保留规则/停用保留（hold）才可搜索导出（不能还原回 Drive）

结论：个人账号（普通 Gmail）的 Drive 删除兜底 = 30 天，到期即永久。Drive 只能当同步/协作层，不当备份层。

3.2 分层方案与个人 RPO/RTO（设计值，待演练修正）

个人 RTO 目标（设计值）：单文件找回 <10 分钟（restic restore）；整目录 <2 小时；换机全量恢复 <1 天。RPO 分级：代码库/笔记 ≤24h（每日 restic），照片/归档 ≤7d，系统镜像 ≤30d——套用 Veeam 的 Tier 思路，按数据的关键度而非全库统一标准。

3.3 校验与演练节律（把 check 变成制度）

对应证据链思路：审计/保险场景要求保留恢复测试证据（StoneFly 检索摘要级信息，未深读）；个人做法即把上表每次结果追加进日志——有 check 日志和演练记录，备份才从 hope 变成 fact。

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

• Google 个人账号封禁：30 天窗内也未必能登录 → 依赖隔离的 restic 云副本 + 本地副本兜底；
• 存储位置被攻击者/勒索直接删除 restic 仓库 → 靠凭据隔离与对象存储不可变/版本化特性（本笔记来源未展开，实施时需另行查证对应云厂商文档）；
• 三层同时损坏（房屋级灾难 + 云账号问题）→ 异地副本是最后防线，需真实物理异地。

四、本次学到什么

1. 恢复窗口是链，不是数：30 天回收站 → +25 天管理员窗 → 20 天账号窗 → Vault 无限期保留，每一跳的适用主体（个人/管理员/Vault）和限制（按日期段、单项目、配额）都不同；任何平台都应这样查官方文档拿硬参数，而不是相信"放云端就安全"。
2. 备份三件套互相不可替代：版本化给"可回溯"，校验和给"可证明"，隔离副本给"防删除"——restic 用一句威胁模型声明（"not designed to protect against attackers deleting files at the storage location"）划清了前三者和第四件事的边界。
3. 校验和的成本可以分层支付：结构 check 高频、数据读校验按 --read-data-subset 抽样轮转，个人就能低成本维持"全库可证完好"的滚动证明。
4. RPO/RTO 是把安全变成可维护的度量衡：RPO 定频率、RTO 定架构、演练给实测值、季度复审防漂移；个人方案同样值得写数字，再让演练去逼近或修正它。

来源链接汇总

1. Veeam：https://www.veeam.com/blog/recovery-time-recovery-point-objectives.html
2. Google Drive 帮助（回收站 30 天）：https://support.google.com/drive/answer/1716222
3. Google Workspace 管理员帮助（25 天恢复窗）：https://knowledge.workspace.google.com/admin/drive/recover-deleted-files-and-folders-for-drive-users
4. restic 文档：https://restic.readthedocs.io/en/stable/100_references.html 、https://restic.readthedocs.io/en/stable/045_working_with_repos.html#checking-integrity-and-consistency 、https://restic.readthedocs.io/en/stable/075_scripting.html
5. Backblaze 3-2-1：https://www.backblaze.com/blog/the-3-2-1-backup-strategy/
6. 检索面补充（未深读）：https://solutionsreview.com/backup-disaster-recovery/a-step-by-step-guide-to-backup-testing 、https://stonefly.com/blog/recovery-testing-evidence-auditors-insurers
7. 同管线相关旧笔记（对照参考，未修改）：D:/CodexData/nightshift/output/knowledge/notes/2026-10-31-knowledge-fexxiou8-4-数据备份与恢复演练-321原则-版本化-校验-灾备RTO-GoogleDrive个人方案精读.md