数据恢复案例:linux ext3 FSCK后文件系统损坏、数据丢失
2006-09-21 15:40
120 查看
转载请保留原作网站:http://www.sjhf.net(数据恢复)
DELL POWEREDGE2850.磁盘系统为SCSI36GB*3,RAID5。LINUX系统,FSCK后系统无法MOUNT。 经查,RAID5完好,FSCK后SUPERBLOCK及第1个块组中的位图、描述均被垃圾日志填充,第1个块组内的根目录也被垃圾日志填充。直观上无法知道文件系统的所有信息。 根据现存的文件系统节点及残留的日志区,还原出原来的SUPERBLOCK;
根据SUPERBLOCK分析,得出文件系统为EXT3,其原日志节点为8。
根据磁盘结构分析出日志节点的起始位置(日志信息的SUPERBLOCK及类型0x04的日志页)得到其大小, 4000 反分析其INODE,得到,以此为据,得到根目录节点。 转移到根目录区域,约逻辑地址500多LBA(通常在这个附近)已被垃圾日志填充;
从日志中还原根目录记录。
还原其他第一个块组内可能的INODE 进行文件系统结构化,已经可以在LINUX下MOUNT了,多数数据已经可以读取,但偏偏用户需要的重要数据多数出错,怀疑使用当中崩溃造成;
按照EXT3的特点,进行索引跟入。发现多数不可读节点被填充日志垃圾。
在日志文件中进行分析,如果可以回溯,直接生成好节点,拷贝进入;
如果日志无参考,通过数据区结构进行分析。(此例所有目录区均完好) 全部做完工作后,100%数据恢复成功。 阅读更多
DELL POWEREDGE2850.磁盘系统为SCSI36GB*3,RAID5。LINUX系统,FSCK后系统无法MOUNT。 经查,RAID5完好,FSCK后SUPERBLOCK及第1个块组中的位图、描述均被垃圾日志填充,第1个块组内的根目录也被垃圾日志填充。直观上无法知道文件系统的所有信息。 根据现存的文件系统节点及残留的日志区,还原出原来的SUPERBLOCK;
根据SUPERBLOCK分析,得出文件系统为EXT3,其原日志节点为8。
根据磁盘结构分析出日志节点的起始位置(日志信息的SUPERBLOCK及类型0x04的日志页)得到其大小, 4000 反分析其INODE,得到,以此为据,得到根目录节点。 转移到根目录区域,约逻辑地址500多LBA(通常在这个附近)已被垃圾日志填充;
从日志中还原根目录记录。
还原其他第一个块组内可能的INODE 进行文件系统结构化,已经可以在LINUX下MOUNT了,多数数据已经可以读取,但偏偏用户需要的重要数据多数出错,怀疑使用当中崩溃造成;
按照EXT3的特点,进行索引跟入。发现多数不可读节点被填充日志垃圾。
在日志文件中进行分析,如果可以回溯,直接生成好节点,拷贝进入;
如果日志无参考,通过数据区结构进行分析。(此例所有目录区均完好) 全部做完工作后,100%数据恢复成功。 阅读更多
相关文章推荐
- 数据恢复案例:linux ext3 FSCK后文件系统损坏、数据丢失
- 数据恢复案例:linux ext3 FSCK后文件系统损坏、数据丢失
- 数据恢复案例:linux ext3 FSCK后文件系统损坏、数据丢失
- 数据恢复案例:LINUX EXT3 FSCK 后降级为EXT2,MYSQL数据库丢失
- 数据恢复案例:LINUX EXT3 FSCK 后降级为EXT2,MYSQL数据库丢失
- 数据恢复案例:LINUX EXT3 FSCK 后降级为EXT2,MYSQL数据库丢失
- linux ext3下删除mysql数据库的数据恢复案例
- 对某网站LINUX FSCK后丢失大量文件的数据恢复过程摘录
- 对某网站LINUX FSCK后丢失大量文件的数据恢复过程摘录
- SAN,LINUX EXT3 LUN,存储ORACLE数据库,FSCK后出错,数据恢复手记
- oracle 恢复学习 案例1 一个数据文件丢失 完全恢复数据库
- Linux下EXT3误删除文件数据恢复之绝处逢生
- 一例LINUX EXT3数据恢复记录:硬盘坏道引起的数据故障
- 数据恢复-LINUX FSCK数据出错灾难应急方案
- Oracle 丢失数据文件和控制文件的恢复案例
- RMAN恢复案例——丢失所有的数据文件
- 硬盘坏道引起的LINUX ext3故障的数据恢复过程记录
- EXT3 文件丢失数据恢复
- linux用extundelete恢复ext2、ext3、ext4下rm -rf误删除的数据
- RAID50更换硬盘引起的数据丢失--数据恢复案例记录