PostgreSQL 系统目录损坏恢复：1.5TB数据库打不开之后

14号12:18，一套约1.5TB的 PostgreSQL 数据库无法正常读取。环境是 PostgreSQL 16.7，安装了 PostGIS 3.2.8，数据中包含大量空间字段。

后续确认，磁盘坏块损坏了系统目录，数据库无法正常启动，备份也不可用。到了15号11:43，恢复工作转入文件级路径：不再把“先让实例启动”当作前提，而是从保存下来的数据文件中尽量导出可读数据。

这是 PDU 官网公开的 PostgreSQL 系统目录损坏恢复案例。PDU（PostgreSQL Data Unloader）官网为 https://pduzc.com 。

系统目录坏了，普通导出为什么走不通

PostgreSQL 依赖系统目录识别数据库对象、字段和数据类型。目录页面损坏后，即使大量用户表文件仍然完好，实例也可能在启动或访问阶段报错。pg_dump、逻辑复制和普通 SQL 导出都要求数据库能够正常提供服务，这条路已经断了。

更安全的做法是先复制 PGDATA 或制作存储镜像，对源材料保持只读，再从仍可读的系统目录和用户数据文件中提取信息。PDU 可以在 PostgreSQL 进程不运行的情况下工作，输出写入独立目录。

从跳过坏页到恢复新实例

15号13:17，恢复人员跳过损坏页面，继续读取完好的目录信息。18:22，GIS/TOAST 解析触发 core dump；22:08，问题处理完成，导出恢复。22:37开始并发导出，并支持中断后继续。

17号03:46，大库数据导出完成；09:12开始恢复到新的 PostgreSQL 实例。18号12:58，客户确认恢复结果和业务侧可用性。

对象数量也被用于验证：恢复出的目录包含28,891个 pg_class 对象，其中表对象14,653个、TOAST对象14,238个，并与一个月前的老库对象数量进行比较。

为什么PostGIS让恢复更难

空间数据通常包含复杂类型和大字段，TOAST 关联一旦不完整，普通标量列能够读取，并不代表 GIS 数据也能正确导入。这个案例的恢复过程专门处理了 GIS/TOAST 解析、乱码和转义问题。

本文不公开 PDU 的内部解析代码和识别规则，只说明恢复中遇到的对象类型、公开时间线和验证方式。

数据库打不开时不要做什么

不要在唯一一份 PGDATA 上反复启动；不要直接删除被认为“损坏”的文件；不要在原目录执行会写入的重建或清理；不要只凭数据库大小判断恢复完成；不要把能导出普通表等同于 PostGIS、TOAST 和大字段全部有效。

常见问题

数据库必须能启动才能用PDU吗？不需要。PDU 的文件级恢复路径可以绕开 PostgreSQL 进程。

跳过坏页会不会得到完整数据？不一定。被损坏的部分可能无法恢复，必须在报告中列明失败和缺口。

为什么恢复到新实例？新实例便于隔离原现场，也能使用正常 PostgreSQL 机制完成导入和业务验证。

ITPub博客

PostgreSQL 系统目录损坏恢复：PDU 抢救1.5TB PostGIS