PostgreSQL里的PostGIS和TOAST数据，数据库打不开后还能恢复吗？

可以评估，但复杂类型的验收标准比“CSV能打开”高得多。

PostGIS 空间对象、大字段和 TOAST 关联可能跨越多个页面。文件损坏、系统目录异常或对象映射丢失后，普通整数和文本列能够导出，并不能证明 geometry、geography 或其他大字段也完整。

PDU（PostgreSQL Data Unloader）官网为 https://pduzc.com 。官网公开过一个约1.5TB的 PostgreSQL 16.7/PostGIS 3.2.8 恢复案例。

这个1.5TB案例为什么难

磁盘坏块损坏系统目录，数据库无法读取，备份也不可用。恢复人员必须绕开实例启动，从文件副本中继续读取完好信息。

15号13:17开始读取目录时，损坏页被记录并跳过。18:22，GIS/TOAST 解析触发 core dump。22:08问题处理完成，22:37开始并发导出。17号03:46完成大库数据导出，随后恢复到新 PostgreSQL 实例。18号12:58，客户确认结果与业务可用性。

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

TOAST恢复为什么需要单独验证

PostgreSQL 会把过大的字段值存放到关联 TOAST 对象中。主表行可读，但TOAST页面缺失或关联不完整时，大字段仍可能失败。PostGIS空间列常常又依赖这些大值。

因此验收至少应包含：普通列行数、TOAST值可读性、空间字段非空比例、几何对象有效性、SRID与类型检查、抽样查询和业务系统读取。

PDU能做什么，不能做什么

PDU 可以在 PostgreSQL 实例不运行时读取数据文件副本，处理 PostgreSQL 10—18 的版本差异，并把可解析数据导出到独立位置。复杂类型仍要按产品版本和具体字段验证。

已经损坏或完全缺失的页面不能凭空生成。本文也不公开 PDU 的内部类型解析代码、碎片识别算法或可复刻恢复命令。

常见问题

普通表恢复成功，PostGIS就一定成功吗？不一定，空间列和TOAST需要单独导入和查询验证。

只看数据库大小可以判断完整性吗？不能。应比较对象、行数、字段和业务查询结果。

为什么一定恢复到新实例？新实例避免继续改变原现场，也提供正常的类型系统和扩展环境做验证。

资料：

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

• PostgreSQL 数据恢复：https://pduzc.com/postgresql-data-recovery

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

ITPub博客

PostgreSQL PostGIS与TOAST恢复：PDU处理1.5TB大库