Googleはハードドライブの障害について 非常に徹底的な調査 を行い、ハードドライブのかなりの部分が大量の使用の最初の3か月以内に失敗することを発見しました。
私の同僚と私は、すべての新しいハードドライブにバーンインプロセスを実装して、テストされていない新しいドライブで時間を失うことによる心痛を軽減できると考えています。しかし、バーンインプロセスを実装する前に、より経験のある他の人からいくつかの洞察を得たいと思います。
編集:ビジネスの性質上、RAIDはほとんどの場合使用できません。全国に頻繁に郵送される単一のドライブに依存する必要があります。できるだけ早くドライブをバックアップしますが、データをバックアップする機会が得られる前に、あちこちで障害が発生します。
私の会社はここしばらくの間バーンインプロセスを実装しており、非常に有用であることが証明されています。在庫にあるすべての新しいドライブをすぐに焼き付けるため、保証期間が切れる前、および新しいコンピューターシステムにインストールする前に、多くのエラーを見つけることができます。ドライブが故障したことを確認することも有用であることが証明されています。コンピュータの1つでエラーが発生し始め、ハードドライブが主な疑いがある場合は、そのドライブでバーンインプロセスを再実行し、RMAプロセスを開始またはスローする前に、ドライブに問題があるかどうかを確認します。ゴミ箱に入れます。
バーンインプロセスは簡単です。多数のSATAポートを備えた指定されたUbuntuシステムがあり、各ドライブに4つのパスがある読み取り/書き込みモードで不良ブロックを実行しています。話を簡単にするために、「データはすべてのドライブから削除されます」という警告を出力し、システムドライブを除くすべてのドライブで不良ブロックを実行するスクリプトを作成しました。
使用を開始する前にハードドライブに書き込むことはどのくらい重要ですか?
優れたバックアップと優れた高可用性システムがあれば、それほど多くはありません。障害からの復元はかなり簡単なはずです。
バーンインプロセスはどのように実装しますか?ドライブを焼き付けるためにどのソフトウェアを使用しますか?バーンインプロセスにはどのくらいのストレスがかかりすぎますか?
私は通常、それを取得したときにドライブまたは新しいシステムに対して badblocks を実行します。予備の山からコンピューターを復活させるときはいつでもそれを実行します。このようなコマンド(badblocks -c 2048 -sw /dev/sde
)は実際には、異なるパターン(0xaa、0x55、0xff、0x00)で毎回すべてのブロックに4回書き込みます。このテストは、多くのランダムな読み取り/書き込みをテストするためには何もしませんが、すべてのブロックも書き込みおよび読み取りできることを証明する必要があります。
ベンチマークツールである bonnie ++ または iometer を実行することもできます。これらはドライブに少しストレスを加えようとするはずです。ドライブを最大にしようとしても、ドライブが故障することはありません。だからあなたは彼らが何ができるかを見てみるのもよいでしょう。私はこれをしません。ストレージシステムのI/Oベンチマークをインストール/セットアップ時に正しく取得すると、将来、パフォーマンスの問題を調べるときに非常に役立つ場合があります。
どのくらいの期間ハードドライブに書き込みますか?
私の考えでは、バッドブロックを1回実行するだけで十分ですが、非常に強力なバックアップシステムがあり、HAのニーズはそれほど高くないと思います。サポートしているほとんどのシステムでサービスを復元するために、ある程度のダウンタイムを許容できます。マルチパスセットアップが必要になると思うほど心配している場合は、おそらくRAID、適切なバックアップ、適切なHAセットアップが必要です。
ラッシュにいる場合、バーンインをスキップできます。私のバックアップとRAIDは問題ないはずです。
IMNSHO、不良ドライブを取り除き、データを「保護」するためにバーンインプロセスに依存するべきではありません。この手順の開発と実装には時間がかかるため、他の場所でより適切に使用でき、ドライブがバーンインに合格しても、数か月後に失敗する可能性があります。
データを保護するには、RAIDとバックアップを使用する必要があります。それが整ったら、ドライブについて心配しましょう。優れたRAIDコントローラとストレージサブシステムには、データを頻繁に調べてすべてが良好であることを保証する「スクラビング」プロセスがあります。
すべてが処理されたら、ディスクスクラブを実行する必要はありませんが、他の人が述べたように、システム負荷テストを実行してすべてが期待どおりに機能していることを確認しても問題はありません。個々のディスクについてはまったく気にしません。
コメントで述べたように、特定のユースケースでハードドライブを使用することはあまり意味がありません。それらを配送すると、バーンインを実行したときにそこにないデータエラーが発生する可能性がはるかに高くなります。
テープメディアは、出荷されるように設計されています。単一のIBM TS1140ドライブで250MBps(または最大650MBps圧縮)を取得できます。これは、ハードドライブよりも高速です。さらに大きい-1つのカートリッジで最大4TB(非圧縮)が得られます。
テープを使用したくない場合は、SSDを使用してください。それらはHDDよりもはるかに粗く扱うことができ、これまでに指定したすべての要件を満たします。
結局のところ、これがあなたの質問に対する私の答えです。
shred
とbadblocks
を実行するだけで十分です。後でSMARTデータを確認してください。あなたの説明を考えると、バーンインプロセスがあなたにとって何の役にも立たないように思えます。ドライブは主に機械的要因、通常は熱と振動が原因で故障します。隠れた時限爆弾のせいではありません。 「バーンイン」プロセスは、他の何よりもインストール環境をテストします。移動すると、元の場所に戻ります。
しかし、ここにあなたを助けるかもしれないいくつかの指針があります:
ラップトップドライブは通常、デスクトップドライブよりも大きな振動や振動に耐えるように設計されています。そのため、データリカバリーショップで働いている私の友人は、常にラップトップドライブでクライアントにデータを発送しています。私はこの事実をテストしたことがありませんが、一部の業界では「常識」のようです。
フラッシュドライブ(USBサムドライブなど)は、あらゆるメディアの中で最も衝撃に強いものです。フラッシュメディアを使用すると、転送中にデータが失われる可能性がさらに低くなります。
Winchesterドライブを出荷する場合は、使用する前に表面スキャンを行ってください。さらに良いことに、単にしないでください使用してください。代わりに、特定のドライブを「シッピング」ドライブとして指定することもできます。これは、すべての不正行為を認識しますが、データの整合性には依存しません。 (つまり、ドライブにデータをコピーして発送し、発送後にコピーし、両面に非常にチェックサムを付けるなど)。
基本的に「バーンインを気にしないで、適切なバックアップをとる」というすべての回答には同意しません。
バックアップは常に必要ですが、システムはバーンインされていないドライブで実行されていたため、昨日(通常の10時間シフトに加えて)9時間をバックアップからの復元に費やしました。
RAIDZ2構成(RAID-6に相当するZFS)には6台のドライブがあり、約45日間稼働していたボックスで18時間の間に3台のドライブが停止しました。
私が見つけた最良の解決策は、特定の製造元からドライブを購入し(ミックスアンドマッチしないでください)、ドライブを実行するために提供されているツールを実行することです。
私たちの場合、Western Digitalを購入し、起動可能なISOからDOSベースのドライブ診断を使用します。起動して、ランダムなゴミをディスク全体に書き込むオプションを実行してから、短いSMARTテストを実行してから、長いSMARTテストを実行します。通常はすべての不良セクターを取り除き、再割り当てを読み書きするのに十分です...
一度に8つのドライブに対して実行できるように、それを「バッチ処理」する適切な方法をまだ探しています。 Linuxでは「dd if =/dev/urandom of =/dev/whatever」または「badblocks」を使用するだけかもしれません。
編集:私はそれを「バッチ」するより良い方法を見つけました。私はようやく、特定のニーズに対処するためにネットワーク上にPXEブートサーバーをセットアップすることに取り掛かり、Ultimate Boot CDをPXEブートできることに気付きました。現在、ドライブ診断を実行するためにPXEで起動できる少数のジャンクマシンが配置されています。
あなたのプロセスは間違っています。 RAID配列を使用する必要があります。私が働いている場所では、持ち運びができるように設計された頑丈なレイドアレイを作りました。それはロケット科学ではありません。大きなゴム製防振装置を備えた特大のエンクロージャにドライブを衝撃マウントすると、信頼性が大幅に向上します。 (Seagate constellation-esドライブは、例として300G衝撃の定格ですが、動作していない2G振動のみです。そのため、出荷ケースはドライブを振動分離する必要があります。 http://www.novibes.com/Products&productID = 62 または http://www.novibes.com/Products&productId=49 [part#50178])
ただし、実際にテスト用ハードドライブを書き込みたいので、ここに移動します。
私はハードドライブのようなシステムで作業し、いくつかの問題を見つけましたが...
PCBのライフサイクルテストを加速して障害を引き出すためには、いくつかのホット/コールドサイクルに勝るものはありません。 (ホットコールドサイクルの操作はさらにうまくいきます...しかし、特にHDDのバンクでは、それを行うのは困難です)
一度に取得するドライブの数について、環境チャンバーを大いに活用してください。 (これらはかなり高価です。レイドアレイを出荷する方が安くなります)湿度制御とプログラム可能なランプが必要になるテストチャンバーを無駄にすることはできません。
最小保管温度から最大保管温度までの2つの繰り返し温度ランプでプログラムし、ハードドライブの製造元のアプリケーションエンジニアを混乱させるのに十分な急勾配にします。 12時間で3回のコールドホットサイクルを実行すると、ドライブがすぐに故障するはずです。このようにドライブを少なくとも12時間実行します。その後何か仕事があればびっくりします。
私はこれを考えていませんでした:私が働いた1か所で、生産エンジニアにこれを行ってもらい、同じテスト機器でより多くの製品を出荷しました。テストで大きな欠陥がありましたが、到着率は実際にはゼロ。
使用を開始する前にハードドライブに書き込むことはどれほど重要ですか?
場合によります。
冗長性(1、5、6、10)を提供するRAIDで使用している場合?それほどではありません。
standaoloneを使用している場合?少しですが、少なくとも私の意見では、smartdまたは何かを実行して監視する方が良いでしょう。
これは当然、「バーンインプロセスをどのように実装しますか?」への私の答えにつながります-しません。
ディスクを「焼き付ける」のではなく、冗長ペアで実行し、予測監視(SMARTなど)を使用して、ドライブが不安定になったときに通知します。フルバーンイン(実際にはディスク全体を実行する)に必要な追加の時間は、ディスク障害やスワップアウトを処理するよりもかなり高くつくことがわかりました。
RAIDと適切なバックアップを組み合わせると、乳児の死亡率(または、古いドライブが死に始めたときに浴槽のもう一方の端)を処理する場合でも、データは非常に安全になります。
Spinrite(grc.com)は、ドライブ上のすべてのデータを読み書きします。新しいドライブを故障させるつもりがない場合でも、それを行うのは良いことです。レベル4で実行するには長い時間がかかります。現在のサイズのドライブの場合、通常は数日です。それは非破壊的であることも付け加えておきます。実際、データが悪い場所にある場合、移動して回復します。もちろん、SSDで実行することは決してありません。
1週間に1回のベンチマークとエラーチェックで、ハードドライブの「焼き付き」が十分であると確信しています。あなたの投稿以来、私はそのようなことを聞いたことがありません。
Stroagereview.comの「6_6_6」からの引用
1. Connect the drive to a running system. Read SMART values.
2. Do a SMART short self test. Do a SMART long self-test.
3. Zero fill / Wipe the drive with the manufacturer's utility. Entire drive.
4. Run HDTach full read/write. Everest / Sandra, etc all have stress tests. Run hard drive part continously for hours.
5. Run Victoria for Windows Read/Write test and make sure no slow sectors.
6. Drop to DOS. Run MHDD, run a LBA test and see check for slow sectors. Run Read/Write/Verify test. Run drive internal ATA secure erase command.
7. Do a full format.
8. Compare SMART values. If no anomalies, all good to go. Install your OS and continue.
全体として、個人的にはそれは悪い考えだと思います。
編集:ソース: http://forums.storagereview.com/index.php/topic/27398-new-hdd-burn-in-routines/
まず、私はあなたのユースケースがテープドライブがより良いオプションであると示唆する他のポスターに同意します。
それが不可能な場合は、ドライブを全国に飛ばさなければならない場合、より多くのドライブを輸送する必要があり、障害のリスクが高まるため、真のRAIDは選択肢にはならないようです。ただし、1つのドライブを送信し、もう1つのドライブをソースサイトに保持する単純なミラーリングスキームについてはどうでしょうか。
その後、ドライブが到着時に故障した場合、新しいコピーを作成して送信できます。ドライブが到着時に良好である場合、スペアは再利用できます-元のデータの送信またはバックアップ用。
ドライブが出荷されている理由を実際に述べていません。これはデータを送信するための方法にすぎませんか。完全なアプリケーション/ OSイメージをPCで起動する準備ができているか、それとも何か他のものですか?
ドライブを出荷すると機械的な問題が発生するリスクがあるため、RAIDまたはバックアップはスキャンよりも優れているという他の回答にも同意します。
これを行うより一般的な方法は、「冗長データに依存してエラーをキャッチして修正する」ことです。つまり、データセットごとに2つのドライブを出荷するか、1つのドライブで冗長データを出荷します。 Parchive のようなものを使用すると、定義されたレベルの冗長性をデータに追加して、データの大部分が破損した場合でもリカバリを可能にすることができます。最近のディスクはかなり安いので、必要以上に大きいディスクを購入するだけで、ドライブのスキャン、交換用ドライブの発送、ドライブ2台の発送よりも安くなることがよくあります。
これは、ドライブの致命的でない障害から保護します。ただし、以前に提案したように、出荷時以外は出荷されたドライブを再利用しないことをお勧めします。インストールされており、どこにも出荷されていません。
これにより、大量のデータ(またはアプリケーション/ OSイメージ)を出荷し、ディスクエラーの影響を経済的なレベルにまで減らすことができます。