数据库这玩意儿，说白了就是个装数据的柜子，平时看着挺稳当的，可一旦出了毛病，真是叫天天不应。我见过太多人，数据丢了之后第一反应就是翻备份，结果发现备份已经过期，或者备份文件本身也坏了。这事儿并不稀奇，我有个朋友的公司，数据库莫名其妙就崩了，技术人员折腾了一宿，只能从半年前的备份里恢复，半年的业务数据全没了。你说这损失有多大？所以，数据库损坏恢复这事儿，真不是临时抱佛脚能解决的，必须提前想清楚怎么应对。
很多人把数据库损坏想得太简单，觉得不就是文件坏了嘛，重装一下、恢复一下就行了。实际情况比这复杂得多。数据库损坏的原因五花八门：硬件故障，比如硬盘老化出现坏道；软件出 bug，比如系统更新时写错了数据；还有人为操作失误，比如不小心删了表结构。最让人头疼的是，有时候数据库表面上看着没事，内部数据已经乱成一锅粥。我认识一个做电商的朋友，系统运行得好好的，突然某天订单数据全对不上，查了半天才发现是硬盘有坏道，导致索引文件损坏，数据虽在但索引乱了，找回数据比重新录入还费劲。
面对数据库损坏，最常见的错误就是直接上手乱试。一发现数据库打不开，就急着用各种工具去修复，结果越修越糟。我见过最离谱的例子，有人用网上下载的免费工具修复一个 MongoDB 数据库，工具号称能自动修复，结果直接把数据文件写成了乱码，连专业公司都救不回来了。正确的做法是，第一时间停止所有操作，把损坏的数据文件备份出来，然后根据具体情况判断：是硬件问题就先换硬盘，是软件问题再考虑修复工具。千万别抱有侥幸心理，觉得随便点两下就能搞定。
不同的数据库，恢复方法也完全不一样。关系型数据库比如 MySQL、PostgreSQL，通常有比较成熟的恢复工具和流程，像 MySQL 的 innodbforcerecovery 参数，可以在启动时跳过部分错误，把数据先读出来。但非关系型数据库比如 MongoDB、Redis，恢复起来就棘手得多，因为它们的存储结构更复杂，数据一致性依赖更多细节。比如 MongoDB 的 WiredTiger 引擎，如果某个数据文件损坏，恢复时可能需要手动处理很多底层存储，普通开发者根本搞不定。我建议平时多看看官方文档，至少要知道自己用的数据库有哪些恢复选项，别等到真出事才临阵磨枪。
备份这事儿，说起来简单，做起来全是坑。很多人觉得只要按时备份就行了，却忽视了备份文件本身也会出问题。比如备份时数据库还在写数据，备份出来的文件可能不一致；或者备份文件存储在同一个硬盘上，硬盘坏了备份也跟着完蛋。我见过最惨的案例，某公司用 crontab 每天跑一次 mysqldump，备份文件就放在服务器本地，结果服务器硬盘坏了，数据和备份一起消失。所以，备份一定要做到“异地、多份、定期验证”。异地存储可以放到云端；多份备份保留最近 7 天的每日备份和最近 4 周的每周备份；定期验证则每月随机抽取一个备份恢复出来检查，确保可用。
有些数据损坏，靠常规手段根本恢复不了，比如物理介质损坏或数据被恶意加密。这种情况就得请专业的数据恢复公司出手。他们通常有专门的设备和技术，比如硬盘开盘、文件系统修复等。但千万别自己瞎搞，比如把坏掉的硬盘接上电反复读取，只会让损坏更严重。我有个客户，数据库文件被勒索病毒加密，他尝试了各种解密工具都无效，花了好几万请专业公司，才从内存快照里找回了一部分数据。这笔钱该花就得花，但前提是要知道在什么情况下该找专业公司，什么情况下自己可以解决。
说到底，数据库损坏恢复这事儿，七分靠预防，三分靠技术。预防做好了，根本不会遇到需要恢复的情况；预防没做好，再厉害的技术也救不了你。所以，别等到数据库崩了才想起备份，别等到数据丢了才后悔没检查过备份文件。平时多花点时间在运维和备份上，比临时抱佛脚找恢复方案靠谱得多。真遇到问题也别慌，按照流程一步步来，实在不行就找专业人士。数据这东西，没了就是没了，再后悔也没用。
