ドライブ自体が書き込み時に検証を実行する場合でも、LTOテープバックアップで検証を実行する必要がありますか？

デルのメディアライブラリには、テープバックアップに使用するLTO-3テープドライブがあります。記事ウィキペディア上のLTOについては、と述べています：

LTOでは、書き込み後の自動検証テクノロジーを使用して、書き込み中のデータをすぐにチェックしますが、一部のバックアップシステムでは、完全に別個のテープ読み取り操作を明示的に実行して、テープが正しく書き込まれたことを確認します。この個別の検証操作により、スケジュールされた各バックアップのエンドツーエンドパスの数が2倍になり、テープの寿命が半分になります。

私が知りたいのは、これらのテープで検証を実行するためにバックアップソフトウェア（この場合はBackup Exec）が必要ですか、またはLTOドライブに固有の書き込み後検証テクノロジで十分ですか？

Backup Execが書き込み後検証テクノロジを理解していて、そのテクノロジがデータを非常に具体化できないか、無視しても問題ない場合は、ドライブが問題を検出したとしても、私が絶対に問題を検出しなかったとしても警告するのに十分興味があるそれについて知っています。

すばらしい質問です。

確かにそれらをテストする必要があると言いますが、テープ/ドライブ自体をテストすることは、エンドツーエンドの復元プロセスをテストすることの方がはるかに重要です。

十分な定期的な完全なシステムの復元とサービスのテストをお勧めすることはできません。これは、システム全体が購入したものを実行していることを確認する唯一の方法です。すべてのステップを個別にカバーしたと思っていたとしても、サービスを復元するのに苦労している人々を確認するために、このサイトを遠くまで見る必要はありません。

お役に立てれば。

まず、この自動検証は、エンドツーエンドの検証に代わるものではありません。ドライブにファームウェアのバグが付属しており、復元の読み取りが検証の読み取りよりも信頼性が低くなるのを見ました。

その結果、エラーは報告されずにテープに書き込むことができましたが、復元しようとすると、読み取りエラーが発生したり、速度が数桁低下したりします。

ほとんどのお客様は、このファームウェアのバグに気づいていません。ベンダーによると、顧客が実際にテストリストアを実行しなかったためです。この特定のバグは修正されました。しかし、最後のファームウェアのバグを見たことはないと思います。実際の読み取りを実際にテストした場合にのみ、一部のファームウェアのバグが発見されます。

検証が失敗すると、ファームウェアは自動的に2番目のコピーを書き込みます（そして、復元中に、ファームウェアはホストに透過的に返され、2つのコピーのうち1つだけが返されます）。つまり、使用可能な容量は、ドライブの状態とメディアの品質によって異なります。

検証読み取りで失敗した書き込み試行が多すぎると、SCSIレベルでエラーが報告されます。この方法で報告されたエラーはソフトウェアレイヤーで見逃すのは難しいと思いますが、不安定なハードウェアによってのみトリガーされるコードパスのバグをテストすることは非常に困難です。