UNIX文件系统下误删除的数据恢复经典案例--UFS删除恢复

•事件描述 
Sun阵列柜中的一个272GB的LUN和一个1TB的LUN,在Solaris 8下格式化成UFS文件系统,由于用户的误操作,导致数据丢失,用户具体操作如下： 
用oracle用户运行shell脚本，误删除了从根目录往后的具有oracle用户权限的所有目录和文件，/data1和/data2是两个文件系统的挂载点。/data1文件系统存放oracle数据库的备份文件，备份文件以压缩文件.gz.Z的形式存放；/data2文件系统是存放oracle数据库的所有数据文件。oracle用户对/data1和/data2都具有删除权限，运行shell脚本后，/data1和/data2目录下的文件和目录都被清空了。

当用户发现误删除了以后，马上把备份在异地的备份文件拷贝到/data2文件系统下，当所有备份文件拷贝完成以后，解压.gz.Z文件时发现问题，原来异地备份的.gz.Z文件在网络传输的时候没有完整的完成，只是传输了部分内容，最后几经努力，异地备份的文件被宣判为不可用，需要从/data1或者/data2两个文件系统中恢复被删除掉的文件。

•要恢复的文件：/data2下的oracle数据文件或者/data1下的oracle数据备份文件，总的数据量大约120GB。

•经过多方导论，认为/data2文件系统在删除文件以后，又往/data2文件系统下拷贝异地的oracle备份文件，拷贝完成以后又解压.gz.Z文件，总之在/data2文件系统下删除数据以后往这个文件系统又写了200-300GB的数据，原始数据能成功恢复的几率已经很小了。而/data1文件系统在删除文件以后，没有往这个拷贝过新的数据，所以决定从/data1文件系统去做数据恢复。

•具体的恢复过程：
1、把/data1文件系统 DD到移动硬盘上，这是为了保证原始数据的安全。
2、从DD出来的镜像进行分析，并恢复数据。
3、对恢复出来的数据进行验证，本案例要恢复的是.gz.Z 的oracle数据库备份文件，只要恢复出来的.gz.Z文件能正常解压缩，就说明文件恢复成功。

•UFS文件系统误删除恢复技术：
1、UFS文件删除文件的时候，会清空Inode的数据指针，恢复难度大大增加。
2、UFS文件系统如果启用日志功能，删除文件的时候会在日志中记录metadata的变化，这是UFS文件系统删除以后能快速恢复的救命稻草。

•恢复结果：
通过对/data1文件系统的分析，发现部分删除文件的metadata信息在日志里还有记录，有部分删除文件metadata没有记录，有metadata记录的文件可以通过Inode信息直接提取数据文件，没有metadata的文件，我尝试寻找该文件头部，确定它的直接地址指针和二级、三级间接地址指针位置，然后构造出Inode信息以后直接提取数据，最后完整恢复出所有.gz.Z文件。

体会心得 ：
对于ext3/ext4、UFS、JFS文件系统，删除文件以后，数据恢复还是可以尝试的，只不过难度要比其他文件系统大一些，灵活应用日志信息以及分析Inode地址指针存放数学规律，有时候就把不可能的事变成可能的事。这个是数据恢复案例上比较经典的UNIX数据恢复技术。

作者：覃廷良，达思数据恢复技术专家，转载至少请保留版权(出自http://www.bnuol.com)，谢谢。