一、数据库恢复，到底难在哪？
我举几个真实的例子，你就懂了。
案例一：Oracle归档日志损坏
去年有个福田的客户，Oracle 11g，RAC双节点。归档日志所在的磁盘阵列掉了一块盘，虽然RAID5没垮，但有几段归档日志读不出来。DBA想恢复前一天误删的几张表，发现需要的归档日志正好在那段坏区里。
一般的数据恢复公司会怎么做？把磁盘镜像出来，试图读出那些损坏的归档文件。但归档日志是顺序写的，中间缺了一段，整个日志链就断了，LogMiner根本解析不下去。
我们当时是怎么处理的？
先分析redo日志的块结构，找到损坏段前后的SCN号，确认缺了多大一段。然后从在线redo日志和闪回区里找有没有重叠的变更向量。最后，结合数据字典和undo表空间的信息，把那段缺失的变更直接跳过，用前后一致点的数据块重新构建逻辑记录。
这不是跑软件能解决的问题，这是得对着十六进制编辑器，一个页一个页地算。
案例二：MySQL ibdata1被误删
上个月，龙华一个电商公司的运维，清理磁盘的时候把ibdata1给rm了。MySQL 5.7，独立表空间没开，所有表的数据和索引都在那个文件里。
客户先找了一家公司，对方用文件恢复工具把ibdata1找回来了，但文件大小只有原来的三分之二。一启动MySQL，InnoDB就报"page corruption"。
我们接过来之后，先不急着挂库。用我们自己写的页解析工具，把ibdata1里所有能识别的InnoDB页头扫一遍，统计有效页、坏页、空页的比例。然后按表空间ID和页号重新排序，把属于系统表空间的关键页（比如数据字典页、undo页、doublewrite buffer）优先修复校验和。
最后这个库恢复了，客户的订单数据一张表都没少。但你知道最惊险的是什么吗？ibdata1被删除后，文件系统只是标记了inode空闲，如果那台服务器继续写入了哪怕几MB的新数据，原来的页就可能被覆盖。 晚来两个小时，结果就完全不一样。
案例三：SQL Server日志文件（LDF）损坏
SQL Server有个特点，它的MDF和LDF是紧密耦合的。LDF里记录了所有未写入MDF的事务日志。如果LDF坏了，MDF在启动时会进入"恢复挂起"状态，因为SQL Server必须重做或回滚那些未完成的事务，才能保证数据一致性。
宝安一家制造企业的ERP数据库就遇到了这种情况。LDF文件所在的磁盘有坏道，LDF读不出来。前面恢复的人直接新建了一个空的LDF，强行附加MDF，结果数据库起来了，但数据是"逻辑不一致"的——库存数量对不上，财务凭证缺号。
我们去了之后，用底层工具绕过文件系统，直接从磁盘扇区读取残留的LDF碎片。然后按VLF（虚拟日志文件）的结构，把能识别的日志记录一条条抽出来，重建事务链。最后再用这些日志记录对MDF做redo，把数据库恢复到一致状态。
这个过程，没有现成的商业软件能做。
二、为什么我们能做别人做不了的？
很多人问我，东方护航做数据库恢复，跟别家到底有什么不同。
我想了想，大概有三点。
第一，我们是从存储底层长出来的。
公司从2010年开始做服务器维修和RAID数据恢复，干了十五年。RAID0、RAID1、RAID5、RAID6、RAID10，还有现在流行的分布式存储Ceph、HDFS、VSAN，我们都是从磁盘块级别开始研究的。
这意味着什么？意味着当数据库文件躺在损坏的磁盘阵列上时，我们不需要先把文件"恢复"出来再修数据库。我们可以直接分析磁盘块，跳过文件系统，从物理层读取数据库页。很多情况下，文件系统层面的"损坏"，在物理层其实是可读的。
第二，我们真懂数据库的底层结构。
Oracle的数据块、MySQL的InnoDB页、SQL Server的GAM/SGAM页、PostgreSQL的Heap Tuple、达梦M8的簇页结构——这些不是背下来的，是十五年里一次次实战磨出来的。
我们的工程师能对着hex dump告诉你，这个页是数据页还是索引页，这个槽位里的记录有没有被事务锁定，这个日志记录的LSN应该接在哪个LSN后面。这不是培训班能教出来的，这是半夜被叫起来处理case，一点一点攒出来的经验。
第三，我们在深圳，响应够快。
公司在福田深南中路，去南山、宝安、龙华、龙岗，基本上都在一小时车程内。香港、澳门的客户，我们也能当天安排工程师过去。
数据库故障不等人。很多场景下，每多等一小时，数据被覆盖的风险就增加一分。我们的7×24小时值班不是写在网站上的口号，是实实在在有人睡在办公室隔壁的值班室。
三、说几句得罪人的话
在深圳做数据库恢复，市场上鱼龙混杂。有些公司报价低得离谱，几百块钱就敢接，接过来就是跑个软件，能出多少算多少，反正钱已经收了。
数据库恢复这行，低价一定不靠谱。 一个合格的工程师，光是分析数据库结构就要花几个小时，再加上恢复、验证、交付，一个case动辄十几个小时。几百块钱的报价，连工程师的人工成本都覆盖不了，怎么可能给你认真做？
还有一种是"保证恢复"。听到这种承诺，你反而要警惕。数据库能不能恢复，取决于损坏的程度、覆盖的情况、日志的完整性。在没做完整分析之前，没人能打包票。我们做了十五年，也不敢说"100%保证"，只能说"尽最大努力，不成功不收费"。
我们的做法是：先免费检测，告诉你损坏原因、恢复概率、大概费用，你觉得合适再动手。 这个检测过程本身就要花一两个小时，但这是负责任的做法。
四、给DBA们的一点建议
干了十五年，见过太多本可以避免的事故。说几句实在的：
备份永远比恢复便宜。 别觉得备份麻烦，真出事了，恢复的费用和停机的损失，够你做十年备份。
不要只备份数据，还要备份日志。 特别是Oracle的归档日志、SQL Server的事务日志，关键时刻能救命。
测试你的备份。 很多人备份了几年，从来没恢复过，真到用的时候发现备份文件是坏的。
出事了先停写。 一旦发现数据库异常，第一时间停止所有写入操作，保护现场。每多一次写入，恢复难度就指数级上升。
别随便跑恢复软件。 很多"免费恢复软件"在扫描磁盘的时候会写入临时文件，这可能会覆盖你原本还能恢复的数据。先找专业的人做镜像，再操作。
