我们在戴尔媒体库中安装了一个LTO-3磁带机，用于磁带备份。 关于维基百科LTO的文章指出：
LTO使用自动validation后写技术在数据写入时立即检查数据，但一些备份系统显式执行完全独立的磁带读取操作，以validation磁带是否正确写入。 这种单独的validation操作将每个计划备份的端到端通道数加倍，并将磁带寿命缩短一半。
我想知道的是，是否需要我的备份软件（在这种情况下为Backup Exec）在这些磁带上执行validation，或者LTO驱动器中固有的validation – 写入后技术是否足够？
如果Backup Exec了解写后validation技术足以提醒我该技术是否能够使数据无法处理，或者是否忽略该技术使其毫无用处，那么我也会很好奇，因为即使驱动器检测到问题，我也绝不会知道这件事。
好问题！
虽然我会说是的你应该testing它们，但是我认为testing磁带/驱动器本身是非常重要的，testing端到端恢复过程更重要。
我不能推荐足够的定期全面系统修复和服务testing，只有这样才能确定整个系统正在为您购买它做什么。 你不必在这个网站上远看，即使他们认为自己已经全部覆盖了所有的步骤，但仍然看到那些努力恢复服务的人。
希望这可以帮助。
首先，这种自动validation不能替代端到端的validation。 我看到驱动器出现固件错误，导致恢复读取比validation阅读不可靠。
其结果是你可以写出没有任何错误报告的磁带，但试图恢复时，你会看到读取错误或速度下降了几个数量级。
大多数客户从未注意到这个固件错误 根据供应商，因为客户实际上没有执行testing恢复。 这个特定的bug已经修复。 但是我相信我们还没有看到最后一个固件错误，只有当你真正testing了真正的读取时才会发现一些固件错误。
validation失败时会发生什么情况是固件会自动写入第二个副本（并且在将固件透明地还原到主机时，只会返回两个副本中的一个副本）。 这意味着可用容量取决于驱动器运行状况和媒体质量。
如果在validation读取中写入尝试次数过多，则会在SCSI级别报告错误。 人们会认为用这种方式报告的错误在软件层是不容错过的，但是仅由片状硬件触发的代码path中的错误是众所周知的难以testing的。