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

Question

我们有一个LTO-3磁带驱动器在戴尔媒体库，我们使用我们的磁带备份。维基百科上关于LTO的文章声明：

LTO使用自动验证后写入技术立即检查正在写入的数据，但一些备份系统显式地执行完全独立的磁带读取操作，以验证磁带是否正确写入。这种单独的验证操作会使每个预定备份的端到端传递次数加倍，并将磁带的使用寿命减少一半。

我想知道的是，我是否需要我的备份软件(在本例中是备份Exec )在这些磁带上执行验证，还是LTO驱动器中固有的验证后写入技术足够了？

。

我也会好奇，如果备份Exec理解验证后写入技术足够提醒我，如果该技术无法验证数据，或者它只是忽略它，使它毫无用处，因为即使驱动器发现了一个问题，我永远不会知道它。

Answer 1

问得好！

虽然我会说是的，你应该测试他们，我会说，测试磁带/驱动器本身是重要的，更重要的是测试端到端的恢复过程。

我不能推荐足够的定期完整的系统修复和服务测试，这是唯一的方法，以确保整个系统是做什么，你买它的。你不必在这个网站上看很久就能看到那些很难恢复他们的服务的人，即使他们认为他们已经单独完成了所有的步骤。

希望这能有所帮助。

Answer 2

首先，这种自动验证不能取代端到端的验证。我见过一个固件错误附带的驱动器，导致恢复读取比验证读取更不可靠。

其结果是，您可以编写磁带而不报告任何错误，但是在试图恢复时，您会看到读取错误或速度下降了几个数量级。

大多数客户从未注意到这个固件错误。根据供应商的说法，因为客户实际上没有执行测试恢复。这个窃听器被修好了。但是我相信我们还没有看到最后的固件错误，只有当你真正测试真实的读取时，才会发现一些固件错误。

当验证失败时，固件会自动写入第二个副本(并且在将固件透明地还原到主机期间，只返回两个副本中的一个)。这意味着可用容量取决于驱动器的健康和媒体质量。

如果过多的写入尝试在验证中失败，则会在SCSI级别报告错误。人们可能会认为这样的错误报告在软件层是很难忽略的，但是代码路径中只由片状硬件触发的but是出了名的很难测试。