邮件数据恢复解决方法

简介:

一.故障描述

由8块盘组成的RAID5, 上层是EXT3文件系统,由于误删除导致文件系统中的邮件丢失


二.镜像磁盘

为防止数据恢复过程中由于误操作对原始磁盘造成二次破坏, 使用winhex软件为每块磁盘做镜像, 以后所有的数据恢复操作都在镜像盘上进行, 不会对原始磁盘造成影响

镜像结果如下:

图一

wKioL1magGKStCvWAABO1WLf9jU207.png-wh_50

三.组建RAID

通过分析数据在硬盘中分布的规律, 获取RAID类型, RAID条带的大小,以及每块磁盘的顺序。根据分析结果使用UFS组建RAID。

结果如下:

图二

wKioL1magFmRFyF6AAHncwMHWc0963.jpg-wh_50


四.导出目标分区

从组建好的RAID中可以看出,上层划分了好几个EXT3分区,通过对每个分区中底层数据的分析, 发现605G的分区里面有大量的邮件头,并且有nsmail目录, 确认此分区是数据恢复的目标分区,使用UFS软件将此分区导出,以便后续处理。

图三

wKioL1magILw4hz0AAAaoxsK7z8364.png-wh_50

RAID中的所有分区如下:

nsmail文件夹:

图四

wKiom1magJaSmxTOAAExoH8jAE4732.jpg-wh_50 


邮件头示例:

图五

wKioL1magJ6Cu-zHAACCoy8b1ww205.png-wh_50

五.邮件恢复

由于EXT3文件系统中文件删除后,节点中的文件大小和块指针都被清零, 因此很难通过常规手段去恢复。针对EXT3文件系统的特点和邮件文件本身的结构,确定算法概要:

在整个文件系统范围内,做全盘扫描,将找到的邮件文件全部取出,然后根据邮件本身记录的收件人、发件人、抄送、主题等信息进行整理,最后再将数据迁移到263平台上

详细过程:

1.完成邮件标识程序,识别收发人、主题等memi标识程序编写。

2.完成ext3超过48k邮件提取程序编写。

3.按小于48k、大于48k两种算法对邮件进行提取。提取同时,生成邮件索引信息库,并且提取非自由空间和非邮件区。

4.对3中提取的非自由空间和非邮件区进行人工分析,确定有无遗漏的邮件,如果有,确定遗漏的原因,调整算法,重新进行扫描。

5.重复3,4过程,直到最后的非自由空间和非邮件区中没有遗漏的邮件。

6. 对所有提取出的邮件,按照数据库中解析到的收件人和发件人归类,每个账号一个文件夹,内含收件和发件两个文件夹。

结果:

第一次 导出邮件 68.2G, 数据量 692,767 个文件

第二次 算法改进后, 导出邮件 77.2G, 数据量 720,209 个文件, 多了3万文件左右

第三次 再次改进算法, 导出邮件 84.8G, 数据量 895,032 个文件, 比第二次多了174823

总的存储空间是605G, 邮件区占用84.8G 剩下的有491.6G 自由空间,属于全零区域,肯定没有邮件了,非自由空间和非邮件区的垃圾数据有28.6G

经过3次大的算法改进,以及中途无数的细节增删,至此,剩余的非自由空间和非邮件区经人工验证也已经无法找到新的邮件文件,只剩下一些邮件的中间碎片,无法进行拼接,以及一些杂乱数据,此结果经北亚数据恢复总监亲自审核。

示例如下,邮件中间碎片:

图六

wKioL1magK3ieILEAAHinoEMzjc761.png-wh_50

垃圾数据:

图七

wKiom1magL7gRz_oAACQgM6wDy8536.png-wh_50 

六.验证数据 

验证数据分为两部分,一个是邮件数据量的验证,通过对几个已知账号的收件和发件数量的统计,大概估算一下邮件的回复比例。二是邮件正确性的验证,用FoxMail打开提取出的邮件,查看内容是否正常.几个账号的数量如下:

图八

wKiom1magMjRYsdpAABFjhVA1_s672.png-wh_50

一些邮件内容:

图九

wKioL1magMvg2-DGAADqBCIYhBk003.png-wh_50

图十

wKiom1magOCw7UsOAAFtf_bgEfQ559.png-wh_50 

七.移交数据 

配合客户将所有提取出的邮件迁移到263平台










本文转自 宋国建 51CTO博客,原文链接:http://blog.51cto.com/sun510/1958029,如需转载请自行联系原作者
目录
相关文章
|
3月前
|
存储 安全 文件存储
【服务器数据恢复】Apple苹果Xsan文件系统卷宗误操作导致文件丢失数据恢复案例
客户因误操作删除了macOS服务器上的重要图片和视频文件,需紧急恢复。Xsan文件系统作为苹果专为高负载环境设计的64位簇文件系统,在未有专门恢复工具的情况下,常规RAW恢复仅能提取小部分连续存储的小文件,且无目录结构。通过专业的数据恢复流程,包括安全挂载、阵列重组,并使用专用工具解析文件系统以恢复目录结构,最终成功恢复丢失的文件。此案例突显了Xsan文件系统的特点及其恢复难度。
37 1
|
4月前
|
存储 数据挖掘 Linux
服务器数据恢复—服务器重装系统导致原分区丢失的数据恢复案例
服务器数据恢复环境&故障: 磁盘柜中有一组通过RAID卡创建的RAID5阵列,分配一个LUN,服务器上层安装Linux操作系统。操作系统层面划分sdc1和sdc2两个分区。通过LVM扩容的方式将sdc1分区加入到了root_lv中;sdc2分区格式化为XFS文件系统。 服务器重装操作系统后,磁盘分区改变,sdc2分区丢失,无法访问。
服务器数据恢复—服务器重装系统导致原分区丢失的数据恢复案例
|
5月前
|
存储 数据挖掘 索引
服务器数据恢复—服务器存储中文件夹丢失的数据恢复案例
服务器存储数据恢复环境: DroboPro FS网络存储,共8块SAS硬盘,组建了一组raid5磁盘阵列。 服务器存储故障: 存储中有一个共享文件夹丢失,该文件夹存放了重要数据。
服务器数据恢复—服务器存储中文件夹丢失的数据恢复案例
|
6月前
|
运维 Oracle 关系型数据库
【服务器数据恢复】服务器硬盘坏道掉线的数据恢复案例
服务器数据恢复环境: 一台IBM某型号服务器上有16块FC硬盘组建RAID阵列。上层linux操作系统,ext3文件系统,部署有oracle数据库。 服务器故障&检测: 服务器上跑的业务突然崩溃,管理员发现服务器上有2块磁盘的指示灯显示黄色。
|
运维 安全 数据挖掘
服务器数据恢复-服务器蓝屏无法启动的数据恢复案例
某公司一台华为机架式服务器,运行过程中突然蓝屏。管理员将服务器进行了重启,但是服务器操作系统仍然进入蓝屏状态。 导致服务器蓝屏的原因非常多,比较常见的有:显卡/内存/cpu或者其他板卡接触不良、硬盘出现物理故障、系统漏洞被利用,外部入侵、系统文件丢失或损坏等。这些情况都可能导致服务器蓝屏故障。 该公司将服务器送到北亚企安数据恢复中心。收到服务器后,北亚企安硬件工程师对故障服务器进行了物理故障检测,经过各方面的检测,没有发现服务器存在任何物理故障,也没有发现严重漏洞或者系统入侵的情况。初步判断服务器蓝屏的原因是操作系统损坏。
从堆里找回“丢失”的代码相关命令简介
从堆里找回“丢失”的代码相关命令简介
从堆里找回“丢失”的代码
从堆里找回“丢失”的代码
|
Docker 容器
快速备份邮件到新服务器
自建邮局后,遇到了意料中的问题:迁移邮件到新邮局,即把原来邮箱里的邮件全部复制到新邮箱。
111 0
|
存储 Windows
EasyRecovery16免费吗?功能恢复效果怎么样
EasyRecovery16是一款优秀的数据恢复软件,不仅能够兼容windows和mac双重系统,同时还能够识别u盘、存储卡、手机等多种数据储存设备,可恢复的文件类型更是多达百余种。还贴心地准备个人版、专业版和企业版的下载,增加了用户的可选性。
130 0
|
存储 安全 Windows