故障存储:

群晖（Synology）5.45TB/文件系统:ext4/块大小:4KB

故障现象:

某日管理员清理早期数据时误删除了两条视频文件，发现误操作后直接断开了网络并对存储进行了关机操作。

故障分析:

在开始分析前先对ext4文件系统做个简单的介绍:

Linux系统中的ext2、ext3、ext4 文件系统，它们都有很强的向后和向前兼容性，可以在数据不丢失的情况下进行文件系统的升级。ext4是一个相对较成熟、稳定且高效的文件系统，适用于绝大部分规模和需求的Linux环境。

ext4突出的特点有：数据分段管理、多块分配、延迟分配、持久预分配、日志校验、支持更大的文件系统和文件大小。而和其它的老前辈一样，ext4仍然使用块（Block）和块组（BlockGroup)进行管理，最小的操作单元就是块（类似于windows的簇)。本例中的块大小为4KB（如图1），4KB算是比较经典的块大小了，兼顾了IO性能和空间的浪费，不仅仅是ext4实际上ntfs文件系统也更加偏爱4KB的块（簇）大小。

一般来讲，NAS还是比较偏爱ext或者btrfs的，这个小存储做为视频数据最终的“落脚点”使用ext4相对来讲比较适合，因为整体的系统开销会更低。而做为网络服务器更多的使用“网络IO”，网络IO的典型特点就是：1、排队  2、分块，比如同一时间可能会有摄像头A和摄像头B都有IO请求，这个时候就需要先排队，再写入，（A写一块然后再写B不断循环）这样就导致了数据的“碎片化”，现实情况下可能排队数量远远大于AB两个客户端，可能会更多。此案例中使用的是mp4文件，这也是目前使用比较广泛的封装格式，其文件结构相对“弹性”，可以实现分块传输、在线播放（如图2）。通过对存在文件的分析发现以下特征：

1、碎片数量多

2、碎片区间较大

3、偏移值并非线性而是随机

这些特殊的情况都让这次恢复变的难度很高，特别是第2点，可以看到实例分析中的碎片区间已经达到了1.36TB（如图3），此文件还算是碎片数量较少的。

图1：块大小为4KB

图2：mp4文件使用AVC视频编码和MP4A音频编码

图3：碎片化的存储方式典型的“网络IO”

故障处理:

STEP1：“海选”式定位文件。

由于存储空间较大，而其MP4使用的是结构体前置的方式，所以初步方案是先进行文件头定位，在海量的数据中去查找客户所需要的文件，当然前提是文件头没有被覆盖，如果此方案无果再进行深入遍历。

使用通用恢复软件成功找到客户所需要的两条视频，由于存在碎片的原因，仅仅能播放前1分钟的画面，但也成功定位到了文件头所在的块偏移（如下图），经过“海选”定位文件没有被覆盖的可能性概率较大，这样就可以继续下一步的恢复工作了。

图4：海选式定位

STEP2:确定大概范围。根据分析的视频特征进行数据定位，由于空间过大的原因还是使用了手工定位。