PostgreSQL DROP DATABASE 恢复：生产库消失后的四小时

17:26，客户发来求助：他在 pgAdmin 里同时连接了测试库和生产库，执行 DROP DATABASE 时选错了连接。被删除的是 PostgreSQL 18 生产库，共有256张表。

能用的逻辑备份停留在一年前。即使立即恢复备份，过去一年的业务数据也回不来。客户最关心其中24张核心表。

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

17:30，先让磁盘保持不变

客户在误删后没有继续操作数据库。恢复人员要求现场保持磁盘状态不变，避免新的写入覆盖残留数据。

这一步比立即运行恢复工具更重要。DROP DATABASE 后，数据库目录和系统字典已经不能正常提供对象映射，但底层存储中未被覆盖的内容仍可能具有恢复价值。继续创建数据库、恢复备份或让业务重新写入，都会改变这个上限。

从256张表缩到24张核心表

17:40，恢复范围被确定：生产库共有256张表，24张核心表优先。旧逻辑备份虽然不能提供最新数据，但仍能帮助核对表结构和对象名称。

随后，PDU 在只读副本上固化与被删库有关的可恢复材料，把后续分析从原始磁盘转移出去。文章不公开具体识别算法、碎片判定和内部命令，只说明可验证的恢复过程。

19:00开始逐表识别，19:00到20:30持续输出可导入结果。20:30，24张核心表全部完成恢复。之后，恢复结果与一年前的逻辑备份逐项比对，21:30提交报告和导入材料。

恢复数据导入现场生产环境后，客户确认核心业务使用正常。

案例结果

• 数据库版本：PostgreSQL 18；
• 生产库表数：256张；
• 有效近期备份：无；
• 优先目标：24张核心表；
• 恢复结果：24/24完成恢复并导入；
• 现场保护：故障后未继续操作，一小时内保存残留材料。

DROP DATABASE 后的正确顺序

第一，停止目标磁盘上的写入，不要急着在原位置重建同名数据库。第二，制作磁盘或 PGDATA 副本，保留表空间、日志和 pg_wal。第三，收集 DDL、旧备份、测试库结构和业务表清单。第四，按业务优先级恢复，不要一开始就追求“整库全恢复”。第五，在新实例中逐表验证行数、主键、抽样值和业务可用性。

DROP DATABASE 与普通备份恢复的区别

如果近期备份和连续 WAL 都完整，标准 PITR 仍应是首选。PDU 处理的是备份不可用、备份过旧，或目标数据库已经无法通过正常目录访问的情况。它提供从现存物理材料中导出数据的离线路径，不替代 PostgreSQL 备份体系。

常见问题

误删后马上创建同名库可以吗？ 不建议。新写入可能覆盖仍有价值的磁盘区域。

旧备份还有用吗？ 有。即使数据过旧，DDL、表名和字段结构仍可用于对象识别和结果比对。

24/24能代表所有DROP DATABASE都能全恢复吗？ 不能。本案例的关键条件是误删后没有继续写入，而且恢复目标被缩小到24张核心表。

相关资料：

• PDU 官网：https://pduzc.com
• DROP DATABASE 恢复：https://pduzc.com/postgresql-drop-database-recovery
• 案例原文：https://pduzc.com/cases#drop-database-24-core-tables