数据库崩了，你慌不慌？这事儿我见多了。上周一个朋友半夜打电话，声音都在抖——他们公司核心业务库突然挂了，所有数据查不到，客户电话打爆。我问他备份在哪儿，他说有，但备份文件也坏了。这种时候，恢复数据就成了救命稻草。数据库恢复不是玄学，而是一套有章可循的流程。说白了，就是跟时间赛跑，跟错误数据抢地盘。你平时觉得备份麻烦，觉得恢复工具多余，真到用的时候，才知道这些东西值多少钱。别等数据丢了再哭，先搞清楚怎么往回捞。
备份这东西，很多人当摆设。我见过最离谱的案例，一家电商公司每天做全量备份，结果硬盘坏了，备份文件全报废。备份策略要讲究“三二一”原则：至少三份拷贝、两种不同介质、一份异地存放。全量备份是底裤，增量备份是外套，日志备份是补丁。你光穿底裤出门肯定冷；但只穿外套不穿底裤，风一吹也尴尬。实操中，全量每周一次，增量每天一次，日志每半小时一次，这样万一崩了，你能恢复到最近半小时的状态。别嫌麻烦，想想丢两个小时的数据，老板能把你吃了。
恢复分好几种场景。最简单的是误删数据，比如有人手滑 drop 了表。这时候，闪回技术就是救星。Oracle 的闪回查询、MySQL 的 binlog 回放，都能在几分钟内把你拉回删表前的瞬间。但前提是你得提前开启了相关功能。我之前采访过一个 DBA，他说最头疼的是用户删完表还顺手做了全量备份，把错误状态也备份下来了。这种时候只能从归档日志里找，像考古一样挖数据。别笑，真有人这么干。所以恢复的第一步不是动手，而是诊断——先弄清楚崩在哪儿，是硬件故障、操作失误，还是勒索病毒。
硬件坏了相对好办。硬盘故障最常见，尤其是机械盘，读写多了容易出现坏道。这时候有 RAID 阵列就爽了，换块盘自动重建。但如果 RAID 卡也崩了，就得靠底层工具。像 ddrescue 这种工具能把坏盘上的数据一比特一比特抠出来，慢是慢点，但能救多少算多少。固态硬盘更麻烦，主控芯片一烧，数据基本没戏。所以别把所有鸡蛋放在一个篮子里，云存储加本地盘混搭才是王道。我有个运维朋友，公司花大价钱上了全闪阵列，结果电源浪涌把控制器烧了，靠异地备份才活过来。
勒索病毒是现在的噩梦。前两年某医院中招，所有病例数据被加密，黑客要 50 个比特币。他们没备份，只能交赎金。交完赎金拿到的解密工具还是坏的，只能从日志里手工恢复部分数据。对付勒索病毒，隔离备份是关键。备份系统不能和主库在同一网络段，最好离线保存。想想，病毒顺着网线把备份也加密了，那还怎么玩？恢复流程也得变——先断网，再查病毒残留，从离线备份里恢复。别急着连回去，否则刚恢复完又被锁了。
数据恢复工具有很多，但要挑对场合。MySQL 的 mysqlbinlog 能解析 binlog，Oracle 的 RMAN 是标配，PostgreSQL 的 pg_rewind 能快速修复从库脑裂。但工具不是万能药。我见过有人用开源工具恢复 SQL Server 数据库，折腾三天后发现工具不兼容，数据全乱码。专业的事交给专业工具，别贪便宜。商业工具如 Stellar、EaseUS 虽然收费，但恢复成功率比盲目操作高得多。尤其是表结构损坏的情况，手工恢复几乎不可能，必须靠工具自动修复。
有时候恢复比备份还重要。很多公司重视备份，却从不演练恢复。问他们备份文件在哪儿，答得上来；问他们怎么恢复，支支吾吾。真实案例：某金融公司每周做备份，结果一次崩库后，发现恢复脚本三年没更新，数据库版本都变了，恢复流程全废。恢复演练应该每季度搞一次，模拟真实场景，比如“主库挂了，从库也挂了”这种极端情况。你可以在测试环境里跑一遍恢复流程，记录所有步骤，写成文档。别靠记忆，也别靠某个人——万一那个人离职了呢？
说句实在话：数据库恢复的本质是预防。你花在恢复上的精力，不如花在预防上。备份策略要自动化，监控要实时，权限要严格。别让普通员工拥有 drop 表的权限，别让开发直接连生产库。我认识一个 CTO，他在公司搞了个“数据安全三件套”：自动备份、异地容灾、恢复演练。三年没出过一次数据事故。不是运气好，而是准备足够。数据是你的命根子，丢了再恢复，就像亡羊补牢——补好了也心疼那几只羊。所以，现在就去检查你的备份，别等崩了再慌。
