これが私の状況です。
Dell Perc 7iコントローラ(LSIコントローラ)を搭載したDellサーバーがあります。
ドライブに故障予測の警告を出すようにしていたので、サポートに連絡して、ドライブを交換してアレイを再構築しましたが、かなり標準的なものでした。
2週間後、別のドライブで「障害が予測されました」という警告が表示されます。ドライブや偶然の不良などが原因であると考えたので、サポートに連絡して詳細を調べます。故障していない他のドライブの1つに不良ブロックがあり、それらの不良ブロックは再構築中にコピーされたことがわかりました。だから今私はいたるところに不良ブロックを持っていて、それらはゆっくりと私のアレイを殺しています。これがパンクチャドアレイと呼ばれることに気づきました。
したがって、彼らのアドバイスは、すべてのドライブを交換し、アレイを再構築し、バックアップから復元することでした。数週間この問題が発生していることを除いて、バックアップが不良であることを意味します...以前(1か月前)のバックアップから復元すると、データベースから約4週間分のデータが失われます。私たちのオフィスにはまったく受け入れられません。
私の質問は...データを失うことなく、または全体(ウィンドウの外に出し、最初からやり直す)アプローチなしに、このような何かから回復した人はいますか?
私のシナリオをカバーするリンクが1つ見つかりました。状況に光が当てられているかどうかは不明です。 http://www.theprojectbot.com/raid/what-is-a-punctured-raid-array/
どんな助けや指示もいただければ幸いです!皆さんはどう思いますか?
私の想定するシステムはまだ稼働しているので、最善の方法はimmediateバックアップを作成し、ディスク/アレイをダンプし、バックアップから再構築して復元することです。
不良ブロックは、常にバックアップが悪いことを意味するわけではありません。パフォーマンスの問題やファイルの損傷を経験していない場合でも、バックアップは、復元を完了するのに十分なものであるはずです。
テストするには、最新のバックアップを取り、最も重要なデータを調べます。それでも問題がない場合は、おそらく適切なバックアップがあります。
この時点では、バックアップが適切であるか、バックアップしてもファイルが失われないことを100%確信できないため、リスクが伴います。ただし、アレイwillは最終的に失敗し、とにかく復元を強制するため、これが唯一の実際のオプションです。
この瞬間、次のようにします。
うまくいけば、ディスクはデータが完全であるほど十分良好であり、新しい完全バックアップの実行で問題が発生することはありません。
次に、それらのディスクをスクラップし、新しいRAIDアレイを構築します。準備ができたら、今作成したバックアップから復元してみてください。運が良ければ、それで十分です。
それが失敗した場合は、次に古いものを試してみてください。システムが機能するかどうかを必ずテストしてください。起動したからといって、システムが完全に機能しているわけではありません。特に、データベースの破損をテストします。
古いバックアップからシステム全体を復元する必要がある場合は、問題ありません。最新のバックアップを取り、データベースファイルと他の重要なファイルのみを復元します。それらをテストして、正しく機能することを確認します。繰り返しになりますが、失敗した場合は、次に古いものを試してください。
このプロセスを使用すると、データの損失が最小限に抑えられます。
GrantとNathan Cによって提供された回答は、バックアップ/復元の処理、およびデータの整合性への対処においてどのように進めるべきかに関して素晴らしいものです。
仮想ディスクを再作成してバックアップから復元するときにRAIDセットを処理する方法について、より明確な詳細を以下に示します。
注:RAID5を使用している場合は、 深刻に 今回はRAID6の使用を検討してください。 RAID5は、このサイズのアレイに対する現在の業界標準のベストプラクティスに従って、ビジネスクリティカルなデータに対して信頼性がありません。大容量のSATA/NL-SASディスクは、再構築中にUREに遭遇するリスクが高く、その結果、処理しているようなパンクが発生します。 RAID6はこのリスクを大幅に軽減し、現在利用可能なドライブ容量を備えた重要なデータには一般的に受け入れられます。