PG DELETE 数据恢复实战：没有归档 WAL，还能找回多少？

周末下午约两点，一张原有约38万行数据的 PostgreSQL 17 生产表突然只剩数千行。超过95%的数据已经被 DELETE，事务也提交了。更麻烦的是，现场没有开启 WAL 归档。

客户发现行数异常后没有继续跑业务，而是立即停止 PostgreSQL 服务。接近下午四点，恢复分析开始。现存 pg_wal 还没有被后续活动大量回收，这个动作保住了事故处理中最有价值的材料。

这是 PDU（PostgreSQL Data Unloader）官网公开的 PG DELETE 数据恢复案例。PDU 官网为 https://pduzc.com 。

为什么 DELETE 提交后仍可能恢复

对应用和普通 SQL 来说，已经提交的 DELETE 不存在“撤销”按钮。但 PostgreSQL 的物理文件和 WAL 可能仍保留与误操作有关的信息。

恢复前先看两条路径：

1. 基础备份和连续 WAL 归档完整时，优先使用标准 PITR。

2. 只需恢复部分记录，或备份链无法覆盖事故时间时，评估现存 WAL 能否支持定向提取。

这个案例没有归档 WAL，PITR 走不通。恢复人员检查误操作时间点前后的 pg_wal，最终找到约35万条仍可使用的 DELETE 记录。PDU 根据这些记录重建删除前的数据，再把结果整理成可导入文件。

三小时恢复了什么

• 原表规模：约38万行；

• 误删比例：95%以上；

• 现场条件：PostgreSQL 17，未开启 WAL 归档；

• 找到的有效记录：约35万条；

• 结果：完成恢复、导入和数据可用性验证；

• 用时：从开始分析到完成恢复约三小时。

这里不能把“约35万条恢复”写成“100%恢复”。原本受影响的数据约38万行，最终能找回多少，由现存 WAL、数据页状态和事故后的写入共同决定。

这个案例真正值得复用的是停库动作

大量 DELETE 会让 autovacuum、WAL 回收和后续业务写入不断改变现场。数据库每继续运行一段时间，可恢复材料都可能减少。

发现 PostgreSQL 误删后，应立即做四件事：停止应用写入；保存 pg_wal 和归档 WAL；复制 PGDATA 或制作只读快照；记录误操作时间、事务、库名、模式名和表名。恢复试验放到副本中，不要在唯一一份生产目录上反复操作。

PDU 在 DELETE 恢复中的位置

PDU 支持 PostgreSQL 10—18，可以离线分析保存下来的 WAL，在明确时间和对象范围后导出误删前的数据。它不替代备份，也不能恢复已经不存在的 WAL。

本文不公开 PDU 的内部解析实现，只给出事故判断、公开案例结果和操作边界。

常见问题

没有开启 WAL 归档就一定没救吗？不是。本案例使用的是仍保留在 pg_wal 中的有效记录，但窗口通常更短。

数据库还在提供服务，要不要先导出当前数据？先判断写入是否会继续破坏恢复材料。大规模误删事故通常应优先冻结现场，再从副本处理。

PDU 能保证全部找回吗？不能。恢复量取决于 WAL 是否保留、数据页是否被清理以及事故后的写入。

案例与技术资料：

• PDU 官网：https://pduzc.com

• DELETE 恢复说明：https://pduzc.com/use-cases/data-deleted

• 公开案例：https://pduzc.com/cases#delete-350k-wal-shutdown-recovery

ITPub博客

PG DELETE 数据恢复实战：PDU 三小时找回约35万行