我们在戴尔媒体库中有一个 LTO-3 磁带驱动器，用于磁带备份。文章维基百科上关于 LTO 的说明如下：
LTO 使用自动写入后验证技术，在写入数据时立即对其进行检查，但有些备份系统会明确执行完全独立的磁带读取操作，以验证磁带是否正确写入。这种单独的验证操作使每次计划备份的端到端传递次数加倍，并将磁带寿命缩短一半。
我想知道的是，我是否需要我的备份软件（在本例中是 Backup Exec）对这些磁带执行验证，或者 LTO 驱动器固有的写入后验证技术是否足够？
我也很好奇 Backup Exec 是否足够了解写入后验证技术，以便在该技术无法验证数据时提醒我，或者它是否会忽略它，使其变得毫无用处，因为即使驱动器检测到问题，我也永远不会知道。
答案1
好问题！
虽然我认为你应该测试它们，但我认为测试磁带/驱动器本身很重要，更重要的是测试端到端恢复过程。
我极力推荐定期进行完整的系统恢复和服务测试，这是唯一能知道的方法一定整个系统都在按照您购买它的目的运行。您无需在这个网站上多看几眼就能看到，有些人虽然认为自己已经完成了所有步骤，但仍在努力恢复服务。
希望这可以帮助。
答案2
首先，这种自动验证不能替代端到端验证。我曾见过驱动器附带固件错误，导致恢复读取的可靠性低于验证读取。
结果是，您可以写入磁带而不会报告任何错误，但是在尝试恢复时，您会看到读取出现错误或速度下降几个数量级。
大多数客户从未注意到这个固件错误。据供应商称，这是因为客户实际上没有执行测试恢复。这个特定的错误已经修复。但我敢肯定，我们还没有看到最后一个固件错误，而且有些固件错误只有在实际测试实际读取时才会被发现。
当验证失败时，固件会自动写入第二份副本（并且在恢复期间，固件会透明地向主机返回两份副本中的一份）。这意味着可用容量取决于驱动器的健康状况和介质质量。
如果在验证读取过程中有太多写入尝试失败，则会在 SCSI 级别报告错误。人们会认为以这种方式报告的错误在软件层很难被忽略，但众所周知，仅由不稳定的硬件触发的代码路径中的错误很难测试。