35.6 工程取证与业务验证
数据库抢救有两个交付对象：一个是可以承担服务的新状态，另一个是解释“原状态发生了 什么、哪些数据仍不确定”的证据链。只交付一个能启动的 cluster，会把未知损失留给 业务和下一次事故。
35.6.1 保留原始证据、操作副本和完整时间线
证据树
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 时间线
每条事件：
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。这样复盘才能区分“当时可见事实”与 “事后才知道的事实”。
工具可复现性
保存：
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 区分“数据库能启动”与“业务数据可信”
五层验收
| 层 | 问题 | 示例证据 |
|---|---|---|
| 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：
replication
archive and backup
monitoring and alerting
service route and roles
capacity headroom
observation window业务不变量要有定义版本
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，可分层：
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 记录不可恢复范围与合规沟通
用区间与集合表达 unknown
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 与业务损失分开
WAL/RPO gap
recovery point 与事故点之间可能缺的数据库事务
physical extraction gap
某些 page/object 无法读取
semantic gap
数据存在但业务意义错误
external-effect gap
数据库与支付、消息、邮件、对象存储不同步一个 RPO 数字不能覆盖四类损失。
合规与沟通
由法律、安全、隐私和业务 owner 判断是否触发通知。技术团队提供可审计事实：
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对客户不要说“数据库坏了但已经修好”这种不可证实概括。应说明已确认影响、仍在验证 范围、临时控制和下一次更新时间；不公布攻击/隐私细节前先走授权。
结案条件
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 章将把这份证据包转化为长期控制。
上一节：抽取、跳过与重建策略 · 返回本章目录 · 下一节：实战：在克隆环境分类并恢复 · 查看全书目录 · 查看索引中心