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 章将把这份证据包转化为长期控制。

上一节：抽取、跳过与重建策略 · 返回本章目录 · 下一节：实战：在克隆环境分类并恢复 · 查看全书目录 · 查看索引中心