即使驱动器本身在写入时执行验证，我是否仍需要在LTO磁带备份上运行验证？

我们在Dell媒体库中有一个LTO-3磁带机，用于磁带备份。维基百科上有关LTO 的文章指出：

LTO使用自动写入后验证技术来立即检查正在写入的数据，但是某些备份系统明确执行完全独立的磁带读取操作以验证磁带是否正确写入。这种单独的验证操作使每个计划的备份的端到端通过次数增加了一倍，并将磁带寿命缩短了一半。

我想知道的是，我需要我的备份软件（在这种情况下为Backup Exec）在这些磁带上执行验证吗？还是LTO驱动器固有的写后验证技术足够？

我也很好奇，如果Backup Exec能够充分理解写后验证技术，如果该技术无法验证数据，或者是否会忽略它使它仍然无用，我会发出警报，因为即使驱动器发现了问题，我也永远不会知道这一点。

好问题！

虽然我会说是的，但您应该对其进行测试，但是我要说，对自身的磁带/驱动器进行测试很重要，而对端到端恢复过程进行测试则至关重要。

我不能推荐足够的常规完整系统还原和服务测试，这是唯一确定整个系统在做什么的唯一方法。您不必在此站点上看到很多东西，即使他们认为自己已经单独介绍了所有步骤，却仍在努力恢复他们的服务。

希望这可以帮助。

首先，这种自动验证不能替代端到端验证。我已经看到驱动器带有固件错误，导致恢复读取的可靠性低于验证读取的可靠性。

这样做的结果是，您可以写入磁带而不会报告任何错误，但是在尝试还原时，您会看到读取错误或速度降低了几个数量级。

大多数客户从未注意到此固件错误。根据供应商的说法，因为客户实际上没有执行测试还原。此特定的错误已修复。但是我敢肯定，我们还没有看到最后的固件错误，并且只有当您实际测试实际读取时，才会发现某些固件错误。

验证失败时，固件将自动写入第二个副本（在还原过程中，固件对主机透明地返回两个副本之一）。这意味着可用容量取决于驱动器的运行状况和介质质量。

如果太多写入尝试在验证中失败，则会在SCSI级别报告一个错误。有人会认为，以这种方式报告的错误很难在软件层遗漏，但是众所周知，仅由不稳定的硬件触发的代码路径中的错误很难测试。