# 工程取证与业务验证 LLMS 索引： [llms.txt](/llms.txt) --- 数据库抢救有两个交付对象：一个是可以承担服务的新状态，另一个是解释“原状态发生了 什么、哪些数据仍不确定”的证据链。只交付一个能启动的 cluster，会把未知损失留给 业务和下一次事故。 ## 35.6.1 保留原始证据、操作副本和完整时间线 {#item-35-6-1} ### 证据树 ```text incident/ manifest.json original/ storage-snapshot-id pgdata/tablespace/wal hashes logs/kernel/hardware projections sources/ backup-id + restore validation replica-id + lineage validation experiments/ E001-input-hash/ hypothesis commands/tool-versions output-projection conclusion E002-input-hash/ recovery/ selected-source transformations validation communication/ decisions impact-estimates ``` 敏感原件放在受控 evidence store，协作仓库只放去敏 projection。不要因为教材/工单需要 “可见”就把 raw PGDATA、query、凭据或客户记录提交 Git。 ### append-only 时间线 每条事件： ```yaml at_utc: ... monotonic_or_sequence: ... actor_or_automation: ... target_identity: ... action_or_observation: ... input_evidence: ... output_hash: ... authority_ticket: ... interpretation_at_the_time: ... later_correction: ... ``` 后来的认识不要覆盖当时记录；追加 correction。这样复盘才能区分“当时可见事实”与 “事后才知道的事实”。 ### 工具可复现性 保存： ```text exact PostgreSQL binary/package version tool options and locale/timezone extension version and schema script source hash exit code stdout/stderr raw location and redacted projection input filesystem/snapshot identity ``` 同名 `pg_checksums`、`amcheck` 或 ICU 在不同版本上可能有不同列、规则和输出。 ## 35.6.2 区分“数据库能启动”与“业务数据可信” {#item-35-6-2} ### 五层验收 | 层 | 问题 | 示例证据 | |---|---|---| | L1 process | postmaster 是否稳定运行 | service/PID/log/crash loop | | L2 SQL | catalog/事务是否可用 | connect、read/write probe、control | | L3 physical | page/structure 是否一致 | checksum、amcheck、heap check | | L4 relational | schema constraints/rows 是否一致 | validate constraints、counts/digests | | L5 business | 业务事实是否可信 | ledger、token、upstream reconciliation | 恢复完成还要加 L6 operational： ```text replication archive and backup monitoring and alerting service route and roles capacity headroom observation window ``` ### 业务不变量要有定义版本 ```yaml invariant: account_ledger_balanced definition_version: git-sha snapshot_or_cutoff: "..." query_or_program_hash: "..." scope: tenants: ... partitions: ... expected: debit_minus_credit: 0 actual: ... exceptions: [...] owner_signoff: ... ``` 只有 row count 不够。相同行数可以包含错误值、重复/缺失互相抵消、错误 tenant 或错误 时间窗。本章实验同时比较 row count、sum ID、sum balance 和有序内容 digest，但真实 业务还要使用有意义的 ledger/token。 ### 抽样与全量 全量验证可能超过 RTO，可分层： ```text release gate: critical tenants/ledger + physical checks + current write probe observation window: wider partitions, indexes, backups, reconciliations post-incident: full historical scan where feasible ``` 必须明确哪些是全量、哪些是抽样、抽样方法与遗漏风险。不能把“抽查 100 行正确”写成 “数据已完整恢复”。 ## 35.6.3 记录不可恢复范围与合规沟通 {#item-35-6-3} ### 用区间与集合表达 unknown ```yaml confirmed_recovered: id_ranges: [...] row_count: ... confirmed_missing: business_ids: [...] reason: ... possibly_affected: time_window: ... tenants: ... relation_blocks: ... unknown: - rows formerly present on unreadable page - external side effects without idempotency ledger estimation_method: source: ... confidence: ... ``` 不要把 unknown 填成 0。若坏页内容不可读，精确行数可能无法知道；可以报告下界/上界 和估计方法。 ### 技术 RPO 与业务损失分开 ```text WAL/RPO gap recovery point 与事故点之间可能缺的数据库事务 physical extraction gap 某些 page/object 无法读取 semantic gap 数据存在但业务意义错误 external-effect gap 数据库与支付、消息、邮件、对象存储不同步 ``` 一个 RPO 数字不能覆盖四类损失。 ### 合规与沟通 由法律、安全、隐私和业务 owner 判断是否触发通知。技术团队提供可审计事实： ```text what systems/data classes were in scope confidentiality vs integrity vs availability impact earliest/latest affected time confirmed/possible/unknown records detection and containment time recovery source and validation evidence retention and access next update time ``` 对客户不要说“数据库坏了但已经修好”这种不可证实概括。应说明已确认影响、仍在验证 范围、临时控制和下一次更新时间；不公布攻击/隐私细节前先走授权。 ### 结案条件 ```text service and business invariants accepted unknown/loss register signed by owners original evidence retained per policy temporary credentials/routes/clones removed backup/replication/monitoring re-established hardware/root-cause track assigned postmortem and control actions scheduled ``` 第 36 章将把这份证据包转化为长期控制。 --- [上一节：抽取、跳过与重建策略](../05/) · [返回本章目录](../) · [下一节：实战：在克隆环境分类并恢复](../07/) · [查看全书目录](/toc/) · [查看索引中心](/indexes/)