目录
环境信息
某证券营业部，后端12TB HDS存储LUN，挂载给RH9，并创建EXT4文件系统，存储证券用户的开户视频认证mp4文件，单个视频文件从500KB-50MB。故障前存储数据量约2TB。
故障原因
在数据存储目录，误执行了rm * -rf命令，发现误操作后立即中止，仍然删除了约70GB数据，之后又写入了约20GB新的视频文件。
本次需要恢复2018-2019的6000个柜台营业员+用户的合成视频，数据量约6GB。
恢复过程
客户在联系数联体前，已经找另一家数据恢复公司尝试过扫描恢复，但其扫描恢复出的1000多个无名视频文件，均不是客户需要恢复的视频，恢复失败。
接到本案后，与客户充分沟通了环境信息，和故障前后的操作，判断已经不能用常规方案扫描LUN，因为扫描一次需要2-4天，没有必要再尝试一次。
- 分析12TB LUN的数据组成：
大量视频文件，均为MP4，但格式各异，有前期未处理的原始视频，有处理过程中的视频，有拼接后的视频
小部分其它文件
- 分析目标MP4特性。因为证券公司的MP4视频是内部软件合成，与常规视频文件有差别。此处为重点：
打开一个客户定制的MP4文件，解析出其头部固定特性：
解析出其特殊尾部特征：
以上信息将索引出12TB LUN中所有视频文件，总数据量达2TB，如此海量目标是无意义的。我们必须缩小范围，客户要恢复目标视频有固定分辨率是640x240。本案例的视频信息采用Big Endian编码，在avc1字段，分别存储了视频宽度和高度，下图中0x0280和0x00F0，即表示为640x240：
按以上规则定制搜索规则，即可搜索出640x240分辨率的所有视频，且均为目标视频，大约2万个，以下为部分测试数据展示：
但以上办法恢复出的2万个视频，仍没有文件名，客户无法直接用于业务系统。
好在客户的数据库运行正常，用户开户的身份证高清照均有保存，因此我们再采用python的OpenCV视频流+图片识别，将视频中的客户区域与所有客户的照片库做对比，成功将视频文件的约90%还原为正确的文件名。以下为部分代码展示：
因图片与视频差另过大，导致剩下约10%无法识别的视频 ，采用人工听视频客户的自我介绍，也在1个工作日后全部匹配成功。
本次恢复完成。
特别注意
核心数据恢复，需要深刻理解客户环境，充分调动一切资源，并定制开发专用程序，才能最大程度挽回损失。
技术支持
直接技术支持：shop396558956.taobao.com