ファイバーチャネル：バスリセット時に上書きされたLTOテープ
私がもっとよく理解したいという状況があります。
何が起こったのか：
- LTOテープドライブを備えたライブラリがファイバーチャネル環境に接続されている
- Windows Server 2008で実行されているアーカイブソフトウェアは、テープにデータを書き込んでいます
- ある時点で、ソフトウェアがそれを認識せずにテープが巻き戻され、書き込みによってテープが消去されました
- テープ上の予想位置と実際の位置を比較することで状況を検出しました
機器のベンダーについての詳細はわかりません。
テープドライブでリセットが発生したためにテープが巻き戻されたようですが、その状況はドライバとソフトウェアにエラーとして報告されなかったため、ソフトウェアは書き込みが成功したと見なしました。
これが発生した理由を理解するために多くのドキュメントを読んでいましたが、お客様を支援するための最終的な結論を出すことはできません。
- FC HBAまたはスイッチ自体でSCSI書き込みオンバスリセットを再送信できますか？
- このようなものを構成できますか？
- FC HBAまたはスイッチは、報告されたユニットアテンションを無視しましたか？
- OSドライバーのせいにすることはできますか？
- このベンダーは特定ですか？
誰かが私に続行するためのいくつかの指示を提供してくれれば、私は非常にありがたいです。
これはテープドライブの既知の問題であり、デバイスを横から見るだけで簡単に巻き戻すことができます（つまり、巻き戻しデバイスを介して間違った方法で開くと、ステータスを確認するなど）。
UNIXバックアップソフトウェアの少なくとも1つの主要な部分がこれを非常に心配しているため、テープを消去する準備ができるまで、テープへの2回目の書き込みを拒否するだけです。これは アマンダFAQ （バスのリセットを問題領域として具体的に言及しています）：
なぜアマンダはテープに追加しないのですか？
アマンダの1回の実行= 1本（セット）のテープ。 Amandaはテープデバイスを1回開き、すべての画像とファイルマークを書き込み、デバイスを1回閉じます。そのシーケンスを使用すると、他のプログラムがシーケンスを中断して、アマンダに気付かれずにテープを巻き戻す可能性はありません。
「mt-f/dev/st0 status」を実行するだけで十分な場合もあれば、「amcheckdaily」を実行する場合もあります。 また、scsiバスのリセットなどのエラーは巻き戻しを意味します。
Amandaがバックアップイメージごとにテープドライブを閉じて再度開くと、テープが誤って巻き戻されるという脆弱性のウィンドウがあり、次のイメージがテープ上のすべての適切なバックアップを上書きします。そして、テープから復元しようとしない限り、あなたは知りません。
テープに追加する場合、アマンダが最後の画像に配置してから（すでに簡単ではありません！）、書き込み用にデバイスを開くまでの間に、テープの巻き戻しが発生する可能性があります。その場合、アマンダはおそらく何日にもわたるバックアップを含む、すべてのテープを喜んで消去します。
Baculaも同様に、テープデバイスを決して閉じないことでこの問題に対処しているため、テープがロードされている間、他の誰も誤ってテープデバイスを開くことはできません。しかし、それはバスリセットの問題を回避しません。
本質的に、これは問題であり、難しい問題です。バックアップハードウェアは、これらが頻繁に発生しないように十分に堅固である必要があると私は主張するかもしれません。 FCが特にこれらの傾向があると思われる場合は、代わりにSASテープドライブを入手するか、少なくとも直接-テープデバイスをバックアップサーバーに接続して、ファイバースイッチなどをバックアップサーバーから削除します。パス。それ以外は、通常のポイントの前に問題をキャッチしたため、つまり「復元が機能しない、私たちはねじ込み」。