半夜两点，手机屏幕亮起来，那头的声音透着慌乱：“哥，我把生产库的表给删了，就剩个备份，还是昨天的。”这个电话我接过不下十次，每次听到“误删”两个字，心里都咯噔一下。但说句实在话，PG数据库的恢复手段比你想的多得多，只要没做物理删库，大部分情况都能救回来。今天就把我这些年踩过的坑、用过的招，掰开揉碎了讲给你听。
先别急着敲命令，第一步是冷静判断你删的是什么。很多人一慌就乱操作，结果把本来能恢复的数据彻底搞没了。PG里常见的误删分三种：删了表数据（DML）、删了表结构（DDL）、以及物理删了数据文件。如果是前两种，恭喜你，基本有救；如果是第三种，那就得看你的备份策略和运气了。判断方法很简单，先查一下当前事务状态，用看看数据还在不在可见性范围里。要是能看到xmin，说明数据还没被VACUUM物理清除，这时候赶紧停掉所有写操作，别让autovacuum把机会给“扫”没了。
最常用也最管用的恢复方式，是PG的PITR（时间点恢复）。前提是你开了WAL归档，并且有基础备份。这个方案听起来高大上，其实原理特别朴素：把数据库恢复到误删之前的某个时间点。具体操作分三步走。第一步，找到误删的时间点，越精确越好，比如“下午3点12分33秒”。第二步，用基础备份恢复一个临时实例，把恢复参数（PG12以上是）配置好，指定目标时间。第三步，启动实例，等到它自动追平WAL日志后，把需要的数据导出来，再灌回原库。这个过程最怕的就是时间点找不准，差个几秒都可能漏数据。所以平时养成习惯，操作前看一眼，这个动作关键时刻能救命。
要是你没开归档，也别急着哭。只要VACUUM还没跑，数据就还在数据文件里躺着，只是“看不见”了。这时候可以用pgfiledump或者pgrecovery工具直接扫数据文件。pgfiledump能读出数据页里的原始内容，哪怕索引和元数据都被改了，只要数据块还在，就能把记录抠出来。我去年帮一个客户恢复过一张被TRUNCATE掉的表，就是用这个方法，从数据文件里硬生生捞出了九成数据。不过这个方法有点门槛，你得知道数据文件放哪，表对应的是多少。查一下，然后用工具去解析那个文件。操作的时候切记只读打开，千万别在原文件上做任何修改。
再讲一个很多人不知道的冷门技巧：利用延迟复制的备库。如果你架构里有流复制备库，而且配置了，那备库本身就带着“后悔药”功能。假设你设置了延迟1小时，主库在3点误删了数据，备库在4点前还能看到3点之前的所有数据。这时候直接从备库把数据捞出来，比什么恢复方案都快。要是没配延迟，也有办法，临时把备库的指到误删前的时间点，让它追到那个位置停下来，然后导出数据。这个方案的美妙之处在于，它不影响主库的在线服务，可以慢慢操作。
还有个场景很常见：删了表结构，比如DROP TABLE。这时候WAL日志里记录了完整的DDL操作，如果你有归档，同样可以用PITR恢复。但要注意，DROP TABLE之后，如果表数据量不大，你甚至可以直接用解析WAL日志，找到CREATE TABLE的记录，然后手动重建表结构。这个方法适合表结构简单的情况，复杂表就当练手了。我见过一个狠人，用自己写的脚本从WAL里提取出了整张表的INSERT语句，硬是拼出了一份完整数据，虽然耗时半天，但总比数据丢了强。
说到这儿，必须提一下预防的重要性。恢复手段再牛，也架不住反复踩坑。我给自己定了几条铁律：第一，生产环境永远开或，并配置归档；第二，每天至少做一次基础备份，保留最近7天的归档日志；第三，高危操作前，先做一次单表备份，就一条命令的事，花不了几秒钟；第四，给autovacuum设置合理阈值，别让它太勤快地把旧数据清掉。这几条做到位了，误删之后基本都能从容应对。
说点掏心窝子的话。数据库恢复这件事，拼的不是技术多高深，而是你有多冷静、准备有多充分。我见过太多人在恢复过程中因为着急，把本来能救的数据彻底弄没了。所以真遇到误删，先深呼吸，关掉所有自动任务，把情况摸清楚，再动手。记住，数据文件只要还在磁盘上，就还有。这篇文字能让你在深夜接到那个电话时，心里不那么慌，那我写这些就值了。下次再有人半夜找你，你可以淡定地说：“别急，有办法。”
