这事儿得从头说起。上周有个朋友半夜打电话，语气急得像热锅上的蚂蚁：“我服务器上的MySQL数据库突然崩了，数据全没了，怎么办？”我听完第一反应是问他备份了吗，他沉默了三秒钟，然后说“备份脚本跑了半年，但最近硬盘满了，备份没写进去。”这种情况我见得太多了。Linux下数据库出问题，十有八九不是系统要跟你作对，而是你自己给自己挖了坑。但话说回来，就算真没了备份，也不代表数据就彻底完了。Linux系统有个特点，它不会主动删你硬盘上的数据文件，哪怕服务挂了，那些二进制文件、表空间文件、日志文件，只要没被覆盖掉，就还躺在磁盘上等着你捞。关键在于，你要知道从哪儿下手，以及别慌着做傻事——比如马上重启系统或者重新安装数据库软件，那才是真正的数据杀手。
数据库崩溃最常见的原因无非那么几种：磁盘空间满了导致写入失败、突然断电导致日志文件损坏、配置错误导致无法启动、或者更倒霉的，误操作删了关键表。不管是哪种，第一反应应该是检查数据库的数据目录是否还在。MySQL的数据目录默认在/var/lib/mysql，PostgreSQL在/var/lib/pgsql，MongoDB在/var/lib/mongodb。直接ls看一眼，如果目录还在，里面文件也都在，那大概率只是数据库程序或者配置出了问题，数据本身没丢。这时候千万别手贱去跑什么mysqlinstalldb或者重新初始化，那会直接把现有数据目录覆盖掉，神仙都救不回来。正确的做法是先备份一份数据目录到安全位置，比如cp -r /var/lib/mysql /tmp/mysqlbackup，然后再去排查数据库无法启动的原因。有时候问题简单得令人发笑，比如磁盘满了，df -h看一眼，删点日志文件，重启服务就完事了。
如果数据目录里的文件已经损坏或不完整，那就得换思路了。MySQL的InnoDB引擎有个好东西叫redo log和undo log，redo log记录的是已经提交的事务，undo log记录的是未完成的事务。只要这两个文件还在，就能用工具把数据抢救出来。比如Percona Data Recovery Tool for InnoDB，这玩意儿专门干这活的。用法也不复杂，先停掉数据库服务，然后跑命令：./innodbrecovery -s /var/lib/mysql/ibdata1 -d /var/lib/mysql/。它会把能读出来的行数据导出成SQL文件。当然，这工具不是万能的，如果文件被严重破坏，可能只能捞出部分数据。但哪怕捞出一半，也比全丢了强。另外，MySQL还有个myisamchk工具，专门修复MyISAM表。如果数据库用的是MyISAM引擎，直接myisamchk -r /var/lib/mysql/dbname/tablename.MYI，很多时候就能把表修好。注意，跑修复前一定先备份，这工具虽然好用，但操作不当也可能把数据搞得更乱。
PostgreSQL的恢复比MySQL要温和一些，但前提是你得懂它的机制。PG的数据文件是WAL（Write-Ahead Log）机制，所有写入操作先记日志，再写数据文件。所以只要WAL文件还在，就能实现时间点恢复。如果数据库彻底起不来了，先检查/var/lib/pgsql/data/pgwal目录下的文件，看看是否有损坏。然后可以尝试用pgresetwal工具重置WAL日志，但这招是救命稻草，因为它会丢失所有未提交的事务。更稳妥的做法是，如果数据库还能以单用户模式启动，就进去把数据导出来。命令是：pgctl start -D /var/lib/pgsql/data -o '-P'，然后连进去用pgdump把所有数据导出成SQL文件。如果连单用户模式也进不去，那就得拿出杀手锏：用pgfiledump或pgrecovery工具直接解析数据文件，把表里的行记录一条条读出来。这过程很痛苦，需要手动指定表的结构信息，但遇到关键业务数据，这点功夫值得花。
还有一种情况，不是数据库崩了，而是你手滑把表删了。比如drop table或者truncate table，这种操作在MySQL里默认是没法回滚的，除非你开了binlog并且binlog格式是row。如果开了binlog，那恭喜你，还有救。先找到binlog文件，用mysqlbinlog工具解析出删除操作之前的SQL语句。比如：mysqlbinlog --stop-position=123456 /var/lib/mysql/binlog.001 > recover.sql，然后从recover.sql里找到删除表之前的insert语句，重新执行一遍就能恢复数据。但要注意，binlog默认只保留几天，而且如果你删表之后又做了大量写入操作，binlog可能会被覆盖。所以一旦发现误删除，第一件事就是停掉所有写入操作，然后赶紧把binlog文件拷出来。PostgreSQL的情况类似，它有个pgwal目录，里面存了所有WAL文件，但要从WAL里恢复单张表，需要用到pgwaldump工具解析日志，再手动重建数据，操作门槛比MySQL高不少。
数据目录彻底没了怎么办？别急，Linux的文件删除机制给了你一个缓冲期。当你rm -rf一个文件之后，文件内容并不会立即从磁盘上消失，只是inode被标记为可重用。只要没有新的数据写入覆盖这些磁盘块，文件就还在。这时候可以用extundelete或者testdisk这类工具来恢复。以extundelete为例，先卸载数据目录所在的分区，防止写入操作覆盖数据，然后跑命令：extundelete /dev/sda1 --restore-directory /var/lib/mysql。它会扫描整个分区，把还能找到的文件恢复到当前目录下的RECOVEREDFILES文件夹里。成功率取决于文件被删除后有多少写入操作。如果发现得早，基本能恢复90%以上的文件。但注意，一定要在卸载分区后操作，在挂载状态下恢复，系统随时可能写入数据覆盖掉你要找的文件。更狠一点的做法是用dd命令把整个分区做成镜像文件，然后在镜像上操作，这样即使操作失误也不会影响原数据。
如果连文件系统都坏了，比如硬盘出现坏道或者分区表损坏，那就得用更底层的工具了。Linux下的ddrescue是专门处理坏道硬盘的神器。它能跳过坏道，尽可能多地读取正常数据。用法：ddrescue -f /dev/sda /tmp/diskimage.img /tmp/diskmap.log。跑完之后会得到一个镜像文件，然后你再基于这个镜像文件去恢复数据。这过程可能很慢，一块500G的硬盘跑个一两天很正常，但总比数据全丢强。拿到镜像之后，再用mount -o loop /tmp/diskimage.img /mnt/recover把镜像挂载成文件系统，然后就能像访问普通分区一样去复制数据文件了。如果连mount都报错，说明文件系统元数据损坏了，这时候可以试试fsck修复文件系统，但fsck有风险，它可能会把损坏的文件当成垃圾清理掉。所以建议先备份镜像，再跑fsck，跑完之后如果不满意，还能从备份镜像重新来过。
想说一句，所有恢复技术都是亡羊补牢。我在系统里常年跑着一个脚本，每天凌晨自动备份数据库到另一个硬盘，同时保留最近7天的备份。备份完还会自动校验完整性，校验失败会发邮件报警。这套机制帮我救过好几次场。另外，定期做恢复演练也很重要，别等到真出事才发现备份文件是坏的。有个朋友的公司，备份脚本跑了三年，结果数据恢复时发现备份文件全是空的——因为脚本里忘记写实际备份命令了。这种笑话一点都不好笑。所以，如果你看完这篇文章，第一件事应该是去检查你的备份是否真的可用。至于那些恢复工具，记住它们的名字就好，最好永远别用到。
