☰

RAID 5がクラッシュします...可能な限り保存しようとしています。 [閉じる]

tag-icon • tag-icon mdadm raid5 qnap
RAID 5がクラッシュします...可能な限り保存しようとしています。 [閉じる]

8つのディスクを持つQNAPサーバーがあります。未使用のバックアップ/追加ディスクが2つあります。 （お金があり、最終的に実行中のディスクを交換する必要があることを知っています。）アレイ全体はそれぞれ6 TBの8つのディスクに分散されています...数学...しかし、現在1/3未満が満たされていると確信しています。

QNAPの担当者はこの問題を解決しましたが、デュアルディスクダイビングは回復が不可能な可能性が高いと述べました。担当者が自分に許可された作業/できることが何かを知っていると思います。しかし...

私は人々がこの災害から回復するのを見ました。システムによると、すべてのディスクがそのまま維持されることを願っています。 ？ ？

「無効なマジックナンバー」/「有効なファイルシステムスーパーブロックが見つかりません」エラーが発生しました

表現前後のデバイス診断出力は次のとおりです。

****フォワード****：

RAID metadata found!
UUID:       cccd0319:89c30791:58322cfe:12ed5c64
Level:      raid5
Devices:    8
Name:       md1
Chunk Size: 64K
md Version: 1.0
Creation Time:  Mar 23 11:49:45 2017
Status:     OFFLINE
===============================================================================
 Disk | Device | # | Status |   Last Update Time   | Events | Array State
===============================================================================
   5  /dev/sdl3  0   Active   Apr 28 08:03:55 2019     3927   AAAAA.AA                 
   6  /dev/sdk3  1   Active   Apr 28 08:03:55 2019     3927   AAAAA.AA                 
   7  /dev/sdj3  2   Active   Apr 28 08:03:55 2019     3927   AAAAA.AA                 
 --------------  3  Missing   -------------------------------------------
   9  /dev/sdh3  4   Active   Apr 28 08:03:55 2019     3927   AAAAA.AA                 
  10  /dev/sdg3  5   Active   Apr 23 15:03:27 2019     3515   AAAAAAAA                 
  11  /dev/sdf3  6   Active   Apr 28 08:03:55 2019     3927   AAAAA.AA                 
  12  /dev/sde3  7   Active   Apr 28 08:03:55 2019     3927   AAAAA.AA                 
===============================================================================

****の後ろに****：

RAID metadata found!
UUID:       a6860c7d:0b020f8d:1a61ec72:4684aeb7
Level:      raid5
Devices:    8
Name:       md1
Chunk Size: 64K
md Version: 1.0
Creation Time:  Apr 29 14:08:04 2019
Status:         ONLINE (md1) [UU_UUUUU]
===============================================================================
 Disk | Device | # | Status |   Last Update Time   | Events | Array State
===============================================================================
  12  /dev/sde3  0   Active   Apr 29 14:38:42 2019      331   AAAAAAAA                 
  11  /dev/sdf3  1   Active   Apr 29 14:38:42 2019      331   AAAAAAAA                 
  10  /dev/sdg3  2  Rebuild   Apr 29 14:38:42 2019      331   AAAAAAAA                 
   9  /dev/sdh3  3   Active   Apr 29 14:38:42 2019      331   AAAAAAAA                 
   8  /dev/sdi3  4   Active   Apr 29 14:38:42 2019      331   AAAAAAAA                 
   7  /dev/sdj3  5   Active   Apr 29 14:38:42 2019      331   AAAAAAAA                 
   6  /dev/sdk3  6   Active   Apr 29 14:38:42 2019      331   AAAAAAAA                 
   5  /dev/sdl3  7   Active   Apr 29 14:38:42 2019      331   AAAAAAAA                 
===============================================================================

ベストアンサー1

前後の間に何が起こったのか正確に知っている人が誰もいないので、実際に答えることはほとんど不可能です。以下の私の推論を冷静に受け入れてください。これがどのように起こったかは確かに言うことはできませんが、あなたが提供したデータによると、これは本当のようです。

あなたのドライブ（以前）には1つのドライブが完全に欠落しており、他のドライブは間違いなく使用されていないとマークされています。 （4月23日と4月28日、イベント数は3515と3927です）。

あなたの（以後）混乱。イベントカウントリセット（331）、ドライブの順序が完全に異なります（sde3は＃7、現在＃0、sdf3は＃6、現在＃1など）。失われたドライブを回復する方法は不明で、使用されていないドライブを強制的に挿入します。設定に戻ります。 。また、ドライブ＃3が欠落しており、ドライブ＃5が期限切れになっていても、ドライブ＃2が再構築されていることを示しています。

デフォルトでは、誰かが正しく実行されると、動作するRAIDを再作成したように見えますが、あなたが何をしているのか本当に知っていますが、そうでない場合にのみ。ドライブの順序の変更を説明できない場合、ここでは正しく行われているようには見えません。

これらの仮定が正しい場合、（以前の）状態からデータを回復する可能性は依然として高いです。ファイルシステム自体が破損しても、エラーイベント（4月23日）以降に修正されていないすべてのファイルは破損せず、ある程度回復可能でなければなりません。

再同期化されたドライブが再作成され、再構築が進むと、ドライブ＃7と＃2のデータが破損する可能性があるため、これらの回復可能性はゼロまたはむしろチャンクサイズよりも小さいファイルに減少します。正確に64K。コードスニペットでは十分ですが、それ以外はあまりありません。

この時点であなたを救うことができる1つは、欠落しているドライブが実際に故障したのではなく、ランダムに削除され、4月23日以前に削除されなかった場合です。実際にドライブが物理的に交換されたかどうかは明記されていません。

失われたドライブに実際に欠陥がなく、まだ有効なデータがあり、アレイ上で回転し続ける場合、ドライブの順序が間違っていてもドライブを再作成すると、追加の損傷が発生しない可能性があります。これは、XORパリティ計算がどのように機能するか（順序に関係なく）raid5に可能な魔法です。

おすすめ記事