流媒体存储服务器阵列缺盘64TB多媒体文件的修复方法

伴随着各种存储技术的发展，现在很多场景都开始切换到“无纸化”的处理方式，包括一些音视频频的场景，通过对现场声音、画面的数字化采集、推流、转码存储来实现和传统存储方式的升级。今天来看一下某企业64TB存储设备阵列崩溃后多媒体文件的修复方法。

故障存储:

64TB存储服务器/文件系统:ext4

故障现象:

该存储服务器使用RAID5阵列来实现数据冗余，是一台较老旧的存储设备，后期由于三块盘的离线导致整个阵列崩溃。存储服务器主要保存流媒体文件，数据量大约在60TB左右。恢复要求：最大化恢复要求多媒体文件可以正常解码播放。

故障分析:

在开始分析前先对RAID5做个简单的介绍:

RAID5 应该是应该是目前最常见的 RAID 等级，它的原理与 RAID4 相似，区别在于校验数据分布在阵列中的所有磁盘上，而没有采用专门的校验磁盘，对于数据和校验数据，它们的写操作可以同时发生在完全不同的磁盘上。因此，RAID5 不存在 RAID4 中的并发写操作时的校验盘性能瓶颈问题。另外，RAID5 还具备很好的扩展性。

声明一下以上信息是AI说的，和本人无关。总结来看RAID5就是通过把校验块P动态分布在每个条带中从而达到安全冗余，其允许离线的磁盘数量为1，从图1中可以看到，在缺少1块盘的情况下，RAID管理程序可以通过校验块和数据块异或得到缺失的数据块。

图1：RAID5的基本原理图(P为校验块)

本例中由于缺失三盘导致RAID5阵列崩溃，其中两块盘损坏严重无恢复可能，有一块盘则通过更换磁头成功恢复，最后的情况就是整个阵列缺失了两块盘。而RAID5最高要求是允许一块盘离线，所以最终阵列缺少一块磁盘。

通过分析阵列信息并找一块空盘补齐阵列，根据RAID5的原理图得知在少一块盘的情况下，每个条带都会出现缺失，这就导致数据会出现异常。所以获取完整数据是不切实际的，最后经过扫描恢复得到了目录信息。当然恢复后的多媒体文件基本上无法播放，这个和客户的要求大相径庭，所以需要进入下一步修复的环节。

故障处理:

经过沟通发现这是一个相对比较复杂的场景，存在多路视频、麦克风等采集设备，这些原始数字信息采集后先交付音频处理设备进行画面和声音编码，然后以RTP网络推流的形式传送到存储服务器进行保存（类似于图2），最终的多媒体文件使用mp4结构进行“封装”打包。

图2：复杂的应用场景

分析mp4文件发现是多路复用的情况，这个也比较符合网络推流的特征，视频编码使用avc音频则是

aac。通过和音频处理设备厂商沟通确定了其使用的方案为RTP推流，再结合样本文件的分析发现其

音频编码结构略显特殊，这就导致常规的恢复方法可能无效，测试后发现确实如此。使用高级版修复

的文件仅有画面，但是却没有声音。毕竟阵列条带中缺失了数据块所以画面解码时会存在马赛克等异常

情况，经过客户查看后表示可以接受，不过另一个要求则是修复音频部分并实现画面和声音“同步”。

图3：多路复用的文件结构

经过对比不同的样本文件发现不少文件的音频编码部分差异比较大，经过和客户沟通证实存在设备上的升级，也就是说负责编码的设备实际上版本有差异，有的比较老有的比较新，新旧交叉共同存在。

总结下当前面临三大难题:

1. 特殊的音频编码
2. 编码设备版本差异导致的编码混乱
3. 由于RTP带来的修复后画面和声音的“同步”难题

好吧，问题很多，一点点解决。先来了解下RTP：

RTP（real-time transport protocol），实时传输协议。RTP在多点传送（多播）或单点传送（单播）的网络服务上，提供端对端的网络传输功能，适合应用程序传输实时数据，如：音频，视频或者仿真数据。RTP没有为实时服务提供资源预留的功能，也不能保证QoS（服务质量）。数据传输功能由一个控制协议（RTCP）来扩展，通过扩展，可以用一种方式对数据传输进行监测控制，该协议（RTCP）可以升级到大型的多点传送（多播）网络，并提供最小限度的控制和鉴别功能。RTP和RTCP被设计成和下面的传输层和网络层无关。协议支持RTP标准的转换器和混合器的使用……

以上信息来源于AI，总结下RTP是一种流媒体传输协议，是协议肯定就有标准，需要传输则肯定存在校验，从这两点考虑重新分析mp4文件果然有了一些收获。Mp4中的四路trak中，有两路就是RTP信息，并且它们和音视频编码是交叉存储，好吧修复音频的思路马上就有了！

剩下的事情就是研究RTP了，多挖一些有利于修复的东西，经过不断的恶补RTP，最后确定了修复方法并尝试着去用代码实现，最后的效果还是可以的。好了，1和2两个难题成功解决。最后的难题就是“同步”问题了，这一类网络推流就是把数据块切割，在推流时系统是清楚不同流的单独时长的，所以大多数使用的是动态时长，所谓的同步就是：

同一时间轴，解码器同时解码画面和声音（虽然实际上解码过程是异步但至少人感官上是同步的）。

现在的问题就是声音原来使用的是动态时长，但是由于文件结构的损坏我们已经无法得到每个音频块的时长了，这就导致解码时画面播放停止了，而声音还在继续解码。大多数情况下mp4文件的画面速率就是总速率，声音一般是参考这个速率，就和地球绕太阳公转一个道理，那能反过来太阳绕地球转吗？天体当然不可以，但是在修复中是可以的，有时候解决难题只需要转换下思路！

好了，有了解决问题的具体方法，剩下就是付诸于实践，经过长时间代码调试，最后终于成功解决了所有问题。测试后效果非常之好，客户极其满意。由于文件数量较多，只能是“蚂蚁搬家”的方式来一点点修复。

图4：部分文件修复效果

这就是流媒体存储服务器阵列缺盘64TB多媒体文件的修复方法，大家在遇到此类问题时，可以和CHS数据实验室联系！