数据库崩了，这事儿在PG圈子里不算新鲜。我见过不少运维朋友，平时好好的，一遇到崩溃就手心冒汗，脑子里全是“完蛋了”“数据没了”的念头。其实PG的设计比你想的皮实得多，它自带的那套WAL日志机制，就是为了让你在灾难面前有路可退。但问题在于，很多人压根不知道退路在哪儿，或者知道有这条路，却不知道怎么走。今天这篇东西，不跟你讲虚的，就说崩溃之后，你该怎么一步步把数据捞回来。
先说最基础的一步：别慌，先看进程和日志。崩溃之后，第一件事不是去敲恢复命令，而是先确认PG到底是怎么死的。打开数据目录下的文件，看几十行，通常会有明确的报错信息，比如“invalid page header”“could not read block”或者“database system was interrupted”。这些关键词能直接告诉你崩溃的根源是磁盘坏块、内存问题还是突然断电。同时用看看有没有残留进程，如果有，直接干掉，别留后患。这一步看似简单，但很多人跳过去直接恢复，结果白折腾半天。
接下来，进入正题：启动PG，让它自己走崩溃恢复流程。PG在崩溃后，数据目录里会有一个文件，这是残留的锁文件，正常启动会报错。这时候别删它，先尝试正常启动一次，命令就是。如果运气好，PG会检测到未完成的WAL日志，自动回放，进入恢复模式。这个过程可能持续几秒到几分钟，取决于你崩溃前有多少事务没刷盘。等它启动起来，数据库就自动进入可查询状态了。但注意，这时候数据可能不是“最新”的，因为有些事务在崩溃时还没提交，PG会回滚掉它们，这是正常的，别慌。
如果正常启动失败，比如报“database system is in recovery mode”卡住不动，或者直接报“invalid page checksum”，那就得手动介入了。这时候最常用的工具是，它相当于给PG做一次“强制重置”。但用这个命令要极其小心，它会把WAL日志里的位置信息强行改到一个安全点，可能导致部分已提交但未写入数据文件的事务丢失。所以用之前，一定要备份整个数据目录，至少把（旧版本叫）目录拷出来。然后执行，再尝试启动。这个方法能解决大部分“卡在恢复中”的问题，但代价是可能丢一部分最近的数据。
还有一种常见场景：某个数据文件损坏，导致整个库起不来。这时候别用硬刚，那会把所有数据都置于风险中。正确做法是单用户模式修复。先编辑，把调小，然后以单用户模式启动：。进去之后，你可以直接执行SQL，把损坏的表删掉或者重建。比如报错说某个表的索引坏了，你可以在单用户模式里再重建。这个模式很原始，没有网络监听，没有并发控制，就是给你救火用的。修完退出，再正常启动。
另一个经常被忽略的恢复手段是时间点恢复（PITR）。如果你之前配置了，并且持续把WAL归档到备份目录，那崩溃后的恢复就从容多了。你需要一份基础备份（比如做的全量备份），再加上归档的WAL文件，然后用（PG12以后改成文件）指定恢复目标时间点。这样你能把数据库恢复到崩溃前一秒，几乎不丢数据。但前提是你提前做了配置，临时抱佛脚是来不及的。所以每次你骂数据库不稳定的时候，先问问自己归档开了没有。
说到备份，不得不提和。这俩是逻辑备份工具，不依赖WAL，适合小规模数据或者单表恢复。崩溃后，如果物理文件损坏严重，但你有最近一次的备份，那就能把数据捞回来。恢复方式很简单，建一个全新的PG实例，然后。但注意，逻辑备份有个先天缺陷：它只备份数据，不备份索引、约束、触发器这些元数据，需要你重建。而且备份到崩溃之间的数据会丢，所以这只能算“保底方案”，不能当救命稻草。
说一个很多人不知道的冷技巧：利用直接读数据文件。如果PG彻底起不来了，也救不了，但数据文件本身还是完好的，你可以用这个第三方工具，直接解析数据文件里的二进制内容，把表数据提取出来。这个工具能输出SQL格式的INSERT语句，虽然慢，但能抢救一部分核心数据。用法是，它会打印出每个块的内容。这个方法适合极端情况，比如磁盘坏道导致启动不了，但你能把数据文件拷到另一台机器上。操作起来需要点底子，但关键时刻能救命。
说到底，PG崩溃恢复这件事，三分靠技术，七分靠平时准备。你平时开了归档，做了定期备份，崩溃之后无非就是按部就班地恢复。你要是啥都没配，那真到崩了那一刻，就只能靠搏一把，或者拿去刨数据了。我见过太多人，平时觉得备份麻烦，觉得归档占磁盘，结果真出事的时候跪在机房求数据。别学他们。现在你拿着这篇指南，先把归档开了，把备份脚本跑起来，然后找一台测试机模拟一次崩溃，按上面的步骤走一遍。等你真正练过手了，下次再遇到数据库崩溃，你就能像老司机一样，稳稳地把车停在路边，而不是一头撞树上。
