前两天有个朋友半夜给我打电话，说他公司那套PostgreSQL数据库突然挂了，数据全没了，他急得差点把键盘摔了。我一边安抚他，一边远程连进去看情况。这哥们儿用的是PG 14，跑的是电商平台的核心订单库，平时运维全靠一个人，备份策略也就一周一次全量备份，增量日志都没开。结果硬盘故障导致数据文件损坏，恢复起来那叫一个头大。这事让我想起一个老生常谈的问题——数据库恢复不是等出事了再学，而是得提前把功课做足。
PG数据库的恢复，说白了就是跟时间赛跑。它的核心机制是WAL日志，也就是预写式日志。每次数据修改都会先写进WAL，再刷新到数据文件。这个设计的好处是，就算数据库突然崩溃，WAL还能帮你把没来得及写进数据文件的操作重放一遍。但问题在于，很多人只开了WAL归档，却没配置好归档策略。我见过一家公司，WAL日志直接写满了一整块硬盘，归档脚本又写得稀烂，导致归档目录里堆了上百GB的日志文件，恢复时根本不知道从哪儿下手。所以，理解WAL的工作原理是第一步，但更关键的是，你得知道怎么用它来快速定位恢复点。
真正让人头疼的恢复场景，往往不是数据库直接崩了，而是人为误操作。比如有人跑了个DELETE语句忘了加WHERE条件，或者不小心DROP了关键表。这时候，PG的恢复手段就分成了两种：基于时间点的恢复（PITR）和基于日志的恢复。PITR能让你把数据库恢复到某个具体的时间点，比如误操作发生前的一秒钟。但前提是你得有完整的WAL归档和基础备份。我处理过一个案例，运维手滑删了一个月的数据，但备份只保留了两周，结果只能恢复两周前的数据，中间那两周的损失全靠人工补录。所以，备份策略得跟业务风险匹配，不能一刀切。
说到备份，很多人觉得pgdump就够了。pgdump确实好用，能导出单个数据库或表，逻辑备份也方便迁移。但它有个致命缺陷：速度慢，而且不支持增量备份。对于几百GB的数据库，一次pgdump可能跑几个小时，这段时间里数据还在变，恢复时就会遇到一致性问题。更靠谱的做法是结合pgbasebackup做物理备份，它能生成数据库的完整快照，配合WAL归档，恢复速度比逻辑备份快一个数量级。我推荐的做法是：每天凌晨跑一次pgbasebackup，同时开启WAL归档，归档目录放在独立的存储上，这样就算主库挂了，归档日志还能用。
恢复过程中最常踩的坑是“归档日志断裂”。WAL归档是顺序写入的，如果中间丢了一个日志文件，恢复就会卡住。我见过有运维为了省空间，手动删了归档目录里“看起来没用”的旧日志，结果恢复时正好缺了那一段。PG的恢复机制很死板，缺了日志就直接报错停掉，不会自动跳过。解决办法有两个：一是开启归档日志的校验功能，定期检查完整性；二是用pgwaldump工具分析日志序列，提前发现断裂点。如果真遇到日志缺失，可以尝试用pgresetwal强制跳过，但这会丢失部分数据，属于最后的手段。
还有一种情况是数据库文件本身损坏，比如硬盘坏道或者文件系统错误。这时候即使有备份，也得先修复损坏的文件。PG的块校验功能能帮你定位到具体损坏的数据块，然后从备份中只恢复那些块，而不是整个数据库。我处理过一个案例，一个表空间里的几个文件出了坏道，导致查询报错。我们用pgchecksums检查了所有数据块，发现只有三个块损坏，然后用pgrewind从备用节点把这三个块拉回来，整个过程不到十分钟。所以，定期做块校验，保持备用节点同步，是应对物理损坏的关键。
对于生产环境，我强烈建议部署流复制。主库写数据，从库实时同步，主库挂了直接切换。但流复制不是万能的，它只能保护硬件故障，挡不住误操作。比如有人在主库上删了表，从库也会同步删除。这时候就需要延迟复制，让从库落后主库一段时间，比如一小时。这样主库出事后，从库还有一小时的数据没同步，可以拿来恢复。我见过一个团队，延迟复制设了15分钟，结果那次误操作后，他们从延迟从库里捞出了完整的订单数据，避免了灾难。
说个大家容易忽略的点：恢复演练。很多公司的备份策略写得天花乱坠，但从来没真正恢复过。等到出事了，才发现备份文件是坏的，或者归档路径写错了。我建议每季度做一次恢复演练，选一个测试环境，模拟数据损坏、误删除、硬件故障等场景，从备份中完整恢复一次。记录下恢复耗时、出错环节，然后优化流程。有一次演练，我们发现pgbasebackup生成的备份因为磁盘空间不足被截断了，但脚本没报错，幸亏演练及时发现了。备份不是存了就完事，得确保它能用。
