# 删库 5 TB

LLMS 索引： [llms.txt](/llms.txt)

---

老冯前两天遇到了一起壮观的删库事件。一位社区朋友找过来，说出事了。一套 PolarDB for PostgreSQL，单机 Docker 跑在生产上，大几个 T 的数据没了。业务系统还挺重要，没有备份，损失惨重。

两三年前，老冯干过一次 [PostgreSQL 数据恢复](/pg/pg-filedump/)，给一家奇绩校友弄的。那次是一套 GitLab 的库，机器上挂了 bcache，一次断电把文件写坏了，然后几次 `pg_resetwal` 进一步放大了伤害。当时我也去市面上帮忙看了看做 PostgreSQL 数据恢复的公司，看下来都不太靠谱。最后朋友实在没辙，老冯就撸起袖子自己上了。

用的手段是 `pg_filedump` 做 page carving。说白了就是直接从磁盘上一页一页把数据页捡起来，认哪些还像是某张表，再一行一行把元组抠出来重新拼回去。听起来很酷，干起来全是苦力活，眼睛都要看瞎。最后数据是捞回来了。但那个库只有 1 GB。这次是 5 个 T。

五千倍。page carving 这种活，在 1 GB 上叫苦力活，在 5 TB 上就叫愚公移山了。而且它不是那种可以“慢慢来”的活，是客户在旁边喘着气、业务停摆、得连轴转好几天。

老冯最近每天都在疯狂 AI 蹬车，实在腾不出这个身子，所以还特意问了阿里云的几位朋友：你们这个 PolarDB for PG 的内核，原厂有没有数据恢复服务？Nope，原厂也没这项服务。

## 摇人

巧的是，老冯正好认识一位精通 PostgreSQL 数据恢复的老司机：PDU 的作者张晨。国内专门啃 PostgreSQL 数据恢复这块硬骨头的人本来就没几个，张老师肯定是佼佼者。于是就把他摇了过来，现在数据还在恢复中，七成以上已经出来了。这个数字放在“无备份 + 大几个 T + 冷门内核”的前提下，是相当漂亮的战绩。

具体是怎么做出来的，老冯就不展开了。这是人家吃饭的本事，不适合我在这儿当科普讲。我只能说围观下来比看剧刺激。至于客户是谁、什么业务，更是一个字都不会提。

不过这场事故本身，有两点感想值得单拎出来说说。

## 扁鹊的大哥赚不到钱

《鹖冠子》里有个特别有名的段子。

魏文王问扁鹊：你们兄弟三个都学医，到底谁最厉害？扁鹊说：大哥最厉害，二哥次之，我最差。文王愣了：那怎么天下只知道你？

扁鹊说，大哥治病，“于病视神，未有形而除之” —— 病还没成形就给你除掉了，所以名气出不了自家门；二哥治病，治在毫毛之间，刚冒个苗头就按住了，所以名气出不了巷口；而我，是在血脉上扎针、下猛药、割皮肉，人都快咽气了才上手，所以名声传遍诸侯。

数据库这行，一模一样。

老冯这些年[见过好几次删库](/db/database-really-exploded/)，剧本高度雷同：拿 Docker 起一个单机 PostgreSQL，跑通了，上线了。不但上线了，还跑得非常欢快，一跑好几年，什么事都没有。这让老冯想起万青那首《杀死那个石家庄人》——“如此生活三十年，直到大厦崩塌”。

跑了三年没出事，不代表这套架构是对的，只能说明你运气好了三年。作为一个生产业务系统，不说给你搭个备库做高可用吧，至少周期性 `dump` 一份、扔到另一台机器上去，这是最基本的职业操守。这事的成本是一个 `cron` 加几十行脚本。真出事的时候，它是你和深渊之间唯一那层窗户纸。

而且老实说，你都已经上了 PolarDB for PostgreSQL 这种冷门内核了，说明还是挺能折腾的，为什么不顺手用一下 Pigsty 呢？[Pigsty 是支持纳管 PolarDB for PG 的](/db/domestic-db-any-good/)。当年阿里云找过来问能不能支持一下，说会给老冯带点生意。结果生意一单没见着，支持倒是老老实实做完了，代码就摆在那儿，免费。

原生 PG 有的高可用、监控、时间点恢复（PITR），PolarDB for PG 一样不少，全都能用，一分钱不要。拿 Pigsty 搭一套，开箱就是自带高可用与时间点恢复的企业级数据库服务。当然，要老冯说，绝大多数人直接用原生 PG 就完事了，吃饱了撑的去折腾这些分支内核。但你非要用，老冯这儿也有现成的免费方案放着。

什么？不会搭？花两千块钱做个咨询，老冯至少能把“你具体该做哪几件事”给你讲明白。一年五万块钱订阅，这些坑老冯基本都能帮你提前填上，你也不用专门养一个人，大部分故障自愈，备份、异地备份基本不用操心。一年五万块钱，在一线城市连个实习生都雇不起。

另一条路是自己土法手搓，省下这两千块／五万，然后等翻车之后花几十万去做数据恢复，赔掉几百上千万的单子。微妙就微妙在这儿：绝大多数人 —— 是翻了车之后才开始认真对待数据库的。能在 Day 1 就意识到数据库有多重要的公司，老冯这些年见得极少。这种认知不是货架上的免费商品，是拿脑袋撞墙撞出来的 —— 得撞得头破血流，才换得回来。

所以“治未病”这门生意天然吃力不讨好：你把事情解决在它还没发生的阶段，既没有戏剧性，也收不上什么钱。人家救回来的是个快咽气的病人，你防住的是无数“本来也不会发生”的事故。在客户心里，这两件事的价值差着两个数量级。

扁鹊的大哥，赚不到钱。

## 止血的时候，别跟人砍绷带的价

第二点，当断则断，别磨磨唧唧。事故之后的头两天，往往不是花在恢复上的，是花在“要不要花这个钱”上的。这不是针对谁，老冯见过，流程都差不多：能不能先免费看看？先评估一下能恢复多少？能不能先把数据弄出来再谈钱？我们内部再讨论一下、走个流程 ——

两天就这么过去了。

而在所有这些拉扯的时间里，磁盘是不等人的。被删掉的那些块随时可能被新的写入覆盖掉，业务每多跑一分钟，理论可恢复率就往下掉一格。这是物理规律，不跟你讲价。假设你手上压着一个几千万的单子，现在数据库没了，恢复要几十万。老冯的决策是什么？他妈的当场打钱，越快越好。

第一时间合同签了，钱给到位，对面完全可以给你通宵、7 × 24 连轴转的。人家凭什么在没签约的情况下给你熬三个通宵？这中间差出来的，是本来也许可以避免的二阶伤害。停工的损失、数据丢失的损失，和数据恢复那点钱比，孰轻孰重？这笔账其实特别好算。但人在应激状态下算的往往是另一笔账：我是不是被人宰了？

这就像半夜送急诊，你躺在救护车上跟司机砍价。

说到底，大部分公司缺的不是钱，是 escalate 的意识 —— 没有一套“什么级别的事故、由谁在几分钟之内、拍板花多少钱”的预案。真出了事，一层层往上传，一层层等回话。等到能拍板的人终于搞明白发生了什么，最佳抢救窗口已经关上了。

## 这种生意，老冯宁愿少做

数据恢复这种活儿专业门槛高、投入大、结果还存在不确定性，真正有本事的人，理应获得相应的报酬。

两千块的咨询，五万块的订阅，几十万的恢复费，七八位数的业务 —— 这道算术题谁都会做，就是大多数人非要等到大厦崩塌那天才肯动笔。让我遗憾的是，很多这样的生意，本来就不该存在。

原本可以按照预案从备份恢复，最后变成专家对着残存的数据文件做考古；原本能在事前明确的响应渠道，最后变成事故群里四处求救。看起来是英雄救场，背后却是一堆本可以避免的麻烦。

所以，别把“最后还能找高手捞一把”当成你的灾备方案。高手应该是最后一道补救，不应该是唯一一份备份。老冯还是更愿意在系统没出事的时候，帮大家把该补的东西补上。少一点传奇，多一点按部就班；少一点通宵抢救，多一点正常下班。

希望下次朋友找到老冯，是说业务又涨了，要加几套数据库。而不是说库又没了，还没备份，赶紧摇人。

至于“壮观的删库事件”这种选题，**老冯宁愿一直缺货。**