如何利用小游戏开发框架提升企业小程序的用户体验与运营效率
1022
2022-09-24
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数据恢复技术。
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。
发表评论
暂时没有评论,来抢沙发吧~