中国的安防市场似乎从来不缺新品牌，市场上目前安防品牌多达30-50个。今天遇到的品牌是奇盾，一个连官网都没有，名不见经传的小小小品牌。

老样子，开始之前先简单介绍下故障现象，如下:

故障存储：希捷SV35 ST3000VX000，希捷标准的监控专用盘

故障描述：

此监控设备外接6个摄像头，2018年12月06号11点到13点之间发生了突发事件，之后监控设备被恶意还原出厂，并重新录了几个小时的视频。客户需要恢复指定时间段的监控视频。

故障分析:

还是要吐槽下国人办事风格，一窝风，看到安防赚钱就都投资安防，然后就催生了多达几十个安防品牌，每个品牌又自己设计了自认为效率高而又自我封闭的产品（表现为只能用自己的播放器播放）。笔者做为数据恢复从业人员关注的是底层文件结构，对于这种“各自为政”的现象深恶痛觉，我们为何不能像国外一样搞一个类似于XX行业，制定一个行业标准，这样重复的开发投入是一种赤裸裸的浪费。言归正传，由于之前刚刚恢复过名字为“亿盾安防”的品牌，所以让我产生了“奇盾和亿盾是一家”的错觉，然并卵，这两个名字上如此接近的厂商竟然是不同的两个牌子~~~

好吧，那就开始分析吧，经过分析发现这个奇盾的厂商还是比较有个性的，完全自己写了一种视频底层存储方案（说实话，在我分析过的所有安防品牌中就海康的方案是相对比较优秀的基本上把264或者265发挥到了极限）。经过分析发现，这个方案说白了和FAT32文件系统很接近。一个EXT的分区用于存储文件索引等明文，另一个自定义的RAW裸分区（请原谅我套用了甲骨文的概念名词，我十在不知道该用什么来描述这么奇葩的文件系统）用于存储数据，数据从RAW裸分区0扇区开始一直到结束，不断的以块为单位进行写入。这个自定义的文件系统就一个优势----极高的空间利用率，其它可以说全部是缺点了。

所有的文件随意的堆叠在一起，和FAT32下不断写入的文件相同，这种随意的写入方式（比如0号头有数据写入请求就开始做写入，此时1号头又有数据请求就排队）导致了极大的碎片化，另外估计是为了在手机APP上查看方便，在写入原始视频数据时，还会排队写入原始视频的缩小版（分辨率比正常视频要低好几倍）。所以最终你在底层会看到相同的或者不同的摄像头采集的原始数据没有任何规律的堆叠在一起，这个可以FAT32的碎片多的多，FAT32是以簇为单位写入，不好意思这个奇盾的方案中最小写入单位是字节级……

好了还是不要吐槽了，要不然根本写不完。经过分析后得到了奇盾的解决方案，下边就是设计程序算法，并进行提取了。请原谅我又想要吐槽（甚至有一种想骂娘的冲动),一种方案的确定最起码应该平衡吧，而不是光侧重于某一点，让人痛心的是这个奇盾的底层存储设计人员更多关注的是如何节省存储空间，现在问题来了，空间是节省了不假，但是由于多个碎片堆叠在一起，想要剥离就会消耗更多的CPU资源。同样，在底层恢复时除了定位碎片时消耗的时间，还要在分离 重组碎片上投入更多的时间，所以奇盾在恢复时速度是不会快的（只考虑底层恢复，不考虑索引正常的情况。相对比海康的方案，奇盾在恢复时所花的时间有是海康的近2倍甚至更多）。

故障处理：

吐槽了这么多，还是开始恢复吧，设计好算法后。运行万能监控恢复工具，选择第8个奇盾然后开始扫描.在花了近20多个小时后成功发现了所需要的时间段。