故障存储:  32G TF卡   fat32文件系统  簇大小64sec

故障现象:

客户反映此卡被格式化后重新使用了一段时间，生成的文件容量大约163.81MB(实际上视频文件就1条，后期经过分析日志发现多数文件是通过手机端APP被恶意删除的并非格式化），剩余空间还有29.5G（如图1）。

图1：卡的剩余空间还有29.5G

故障分析:

小米的智能摄像头之前处理过不少，基本上规律如下:

1、1分钟生成一个文件。

2、文件格式为MP4，新式摄像头一般使用HVC高清编码。

3、采用的方案是在生成当前MP4文件结构体时，已经在采集新的视频画面数据，此时会导致两个文件碎片交叉，糟糕的是有时候碎片的大小仅仅只有一个簇，即碎片又小又多。

第3条会产生最不愿意看到的情况-----“音视频”数据区交叉，HVC采用的也是压缩算法，其会对采集画面进行量化后压缩，对于压缩来讲就是为了让数据不在松散，所以根本没有任何规律而言（有规律的一定是结构体而不是数据本身），此种情况下恢复难度是很大的，因为就算用CHS零壹视频恢复系列软件，也无法甄别数据区交叉碎片的情况，这个时候只能通过穷举遍历法结合恢复经验来判断。

图2：1.9M的文件在32K簇大小情况下竟然有40个碎片，典型的碎片又多又小

故障处理:

根据这种复杂的情况，通用型的恢复软件是无法恢复的，原理如下：

1、删除或者格式化后FAT32或者exfat 都会对FAT表进行清0，清0后存在碎片的文件是无法得到有效的链表的，没有链表就无法得到准确的数据。

2、由于文件不连续存放，所以此时通用型恢复软件只能通过目录项中的文件第一簇指针和文件长度，来定位文件头。然后按照连续存放的方式读取，这就导致恢复的文件除了第一簇其它全是错误的。

图3：通用型恢复软件R-Studio新版本增加了文件校验并提示发现存在碎片

图4：查看文件肯定是无法播放

但是我们可以使用通用恢复软件来扫描并定位文件的目录，FAT32格式化后只要目录项所在簇没有覆盖就能定位文件的第一个簇，也就是文件头所在，在来定位文件尾，两者之间就是数据区间

由于文件名中就包含了日期和时间所以这个也可以精确定位到客户需要的文件，经过通用软件扫描发现客户要的文件名都在，而且第一簇起始是相对靠中间的，所以恢复的机率还是比较大的。

下边这些话照抄之前的案例，解释的很清楚，就不再码字了 :-） :-） :-）

下图可以看到通用恢复软件只会定位到文件目录所在的第一个簇，也就是文件头所在，但是后边的区域就是直接以长度获取了，所以肯定是不能用的。通过这个方法成功定位了客户所要的时间段，由于是采用裸流，所以计划提取文件头所在的簇，得到第一帧画面，来和客户确定数据。但是发现失败了，因为以一个簇为单位进行提取发现视频帧是不完整的，说明碎片极小可能只有一个簇的大小（可以理解为首帧长度>簇长度）。其原理如图5，第一帧至少有三个DATA分割分别是DATA0~DATA2,注意DATA区本身就是对现实环境抽象化取值再转换成数字化的底层数据其是压缩类数据，没有参考值。另外就是图5中是为了方便介绍用了比较简单的方式，现实中可能DATA1和DATA0会“距离”很远，极端情况下也有可能DATA1位于DATA0之前（这在所有文件系统中都是允许的）。

图5：视频、音频帧数据存在碎片的简略图

经过使用不同的方案反复测试，发现没有比较好的办法应对，但是也找到了此类文件的规律，其采用moov后置方案，基本上可以判断在head和moov之间的数据就是此文件的所有簇列表，现在的问题是需要精确的定位碎片并分离数据，但是用常规的方法却无法做到。最后想到之前处理的一个JPG碎片案例，使用遍历方法不断以簇为单位写入，再查看数据，然后根据此方案再结合一些HVC的特征制定了以下恢复方案：

1、 获取文件区间

2、 视频帧自身特征来缩小范围

3、 日志和JPG文件头来缩小范围

4、2和3没有地方直接遍历

1、根据此方案，重新写了一个小程序进行碎片的筛选和定位，写入一轮再查看一轮，最终完成定位和重组，好在文件较小，经过对比时间需要的文件有11个，直接请出我们之前编写的“MOOV视频RAW级重组程序“，程序的精度和便利度已经很好了，所以直接处理即可，如果没有此程序，光靠纯粹的手工是一项不可能完成的任务。

图6：MOOV视频RAW级碎片重组程序是恢复此类案例很优秀的助手

下图为恢复效果，11个文件播放没有任何问题，视频帧及音频帧全部正常，11个文件消耗了约三天多的时间，恢复的成功验证了方案的可行性。

图7：重组好的视频文件

这就是小米智能摄像头APP删除文件又写入的恢复方法，大家在遇到此类问题时，可以和我们联系！