事情是怎么开始的

那天是周四，下午三点多，我正蹲在机房角落里啃一个三明治。手机突然开始震，微信群消息一条接一条往外蹦。我瞄了一眼，是118论坛的运营老张在群里@所有人，说论坛打不开了。我当时没太当回事，论坛嘛，偶尔抽风也正常，重启一下nginx多半就好了。结果老张紧接着又发了一条："数据库连不上，整个盘好像都出问题了。"我嘴里的三明治顿时不香了。

118论坛不是那种日活几百万的大站，但它是我们本地一个挺有年头的社区，从2009年就开始跑了。十几年的帖子、用户数据、附件资料全在里面。虽然平时看着不起眼，但真要说没了，那可不是小事。老张后来打电话过来，声音都在抖，说服务器商那边通知他硬盘出了物理故障，RAID阵列直接降级了，数据能不能保住不好说。

我到机房的时候，运维小李已经在了。他脸色不太好看，指着监控屏幕跟我说："你看这个IO曲线，从中午十二点半开始就不正常了，不断在报错。我以为是系统层面的问题，重启了一次，结果直接起不来了。"我问他有没有备份，他沉默了几秒钟，说："上一次全量备份是三个月前，增量备份的脚本上个月就挂了，不断没修。"

这句话一出来，我心里咯噔一下。三个月，对于118论坛来说，意味着差不多上万条新帖、几千个新注册用户、还有大量用户上传的图片和附件。如果只能恢复到三个月前，那跟丢了大半条命没什么区别。

先搞清楚到底坏了什么

慌归慌，活还得干。我让小李先把服务器下电，避免二次损伤。然后联系了服务器托管商的技术，让他们帮忙确认硬盘的具体状态。等回复的间隙，我跟老张通了个电话，让他先在备用域名上挂一个维护公告，别让用户瞎猜。

托管商那边回复得还算快：两块硬盘中的一块彻底不认盘了，另一块有大量坏道，SMART信息显示磁头也有问题。简单说，就是硬件级别的损坏，不是软件能绕过去的。RAID 1本来应该互为镜像，但坏的那块盘在彻底挂掉之前，可能已经把一些错误数据同步到了好盘上，所以两块盘的数据都不干净。

这时候摆在面前的选择有几个：一是直接找专业数据恢复公司，把两块盘送过去做开盘恢复；二是自己用ddrescue之类的工具试着把还能读的数据镜像出来；三是接受现实，用三个月前的备份恢复，然后想办法从其他渠道补数据。第一个方案最稳妥，但费用不低，而且周期长，老张那边不一定等得起。第二个方案风险大，操作不当可能让坏盘彻底报废。第三个方案最省事，但数据损失太大。

我跟小李商量了一下，决定先走第二条路——用ddrescue把坏盘上还能读的扇区尽量镜像出来。如果能拿到一个相对完整的镜像，后面的恢复就有戏。如果不行，再考虑送专业公司。

镜像过程比想象中更磨人

ddrescue这个工具的好处是它会记录已经读过的扇区，下次可以接着读，不会重复浪费时间。但坏盘的读取速度慢得让人抓狂，尤其是碰到坏道密集的区域，一个扇区要反复重试几十次。小李盯着终端屏幕，看着进度条一格一格往前爬，嘴里念叨着："这速度，读完得等到明年。"

我们设了参数，先跳过坏道密集的区域，把能读的地方快速过一遍，然后再回头慢慢啃那些难读的部分。第一遍跑完，大概拿到了85%左右的数据。剩下的15%里，有一部分是文件系统的元数据区域，这就比较麻烦了。

我让小李把镜像文件挂载到一个测试环境里，用extundelete和testdisk扫了一遍。结果不太乐观——数据库的核心文件（MySQL的ibdata和几个大表空间文件）有一部分扇区读不出来，正好落在坏道密集的区域。这意味着即使挂载上去，MySQL也起不来。

这时候已经是晚上十点多了，机房里空调嗡嗡响，我后背全是汗。老张又打来电话问进展，我没敢把话说死，只说"还在弄，有希望"。挂了电话，我跟小李说："换个思路，别直接恢复整个数据库了，先把ibd文件里的记录抽出来。"

从碎片里捞数据

MySQL的InnoDB引擎有个特点，就是数据和索引是分开存的，而且每个表有自己的表空间文件（如果开了innodb_file_per_table）。这意味着即使ibdata1损坏了，只要表的.ibd文件还在，就有机会把数据抽出来。我们用了一个叫innodb_ruby的工具，配合page_parser，开始从镜像里扫描.ibd文件的页结构。

这个过程有点像考古。每个页16KB，里面有页头、页目录、记录列表。我们要做的是找到那些还没被损坏的页，把里面的记录解析出来，拼成完整的行数据。有些页的头部还在，但数据区已经花了，这种就只能跳过。有些页虽然校验和不对，但记录本身还能读出来，这种就靠工具去尽力提取。

跑了一整夜，第二天早上七点多，结果出来了。用户表恢复了大概92%的记录，帖子表恢复了88%，附件表最惨，只有76%。但好消息是，关键的帖子内容表恢复得不错，大部分文字内容都在。丢失的主要是一些图片附件和少量最近几天的帖子。

我把结果告诉老张的时候，他在电话那头长出了一口气。虽然不完美，但至少论坛的骨架还在，用户还能登录，老帖子还能看。接下来就是补数据的事了——从搜索引擎缓存里找最近几天的帖子快照，从用户本地备份里回收一些附件，再让版主们手动补一些精华帖的内容。

那些踩过的坑和学到的教训

事情过去之后，我花了一个周末把整个过程复盘了一遍。有几个地方现在想起来还是挺后怕的。

备份策略形同虚设

118论坛的备份脚本是好几年前写的，全量备份用mysqldump，增量用binlog。问题是，mysqldump在数据量大了之后越来越慢，后来干脆跑不完就超时了。运维小李接手之后，发现备份文件大小不对，但也没深究，就把定时任务关了，想着"以后有空再修"。这一关就是大半年，直到出事。

这件事给我的教训是：备份这东西，不是设了定时任务就万事大吉了。你得定期去验证备份文件能不能恢复，得监控备份任务的执行状态，得确保备份文件本身是完整的。否则你以为自己有备份，其实跟没有一样。

RAID不是万能药

很多人觉得做了RAID 1就安全了，两块盘互为镜像，坏一块换一块就行。但实际上，RAID 1在重建的时候风险很大——如果另一块盘也有隐患，重建过程中很可能把它也拖垮。而且像这次的情况，坏盘在彻底挂掉之前可能已经把错误数据写到了好盘上，RAID反而成了"同步损坏"的帮凶。

所以RAID只能解决单盘故障，不能解决数据逻辑损坏和静默错误。真正靠谱的做法是RAID加上定期备份，再加上异地容灾。当然，对于118论坛这种小站来说，异地容灾可能成本太高，但至少本地备份得做扎实。

恢复过程中最怕的是"想当然"

我中间有一度想直接用fsck去修文件系统，幸好忍住了。fsck在文件系统元数据损坏的情况下，很可能会把还能恢复的inode直接标记为空闲，那就真的没救了。数据恢复这行有个基本原则：在没搞清楚损坏程度之前，不要对原始盘做任何写操作。所有的修复都应该在镜像上进行。

还有就是，不要迷信单一工具。testdisk扫不出来的东西，photorec可能能扫出来；extundelete恢复不了的文件，debugfs可能还有机会。多试几种工具，多换几个角度，往往能多捞回来一些数据。

后来我们做了什么

论坛恢复上线之后，我帮老张重新设计了一套备份方案。全量备份改成每周一次，用xtrabackup替代mysqldump，速度快很多，而且支持热备。增量备份用binlog，每小时同步一次到另一台机器上。另外加了一个监控脚本，每天检查备份文件的大小和修改时间，如果异常就发告警。

附件存储也做了调整，不再直接放在服务器本地盘上，而是走对象存储。这样即使服务器出问题，附件本身不会丢。数据库那边开了双机热备，虽然增加了点成本，但老张说经历了这次的事，他晚上终于能睡着觉了。

至于那块坏掉的硬盘，我最后没扔，用防静电袋装好放在了机柜顶上。小李问我留着干嘛，我说当个纪念品，提醒自己数据这玩意儿，你不把它当回事，它迟早会让你知道厉害。

整个恢复过程从周四下午出事，到周六晚上论坛重新开放，前后大概五十多个小时。中间睡了不到六个小时，吃了四顿外卖，喝了十几罐红牛。老张后来在论坛上发了个公告，说"因服务器故障，部分数据可能丢失，请大家谅解"，底下跟了一百多条回复，大部分都是"辛苦了""能回来就好"。有个老用户说了一句话我印象挺深："这个论坛比我孩子的年龄都大，要是没了，真不知道去哪儿找那些老帖子。"

可能就是这句话，让我觉得那五十多个小时没白熬。