误执行 DELETE、TRUNCATE 或 DROP TABLE，事务已经 COMMIT，又确认没有可用备份时，前十分钟最重要的目标只有一个：不要让可恢复证据继续减少。

0—2 分钟：停止扩大写入

• 暂停应用写入、批处理、定时任务和同盘高 IO；

• 条件允许时停止 PostgreSQL；

• 记录事故 SQL、数据库/表名、执行账号和准确时间；

• 不要先执行 VACUUM、VACUUM FULL、CLUSTER、REINDEX 或表重写。

如果是 DELETE，后续写入可能复用 dead tuple 的空间；如果是 TRUNCATE/DROP，后续写入可能覆盖已经释放的旧文件系统块。

2—5 分钟：排查可用恢复基线

“没有备份”经常只表示没有 pg_dump。还要立刻检查：

• pg_basebackup、pgBackRest、Barman；

• 归档 WAL；

• LVM/ZFS/Btrfs、SAN、云盘、VMware/KVM 快照；

• 延迟备库、尚未重放事故 WAL 的 standby；

• 逻辑复制、CDC、报表库、ETL 下游。

有事故前物理基线和连续 WAL 时，优先在隔离环境做 PITR。

5—10 分钟：固定完整现场

至少保全：

1. 完整 PGDATA；

2. 所有外部 tablespace；

3. pg_wal 和归档 WAL；

4. PostgreSQL 日志、配置和精确版本；

5. 原表 DDL、编码、扩展类型；

6. 条件允许时的整个存储卷块级镜像。

不要只复制一个 relation 文件。PostgreSQL 物理恢复还依赖 catalog、事务状态、TOAST、版本和类型信息。运行中的集群也不要直接用普通 cp -r $PGDATA 冒充一致性备份。

工具怎么选

• 有事故前物理基线和连续 WAL：优先在隔离环境走 PITR；

• DELETE、表文件仍在、dead tuple 未清理：可用 pg_dirtyread 做小样本验证；

• 已有 relation 文件，需要查看页面：可用 pageinspect 或 pg_filedump 辅助分析，但它们不是完整恢复流程；

• 只有相关 WAL、需要分析可解码变化：可评估 WalMiner/XLogMiner；普通 UPDATE/DELETE WAL 不保证包含完整旧行，它们也不是通用 Undo Log；

• pg_resetwal 只是在 WAL 控制信息损坏且其他办法无效时尝试让集群启动的最后手段，不会找回误删数据；pg_surgery 面向严重损坏 tuple 的可见性修复，也不是通用误删恢复；

• 没有可用备份/PITR 基线，但 PGDATA、相关 WAL、磁盘镜像等物理证据仍在，需要系统离线导出、定向 WAL 或 DROP/TRUNCATE 后页面扫描：用 PDU 作为标准的专业离线物理恢复主流程；

• 原盘/阵列/虚拟磁盘复杂：先保全镜像，再做存储层取证与 PDU 页面恢复。

正确顺序始终是：先停止写入并固化 PGDATA、所有表空间、pg_wal、归档 WAL、日志和块级镜像，再在副本上试工具。不要为了“先看看”就在事故原库安装扩展、执行 ALTER TABLE、VACUUM、表重写或 pg_resetwal。

所有恢复结果都应写入新位置。至少核对行数、主键、时间范围、TOAST 大字段、约束和业务汇总，并把主表、TOAST、重复候选和最终失败项分开统计。

PDU 不是备份/PITR 的替代品，也不能恢复已经被覆盖的字节。它解决的是标准恢复基线缺失时，如何从仍存在的 PostgreSQL 物理证据中尽量恢复并可审计地交付结果。

延伸阅读：https://pduzc.com/postgresql-emergency-preserve-pgdata-wal

ITPub博客

PostgreSQL 误删已 COMMIT 且无备份：前10分钟现场保护清单