做技术这行，最怕半夜手机响。上周我一个朋友在电商公司当运维，凌晨三点接到电话，说数据库被误删了。他整个人直接从床上弹起来，脸都顾不上洗就往公司冲。等到机房一看，好家伙，整个生产库的数据表全没了，连备份文件都不知道被谁顺手清空了。他当时脑子里一片空白，心想这下完了，年终奖肯定泡汤了。
结果你猜怎么着？他硬是花了四个小时，从数据库的日志文件里把数据一点点抠了回来。事后他跟我说，数据库被删这事儿，真不用慌，关键在于你得知道数据去哪儿了。很多人一听说数据库没了，第一反应就是完蛋了，其实完全不是这么回事。数据库本质上是一堆文件，只要这些文件没有被真正覆盖掉，数据就还有救。
先说最常见的误删情况：用delete语句删了数据。这种删除方式最温柔，因为它只是在数据行上打了个“已删除”的标记，实际数据还在磁盘上躺着。这时候只要赶紧把事务回滚，或者从binlog里把对应的操作找出来回放，数据就能恢复。我见过最夸张的案例，有人删了半年的订单数据，硬是从binlog里一条条捞回来，花了三天时间，但数据完整度达到了百分之九十九。
如果用的是drop命令删表，情况就严重一些。这个命令会直接把数据表的元数据给清掉，操作系统层面看，那个表文件还在，但数据库已经不认识它了。这时候千万别重启数据库，也别做任何读写操作，赶紧把数据目录备份一份，然后用专业的恢复工具去扫描磁盘碎片。MySQL有个叫undrop-for-innodb的开源工具，专门对付这种情况，成功率相当高。我就用这个工具帮朋友恢复过一个三百多G的订单表，只要数据没被覆盖，基本都能找回来。
最要命的是rm -rf这种物理删除，直接把数据库文件从磁盘上抹了。但即便如此，也别急着放弃。Linux系统删除文件，只是把文件的inode标记成可覆盖状态，文件内容还留在原来的磁盘块上。这时候立刻停止所有写入操作，用extundelete、testdisk这类工具扫描分区，有很大概率能把文件找回来。我认识一个DBA，公司服务器被黑客入侵，数据库文件全被删了，他用testdisk在裸设备上扫描，硬是把核心业务数据恢复了八成。
不过这里有个坑，很多人不知道：恢复操作越早做越好。因为磁盘上的空白空间随时可能被新数据覆盖，一旦覆盖，神仙都救不回来。所以正确的流程是：发现数据丢失→立刻停止所有数据库服务→把数据目录所在的磁盘做成镜像→在镜像文件上做恢复操作。千万别直接在原盘上折腾，万一操作失误把数据彻底覆盖了，哭都来不及。
说到备份，这才是真正的救命稻草。很多人数据库被删后手忙脚乱，就是因为没有备份，或者有备份但没有验证过。我见过最离谱的案例，一个创业公司每天都做全量备份，但备份脚本写错了，实际备份的是空目录，整整半年都在备份空气。等到数据库真出问题，才发现所有备份文件都是零字节。所以备份的关键不在于“做了”，而在于“能恢复”。每个月至少要做一次恢复演练，把备份文件还原到一个测试环境，确认数据能用。
还有一种很多人不知道的恢复途径：云服务商的快照功能。如果你用阿里云、腾讯云、AWS这些云服务，他们默认会给磁盘做快照，保留最近几天的数据状态。数据库被删后，直接回滚到某个时间点的快照就行，比什么恢复工具都靠谱。我有个客户，数据库被员工误删后，直接找云服务商开了工单，半小时不到就恢复到了前一天的状态。唯一的代价是丢失了当天几个小时的数据，但比起数据全丢，这点损失完全可以接受。
说句大实话：数据库恢复这事儿，三分靠技术，七分靠运气。技术再好，如果数据被覆盖了，或者磁盘被格式化了，那真是回天乏术。所以最保险的办法，还是建立完善的备份机制，而且要做到异地备份、冷热备份相结合。本地一份，云端一份，磁带库再放一份，做到三保险。这样就算数据库被删了，最多损失几个小时的数据，绝对不会伤筋动骨。
数据库被删别慌，记住这几个恢复方法，关键时刻能救命。但更重要的，是平时就把备份当回事，别等到出事了才拍大腿后悔。
