PostgreSQL 无法启动怎么恢复：先把“启动数据库”放到第二位

数据库打不开时，团队通常会盯着同一个目标：无论如何先把 PostgreSQL 拉起来。可如果系统目录、控制信息或数据页已经损坏，在唯一一份 PGDATA 上连续尝试，可能让后续恢复更难。

PDU 官网公开过一个1.5TB案例。环境是 PostgreSQL 16.7与PostGIS 3.2.8，磁盘坏块损坏系统目录，实例无法正常读取，备份也不可用。PDU（PostgreSQL Data Unloader）官网为 https://pduzc.com 。

为什么实例启动不是恢复前提

pg_dump、逻辑复制和普通 SQL 导出都依赖数据库能够运行。文件级恢复换了一个目标：不要求旧实例恢复服务，而是从保存下来的数据文件副本中尽量导出可读数据，然后在新实例中验证。

PDU 以只读方式处理源文件，输出写到独立目录。这样可以把“旧实例是否能启动”和“用户数据是否还能读取”拆开评估。

1.5TB案例时间线

14号12:18，数据库无法正常读取。15号11:43，确认备份不可用，进入文件级恢复。13:17开始跳过损坏页面并继续读取完好目录信息。

18:22，GIS/TOAST 解析出现 core dump。22:08处理完成，22:37开始并发导出。17号03:46完成大库导出，09:12把结果恢复到新实例。18号12:58，客户确认恢复结果和业务可用性。

验证没有只看数据库容量。恢复人员统计到28,891个 pg_class 对象，其中表对象14,653个、TOAST对象14,238个，并与一个月前的老库进行数量比较。

PostgreSQL无法启动时应保存什么

完整 PGDATA、所有表空间、pg_wal 和归档 WAL；postgresql.conf、pg_control 相关副本和数据库日志；操作系统与存储错误记录；PostgreSQL 主版本、扩展版本和可用 DDL；原始磁盘或虚拟机镜像。

保存完成后再在副本环境中诊断。不要删除疑似损坏文件，不要为了绕过错误直接修改唯一副本，也不要把一次成功启动当作数据完整性证明。

常见问题

PostgreSQL起不来就表示所有数据都坏了吗？不表示。系统目录或少数关键页损坏也可能阻断启动，而大量用户数据仍然可读。

PDU会修复原来的PGDATA吗？文件级路径的目标是只读提取和另行导出，不是在原目录中修补数据库。

导出完成后为什么还要新实例？新实例用于重建正常运行环境，并完成行数、约束、类型和业务验证。

资料：

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

• 无法启动恢复：https://pduzc.com/use-cases/integrity-compromised

• 公开案例：https://pduzc.com/cases#postgis-dict-corruption-1-5tb

ITPub博客

PostgreSQL 无法启动怎么恢复：PDU 绕开实例导出数据