北京某游戏公司，一台老的IBM服务器，服务器为CentOS6.4操作系统，服务器使用两块SCSI 73GB硬盘，两块硬盘都使用LVM管理。
某天该服务器被黑客攻陷，黑客删除了大量的用户数据和系统数据。
服务器中最重要的是该公司一个内部的后台管理应用，应用使用了MySql5.5数据库。
MySql数据库每天生成一个备份，备份在/usr/bak 目录下，黑客也删除了数据库和数据库的备份。
数据很重要，如果数据不能恢复将给该公司的运营带来很大的困难。在管理员用了不同方法和不同数据恢复软件后，仍然不能恢复数据。
后，客户找到北京安数云和公司，北京安数云和公司的尹工在听取客户描述后，认定数据可恢复性很高。北京安数云和公司的尹工让客户在关机状态下把硬盘拔出，并按槽位做好标记，把硬盘带到北京安数云和公司进行数据恢复。
接上硬盘进行底层分析，并把要恢复的硬盘镜像到北京安数云和公司内部的临时存储中，后面所有操作只在临时存储上执行，原硬盘不再操作。
客户表示只要恢复最新一个MySql备份文件就可以了。
存放数据的文件系统为EXT4 。linux的EXT2/3/4文件系统在删除文件目录后，会把所有删除的文件和目录的Inode中的描述文件大小和文件数据分配指针 区域全部用0填充。
而Windows在删除文件目录后，只在MFT上做一个标记，描述文件大小和文件分配的区域没有变化（文件大小大于4GB的文件除外）。
这也是Windows删除文件目录后容易恢复，而linux删除文件后数据恢复变得非常困难的原因。
用磁盘底层分析软件WinHex找到 /usr/bak 目录，目录被删除，目录的inode中大小和目录块的指针被清0，WinHex软件无法解析，无法进入目录：
北京安数云和的尹工通过EXT4文件系统中残留的信息，拼出 /usr/bak目录的inode中被清0的数据，winhex软件可以进入目录，看到了文件列表：
目录中所有文件大小都是0字节，这些文件的Inode中的表示文件大小指针和数据块分配指针都一样被清0。
再次通过EXT4文件系统中残留的信息拼出要恢复的文件的Inode数据，要恢复的文件大小和数据分布指针已正常，直接用Winhex导出数据：
数据库备份很小，用了gz压缩，才16.8MB，压缩前约110MB。恢复出数据，检测gz压缩包，数据正常：
然后客户把恢复出来的数据传回公司，公司的的工程师正常把备份还原，查看数据也全部正常。
