私は、ソフトウェアがロードされ、評価のために潜在顧客に送られるシステムのプールを管理していますが、その際にドライブに機密情報が保存されることがよくあります。通常、返送する前に、ドライブをクリーンアップするために標準のワイプを実行することを希望します。ほとんどの人は DBAN に精通しているので、自分のシステムでそれが機能することを確認するようにしています。残念ながら、これは通常、RAID ドライバー地獄に陥り、市場に出回っているバージョンが自分のシステムに付属しているものをサポートしているかどうかを確認しようとしていることを意味します。これらは、さまざまな種類の 3ware および LSI のものです。
その結果、一部のマシンでは DBAN 1.0.7 が動作し、他のマシンでは 2.0 のベータ版が動作し、最新の SSD ベースのマシンでは 2.2.6 が動作しています。現在、IBM x3550 M3 (1064/1068) の LSI コントローラーでは、まったく役に立ちません。
解決策はありますか? DBAN でルートを構築し、ドライバーをつなぎ合わせてみますか? 最新の状態に保たれている無料または商用のその他のツールはありますか。私は、さまざまな技術力を持つ人々にこれを説明しようとしているので、簡単な選択肢のあるブート ディスクが望ましいです。
答え1
現在、ドライブを消去するために機械的な破壊を使用していますが、ドライブを再利用する必要はありません。
特定のセキュリティ/監査標準をターゲットにしていない場合は、Linux ブート CD を使用して、単に /dev/random をドライブに書き込む方が成功する可能性が高いでしょう。
別のオプションとしては、（アプリケーションに応じて）ファイルシステム レベルでドライブを暗号化し、顧客がドライブを引き渡すときにボリューム キーを変更してもらうという方法があります。
答え2
当社も DBAN を使用しています。RAID ドライバーは忘れてください。Dell サーバーでは RAID を破壊し、各物理ディスクを独自の RAID 0 (RAID 0 ごとに 1 つのディスク) に割り当てました。DBAN は各ディスクを検出し、すべてを消去しました。もう 1 つの (おそらく最善の) オプションは、ディスクなしでデバイスを返送してもらい、顧客が独自の基準に従って処分できるようにすることです。これにより、責任から解放されます。
編集: 質問をもう一度読みましたが、これらは評価用であることに気付きました。顧客がデモ用のみであることを理解している限り、コストを抑えるために安価なニアライン SAS または SATA ドライブを使用しても問題ないかもしれません。
答え3
DBAN 1.07/2.2.6 でも同様の問題がありました。時間に余裕があったので、buildroot 2012.05 + disknukem (github の Paolo Iannelli による dwipe のさらなる開発) の i686 および x86_64 汎用バージョンを作成しました。また、sg3_utils、sdparm も追加し、lsiutil 1.63 のソース コードも見つけたので、それも含まれています (たとえば、RAID ボリュームの書き込みキャッシュを有効にしたい場合など)。64 ビット バージョンは、次の場所から入手できます。http://www.cs.helsinki.fi/u/mcrantan/dban/dwipe-bzImage-x86_64少なくとも Cisco B シリーズ ブレードおよび qemu で動作します。
古い話題に答えて申し訳ありません (嫌われることもあると聞きます)。