共计 993 个字符，预计需要花费 3 分钟才能阅读完成。
服务器数据恢复环境：
MYSQL 数据库服务器，2 块硬盘组建 RAID1；
DATA 卷存储了 200 多个数据库；
每天将每个数据库 dump 出后间接压缩成.gz 包，而后将所有重要数据库的.gz 包放在一起压缩成一个总的.tar.gz 包，笼罩原来的备份；
数据文件及备份文件全副存储于 DATA 卷上。
服务器故障 & 剖析：
在一次惯例的保护中，管理员不小心将 DATA 卷下的所有文件全副 rm，删除后管理员马上关闭系统，再未做其它操作，但在删除那一刻有大量终端在拜访此服务器。
管理员分割咱们数据恢复核心要求复原 mysql 数据库文件（如 myd、frm、myi(可重建) 文件），或者每个数据库的.gz 包，或者所有重要数据库总的.tar.gz 备份包。
实践上，在 ext3 文件系统下删除数据会革除 inode 中除节点类型、日期外的其余属性如文件大小、数据存储地址等，这些属性会全副清 0。同时目录表中会以目录条目长度的形式屏蔽掉已删除的文件，但会保留节点编号，最初会扭转 BITMAP 中的空间占用标记。即便是目录表中存在删除文件的节点编号，但因节点内容曾经没有须要的货色，与数据区也是脱钩的。
从数据角度来说，大多数文件类型都会有特定的文件头标记，通过文件头标记是有可能找到删除文件的起始地位的。但 EXT3 文件系统以块组为单位进行存储，同时数据与索引是混合存储于数据区的，所以数据间断存储的可能性十分小，所以依照文件格式进行解决可行性不大。
惟一的计划是联合上述几个特色，加上对日志和存储过程的模仿剖析，尽可能地还原实在的存储构造。
服务器数据恢复过程：
1、首先对故障服务器的所有硬盘做残缺镜像备份。
2、基于镜像文件对总的.tar.gz 进行剖析并尝试复原，但复原进去的文件解压到一半左右就报错，后续文件列表也无奈列出。通过数据恢复工程师的剖析，发现呈现这种状况是因为在删除 DATA 卷下的所有文件时仍有数据写入毁坏了文件。
3、对每个数据库的.gz 包进行剖析并尝试复原，大多数数据库的.gz 包复原胜利。
4、对于未复原胜利的数据库.gz 包，间接复原其 myd\frm 数据文件，最终将所有数据库的.gz 包复原胜利。
5、通过用户亲自验证，复原进去的数据残缺可用。
服务器数据安全 Tips：
1、LINUX EXT3 文件系统下数据删除后应尽快断掉文件系统 I /O，通常 umount 文件系统即可。
2、对故障卷做 dd 备份，确保数据恢复操作不会对原始数据进行二次毁坏。
