张晨：不可能的任务：我们如何在48小时内恢复1TB数据
内容提要
PDU工具成功从严重损坏的PostgreSQL数据库中恢复1TB数据。面对磁盘损坏、备份失效的困境，PDU跳过损坏页，修复了PostGIS和JSONB解析bug，实现断点续传。最终在48小时内完成恢复，对象数量与备份验证一致，无缺失表，展现了生产环境下的可靠性能。
延伸解读
生产环境与开发环境的差距
文章作者在开发PDU时，曾以为适配了PostGIS 3.5.2就能应对所有情况，但实际生产环境中的PostGIS 3.2.8却暴露了未预料的解析问题。这提醒我们，版本差异和真实数据复杂性远超测试环境，工具在正式使用前需经过更广泛的兼容性验证。
断点续传的关键作用
面对频繁的解析错误，PDU通过实现断点续传，确保从失败的表继续而非从头开始，大幅节省了时间。这一设计在长耗时恢复任务中至关重要，能有效应对不可预见的错误，提升恢复效率。
验证恢复完整性的方法
文章通过对比恢复数据库与一个月前备份的对象数量（表、TOAST对象），确认无缺失表。这种基于对象计数的验证方法，为数据恢复提供了客观依据，尤其当备份不最新时，仍能有效评估恢复的完整性。
Q&A
PDU工具在恢复1TB数据时遇到了哪些主要挑战？
主要挑战包括：磁盘损坏导致数据字典损坏、数据库无法启动、备份失效；PostGIS和JSONB解析bug导致频繁崩溃；以及需要处理复杂的数据类型和边缘情况。
PDU是如何处理损坏的数据字典的？
PDU会智能跳过损坏的页面，并继续提取剩余完整的数据字典信息，而不是在遇到损坏时放弃。
PDU在解析PostGIS数据时遇到了什么bug？如何修复的？
PDU在解析PostGIS数据时，由于在detoast_attr函数中注释掉了VARATT_IS_EXTERNAL_ONDISK逻辑，导致没有从TOAST表获取实际数据，而是错误地解析TOAST指针。修复方法是恢复TOAST解析代码路径，同时修复了JSONB列存在的相同问题。
PDU如何实现断点续传？
PDU通过实现检查点恢复机制，在提取过程中遇到错误时，可以从失败的表格继续，而不是从头开始。
如何验证PDU恢复的数据没有缺失表？
通过对比恢复的数据库与一个月前的备份数据库的对象数量。备份数据库有28,711个对象（14,551个表，14,160个TOAST对象），而恢复的数据库有28,891个对象（14,653个表，14,238个TOAST对象），数量匹配且更多，说明没有缺失表。
PDU在恢复过程中遇到了哪些导入问题？
在导入过程中遇到了一些编码问题和转义序列错误，但都及时处理了。
这次恢复经历给作者带来了什么反思？
作者认识到开发环境与生产环境的差距，生产环境非常残酷，但这次实战经历增强了信心，比任何测试都更能证明PDU的可靠性。
