半夜两点，手机突然狂震，群里炸了锅——生产环境的PG库被人一条DELETE没带WHERE条件，几百万行订单数据瞬间蒸发。这种场景，干过DBA或者运维的朋友估计都能脑补出那种心跳骤停的感觉。我见过太多人这时候第一反应是去翻备份，结果发现备份策略稀烂，或者备份文件根本起不来，只能干瞪眼。别慌，PG这玩意儿虽然偶尔让人头大，但在数据恢复这件事上，它其实留了不少后门和保命手段。今天咱们就把误删数据这事儿掰开揉碎了讲，从最基础的备份恢复到进阶的WAL日志挖掘，给你捋出一条能落地的完整流程。
先说最理想的情况：你有定期全量备份，而且开启了WAL归档。这时候恢复流程其实挺机械的，但每一步都有坑。你得赶紧把数据库停掉，或者至少把数据目录只读挂载，防止新的写入覆盖掉那些还没被清理的老数据页。然后，找一台干净的机器或者目录，把最近一次的全量备份解压出来，修改conf里的restorecommand，指向你归档WAL存放的位置。接着，创建一个recovery.signal文件（PG 12以上版本），里面写上restorecommand的配置，或者直接在conf里写好。启动数据库，PG会自动重放从备份点到一个完整WAL段的所有日志，把你的数据恢复到崩溃前的那一刻。这个过程看着简单，但有个细节容易被忽略：你得确认归档WAL是连续的，中间缺一段，恢复就会卡住，数据库起不来，报错信息还不明不白。
但现实往往比理想骨感。很多团队压根没开归档，或者归档目录早就被清理脚本干掉了。这时候全量备份只能恢复到备份时刻，之后的那部分数据就丢了。如果你运气好，误删操作发生在备份之后不久，而且你开启了足够的wallevel（至少是replica级别），那么还有一条路可以走——利用pgwal目录下还残存的WAL段文件。这些文件默认会保留几个，具体数量取决于walkeepsize和checkpoint的触发频率。你可以用pgwaldump工具去解析这些WAL段，找到那条误删事务的LSN位置，然后用pgresetwal或者更精细的工具，把数据库状态回退到那个LSN之前。但这招操作难度极高，而且PG官方明确不支持这种手动重置WAL的方式，搞不好会把整个数据目录弄到不可用状态，只适合在万不得已、且没有其他任何选择的时候去赌一把。
如果你连WAL段都没剩下，那就得考虑另一层方案了——从文件系统层面找线索。Linux下，被删除的文件其实还有机会通过lsof或者debugfs找回来，前提是磁盘块还没被覆盖。你的PG数据表文件，在操作系统层面就是一个大文件，DELETE操作只是标记了元组为死元组，并没有真正把物理文件删掉。所以，如果你能停止数据库服务，立刻对数据目录所在的磁盘做只读镜像，然后用extundelete或者xfsundelete这类工具去扫描，是有可能把整个数据文件捞回来的。捞回来之后，再挂载到另一台机器上，用PG的standby模式去启动，它会自动进入恢复流程，把崩溃状态下未提交的事务回滚掉。这个方法不依赖任何PG内部机制，纯粹是跟操作系统抢时间，但效果往往出奇的好，尤其是你的数据文件本身并不大、磁盘写入也不频繁的时候。
还有一种更精细的场景：你只是误删了某几张表，而不是整个库。这时候，如果你之前用pgdump做过逻辑备份，那直接恢复那张表就行。但如果你没有单独备份那张表，而全量备份又是几天前的，那中间这些天的数据怎么办？PG有一个不太为人知的函数，叫pgcurrentwallsn()，它可以告诉你当前写入位置。如果你能定位到误删操作之前的一个安全LSN，配合pgdump的--reuse-previous-output选项，或者直接用pgrewind这个工具，把实例回退到那个点。pgrewind本来是用来快速同步主备节点的，但它也能在failover场景下把旧主库回退到新主库的时间线。对于误删数据，你可以临时搭建一个新实例，把旧实例的数据目录作为备库去追，追到误删点之前，然后提升为新主库。这招比手动改WAL安全得多，而且社区里有很多成功案例。
万一以上所有手段都失败了，你还有一张底牌——第三方恢复工具。比如pgrecovery，这个开源项目专门针对误删数据设计，它能扫描表文件里的死元组，把那些已经被标记删除但还没被VACUUM物理清理掉的数据重新捞出来。原理很简单，PG的堆表里，每个元组都有个xmax字段，标记删除事务ID，只要这个ID对应的事务还没提交，或者提交后还没触发清理，那这些数据就还物理存在。pgrecovery就是利用这个机制，绕过正常的MVCC可见性判断，直接把这些死元组导出成INSERT语句。这个工具对表结构有要求，需要你提供表定义，而且它只能恢复数据，不能恢复索引和约束，但总比数据全丢强太多了。我见过一个例子，有人靠这工具把误删的三个小时数据全找回来了，一条都没少。
咱们得聊聊预防。恢复流程再熟练，也不如压根不出事。PG从13版本开始，有个叫pgidentifyobjectasaddress的函数，配合事件触发器，可以实现在执行DELETE前自动把受影响的行数记下来，超过阈值就直接报错。这种保护性编程比任何恢复手段都靠谱。另外，建议每个库都开启autovacuum但别开得太激进，因为VACUUM会物理清理死元组，一旦清理了，pgrecovery这类工具就彻底没戏了。还有，定期做恢复演练，别等到真出事才发现备份是坏的。我接触过的团队里，凡是经历过一次完整恢复流程的人，之后对备份和WAL归档的态度都会变得极其认真，因为那种差点丢数据的恐惧感，比任何规章制度都管用。
总结一下，PG误删数据的恢复路径，优先级大概是：有归档WAL就做PITR时间点恢复，没归档就看文件系统能不能捞，文件系统没戏就试试pgrecovery挖死元组，实在不行只能认栽。整个过程最核心的一点是：第一时间停库、只读挂载、别乱动数据目录。你每多写一个字节进去，恢复的成功率就降低一分。平时多花点时间把备份策略和恢复流程跑通，关键时刻能救命。别等事情发生了才后悔，数据库这行，稳字当头，但真出了事，也别慌，按流程一步步来，大部分数据其实都能救回来。
