这事儿我得从上周一个朋友的电话说起。他在一家电商公司管数据库，半夜三点打过来，声音都有点变调：“完了，磁盘阵列直接挂了，RAID卡也报错，数据全读不出来。”我问他备份呢，他沉默了三秒，才说备份也在这台阵列上。那一刻，我脑子里蹦出的第一个念头是：这哥们儿怕是得重新找工作了。数据库介质故障听起来像教科书里的术语，实际上却是每个 DBA 的噩梦。硬盘坏道、控制器死机、存储网络断连，任何一个环节出问题，数据就可能变成一堆二进制“尸体”。更操蛋的是，很多时候你以为已经做好万全准备，结果发现备份策略不过是纸糊的盾牌。
介质故障之所以让人头皮发麻，是因为它不像应用程序崩溃那样可以靠重启糊弄过去。应用挂了，你重启服务，最多丢几分钟数据，业务还能继续跑。但硬盘物理损坏，或者存储系统的逻辑损坏，就像房子地基塌了，上面的装修再漂亮也没用。我见过一家创业公司，把核心数据库放在一块二手 SSD 上，连 RAID 都没做。某天 SSD 主控芯片烧了，数据恢复公司开价八万，老板当场脸绿了。结果还是没恢复成功，因为芯片级故障根本无法读取。这种案例在中小公司里比比皆是，大家总觉得自己运气好，或者认为“数据丢了再录入呗”，直到真丢了才明白数据比命还贵。
说到恢复，很多人第一反应就是备份。但做好备份的人并不多。我见过最离谱的操作，是有人每天凌晨用 mysqldump 导出一份 SQL 文件，存放在同一块硬盘的不同分区里。这算什么备份？硬盘坏了，所有分区一起死，SQL 文件连个水花都溅不出来。真正的备份必须满足“3‑2‑1”原则：至少三份副本、两种不同介质、一份异地存放。而且要定期演练恢复流程，不能只把文件拷出来就算完事。我有个朋友的公司规定每季度做一次恢复演练，结果第一次演练就发现备份文件有坏块，恢复出来的数据全是乱码。要不是这次演练，真出事那天连哭都来不及。
介质故障恢复的手段大致分几种。最简单的是让 RAID 冗余发挥作用。比如 RAID 5 坏一块盘，换上去重建就行。但 RAID 不是万能药，RAID 卡本身也可能出问题，而且 RAID 5 在重建过程中如果第二块盘也坏了，就彻底凉凉。更高级的是分布式存储，像 Ceph 或 HDFS，数据分片加副本，坏几块盘不影响整体。但分布式系统也有坑，比如网络分区导致脑裂，或者副本一致性协议出 bug，数据仍会丢失。还有一种叫快照的技术，存储系统定期打快照，故障时回滚到某个时间点。快照的局限是只能恢复到快照时刻，中间的变更全都失去。如果业务要求零数据丢失，就必须使用同步复制或实时备份工具。
我处理过一个案例，某金融公司核心数据库的存储阵列控制器挂了，双控变成单控，性能暴跌，业务响应直接崩溃。更麻烦的是，单控模式下所有写操作都要等缓存刷盘，而硬盘本身还有坏道。当时我们用了 Oracle 的 Data Guard，搭建了一个异地备库，但备库的日志应用延迟了十几分钟。只能切到备库，丢了十几分钟的交易数据。虽然业务很快恢复，但合规部门找上门，因为金融监管要求数据零丢失。后来他们升级为存储双活方案，两个数据中心同时读写，任何一边故障，另一边都能无缝接管。代价是成本翻了三倍，但比起因丢数据被罚几百万，这钱更值得。
介质故障恢复的核心其实不是技术，而是预案。很多公司平时不烧香，临时抱佛脚。数据丢了才想起翻文档，结果文档是三年前写的，早就过时了。我还见过更荒诞的：某公司运维大哥自己写了个备份脚本，脚本里有个 bug，每次备份都会把旧备份覆盖掉。硬盘坏了，他想恢复备份，却发现目录里只有一个空文件。这种事儿说出来像段子，但真实发生的概率比想象的高得多。所以我说，预案要写在纸上，贴在墙上，还得定期演练。演练时最好让新人上手，老员工站旁边指导，别让唯一的负责人独自承担。
说句实在话，数据库介质故障恢复本质上是概率和成本的博弈。投入越多冗余和备份，故障带来的损失就越小，但成本也越高。很多公司觉得“反正数据丢了还能从客户那里再拿回来”，或者“业务量小，丢点数据无所谓”。这种想法迟早会栽跟头。我见过最惨的一家 SaaS 公司，客户数据全丢，结果被集体起诉，直接破产。数据活着时不觉得重要，死了才知道它比命还贵。所以，该做 RAID 的就做 RAID，该异地备份的就异地备份，该买双活的就买双活。别等硬盘“咔嚓”一声响，才想起该做的事，那时已经太晚。
