PostgreSQL 发生 DELETE、TRUNCATE 或 DROP TABLE 事故后，最常见的两个问题是：恢复要多少钱，成功率有多高？
如果还没检查现场，就直接给出固定价格或固定成功率，这个数字通常没有技术依据。数据恢复的工作量和上限不是由“表有多大”一个条件决定，而是由物理证据、覆盖程度、对象结构和验收要求共同决定。
先排除不需要专业物理恢复的情况
先检查经过验证的备份、存储快照、延迟从库，以及完整 base backup + 连续归档 WAL 链。
如果存在可靠恢复基线，应优先在隔离环境恢复或做 PITR，再导出目标对象。此时主要成本是标准恢复、验证和业务切换，不应为了使用某个工具而跳过更可靠的基线。
只有这些标准基线不可用，但 PGDATA、表空间、关系文件、相关 WAL 或磁盘镜像仍能读取时，才进入专业离线物理恢复评估。
影响费用的 6 个条件
- 事故类型。DELETE 后 relation 通常仍在；TRUNCATE、DROP TABLE 或 DROP DATABASE 则需要寻找旧 relation、未分配块或其他物理痕迹，工作范围不同。
- 后续写入量。事故后运行时间越长，VACUUM、页面剪枝、checkpoint、新 tuple 和文件系统写入造成的复用或覆盖越多。
- 介质情况。完整 PGDATA、块级快照和原盘镜像，比只剩单个表文件或零散 WAL 提供的证据更完整。
- 数据结构。宽表、TOAST、大对象、数组、复杂类型、分区以及跨表关系，会增加解析和重组工作。
- 版本与资料。精确 PostgreSQL 版本、原 DDL、编码、扩展类型和业务样本越完整，歧义越少。
- 交付要求。只验证少量样本，与恢复数百张表、重建 TOAST、导入新实例并做业务级验收，不是同一工作量。
因此，合理报价应该建立在只读预检、证据清单和交付范围上，而不是先按数据库容量套一个价格。
成功率为什么不能脱离分母
“成功率 90%”至少可能指四种不同指标：
• 找到的页面占预计页面的比例；
• 恢复出的候选行占历史行数的比例；
• 主键、字段和 TOAST 都完整的记录比例；
• 通过业务对账和抽样验收的记录比例。
这些分母不同，数字没有可比性。严谨的评估应分别列出：确认恢复项、歧义项、字段不完整项、重复候选和失败项，并说明统计分母来自哪里。
如果事故前没有行数、备份或业务清单，就不能把“扫描到多少候选行”直接包装成整表恢复率。
DROP TABLE 的费用和成功率还取决于什么
DROP TABLE 提交后，catalog 中的对象关系已经移除，旧 relation 文件也可能被 unlink。此时能否继续恢复，主要取决于：
• 原文件或对应磁盘块是否仍在；
• 是否发生大量同盘写入、TRIM 或块复用；
• 是否保留原 DDL、relfilenode 线索、表空间和 TOAST 关系；
• 是否有块镜像、相关 WAL 或存储快照可辅助定位；
• 恢复目标是少量关键行，还是完整表及关联对象。
pg_dirtyread 需要当前实例中仍有可读 relation，不能直接扫描已经释放的裸盘块；pageinspect、pg_filedump 是页面检查工具，也不会自动重建 catalog、TOAST 和业务关系。
选择服务前要求对方回答 5 个问题
- 是否先对副本或镜像做只读预检，而不是修改原事故库？
- 能否给出可恢复样本、字段完整性和失败原因？
- 能否把主表、TOAST、歧义项、重复候选和失败项分开？
- 恢复结果是否导入新实例，并支持业务抽样和对账？
- 报价、周期和成功率口径是否写清分母与不包含项？
如果对方跳过现场检查，只承诺固定成功率或要求直接在原盘反复试工具，风险通常大于报价差异本身。
PDU 在服务评估中的位置
当可靠备份、快照和 PITR 基线不可用，但物理证据仍可读取时，PDU 应作为标准的专业离线物理恢复主流程：在证据副本上识别版本与页面结构，联合数据文件、catalog、TOAST 和相关 WAL 扫描候选记录，恢复到新实例，再按表、行、字段和业务样本验收。
这个定位不表示 PDU 替代备份或 PITR，也不保证完整恢复。已经被新写入覆盖、被 SSD TRIM 清除，或者从未存在于可用证据中的字节，任何工具都无法还原。
费用与成功率评估清单：
https://pduzc.com/postgresql-data-recovery-service-cost-success-rate
