この原文で最も重要な訂正は、アレイが「1台のディスクが故障した」状態のまま確定していたわけではないということです。ユーザーが各ドライブを別々に接続して起動したところ、どちらも単独で実用可能でした。両方のドライブを再接続すると、翻訳結果が続きます。 [UU] 内 /proc/mdstatつまり、その時点ではRAID 1の両方のメンバーが存在し、同期されていました。
その後、スレッドではSATA/リンク/電源の不安定さ、USB/モニターの障害、緊急モードでの起動、NFSエラー、ZimaOSが別のシステムスロットにフォールバックする問題へと話が広がりました。データは復旧しましたが、最終的な原因が1つに特定されたことは、原文では示されていません。これを単純な「ディスクXを交換する」手順にしてはいけません。
復旧の可能性がある間は「Break」や「Format」をクリックしないでください
この安全面に関する最初のコミュニティの助言は正しかったです。データが重要で、アレイの実際の状態が不明な場合、破壊的なUI操作によって復旧が難しくなる可能性があります。まず読み取り可能なデータをバックアップしてください。
各ディスクは単独でテストすると動作した
元の投稿者はドライブを1台ずつ取り外し、それぞれで実用可能なシステム/データ経路が得られたと述べました。これにより、ディスクの1台が物理的に故障したという仮定は直ちに弱まりました。
両方を再接続すると正常な[UU] mdアレイになった
投稿されたステータスは、両方を再接続すると正常な[UU] mdアレイになったことを示していました md0 : active raid1 ... [2/2] [UU]その時点でLinuxのmd層は、両方のメンバーが存在すると認識していました。
このため、その後の議論はRAIDメタデータだけでなく、ケーブル、SATAポート、コントローラー、アダプター/バックプレーン、電源の安定性へと移りました。
SATA/電源の不安定さはRAID障害に見えることがある
その後、SATA、USB、ディスプレイの動作に影響する、より広範な障害が報告されました。コミュニティからは、SATAケーブルの交換、別のポートでのテスト、限界状態のスプリッターやアダプターの回避、I/Oリセットの有無を確認しながらのストレステストなどが提案されました。
これらはコミュニティによる診断であり、IceWhaleが確認したハードウェアの欠陥ではありません。
その後の緊急モード/NFS問題は別の層の問題だった
ケーブルの変更と再起動の後、システムは緊急モードに入り、NFS/RPC関連のエラーが表示されました。コミュニティではNFSの状態を消去したりNFSを無効にしたりする試みが行われましたが、修復が確認されるには至りませんでした。
NFSが元のRAIDアクセス不能の原因だったと推測してはいけません。NFSの問題は、すでにシステム全体が不安定になっていた後に発生しました。
システムは別のZimaOSスロットにもフォールバックした
ユーザーはAではなくBlock／スロットBから起動したと報告しました。現在のZimaOSは復旧用にデュアルシステムスロットを使用しているため、フォールバックはRAID上のユーザーデータが失われたことではなく、一方のシステムスロットが健全性／起動チェックに失敗したことを示している可能性があります。
現在のZimaOSデュアルスロット復旧モデルを参照してください。
現在のZimaOSには公式のRAID 1修復ワークフローがあります
ZimaOS 1.4.4では、劣化／損傷したアレイ向けのRAID1修復機能が追加され、以前使用していたディスクが復旧中に利用できなくなる問題が修正されました。
古い手動のmdadm変更コマンドを実行する前に、公式のRAID1修復機能を使用してください。
新しいZimaOSリリースではRAIDメタデータの耐性が向上
ZimaOS 1.6.0では、OSの再インストールやデバイス交換後に元のアレイを自動的に再識別してマウントするよう設計された、RAIDメタデータの保存機能が追加されました。これにより、1.5.x時代のソースと比べて復旧手順が改善されています。
より安全な現在の復旧手順
- アレイをフォーマットしたり、分解したりしないでください。
- 読み取り専用の診断で、ディスクのモデル／シリアル番号と現在のRAIDの健全性を確認してください。
- アクセス可能なデータは直ちにバックアップしてください。
- ケーブル、ポート、電源、SMART、およびカーネルのI/O／リセットログを確認してください。
- アレイが実際に劣化している場合は、現在のRAID修復UIを使用してください。
- OSスロットの復旧は、RAIDデータの復旧とは分けて扱ってください。
復旧スレッドは最終的にZimaOSのリセット／復旧オプションに到達しました
[UU] mdステータスは、その時点でRAID 1の両方のメンバーが存在していたことを示します
両方のディスクを再接続した後、ソースではアレイが2つのメンバーでアクティブになっており、 [UU]。これは、その時点でミラー自体が正常に再アセンブルされていたことを示す強い証拠でした。
アレイが以前アクセス不能に見えた理由や、その後もSATA／USB／モニターの不安定さが続いた理由については説明していません。
読み取り専用の診断は、mdadmによる手動修復コマンドより安全です
コミュニティは変更を提案する前に、アレイやステータスに関する情報を求めました。それが正しい順序です。メンバーの追加・削除やメタデータの再作成を行う前に、どのデバイスがアレイに属しているか、アレイがアクティブか劣化しているか、カーネルが何を報告しているかを確認してください。
別の mdadm --create別のLinux事例にある、強制アセンブルやスーパーブロック消去のコマンドを、データの唯一のコピーが含まれるRAIDにコピーして実行しないでください。
アレイが読み取り可能になったら重要なデータをコピーする
情報源のユーザーはアクセスを復旧しました。その時点では、ケーブル、コントローラー、システムスロット、NFS、再インストールについてさらに試行錯誤を続ける前に、代替ストレージへかけがえのないデータをコピーすることを優先すべきです。
RAID 1は冗長性を提供しますが、不安定なホストやコントローラーによって両方のメンバーが同時に利用できなくなることがあります。
SATA、USB、ディスプレイの問題が同時に発生した場合は、診断の範囲を広げる
後に現れた症状は、もはや単純な1台のディスク故障だけでは説明できませんでした。SATAの検出不良、USBの挙動、モニターや起動の問題が断続的に発生する場合は、ケーブル、電源、コントローラー、マザーボードのファームウェア、その他のプラットフォームの不安定さが原因である可能性があります。
RAIDの再構築を繰り返す前に、正常な電源とケーブルを試し、ハードウェア構成を簡素化してください。
システムスロットのリカバリーとRAIDリカバリーは別のもの
ZimaOSは、OSリカバリーのために別のシステムスロットから起動できます。Slot Bへの切り替えでOSスロットの問題を修復または回避できますが、それだけで劣化したアレイが修復されるわけではありません。
OSスロットも不調な場合は、現在のZimaOSシステムリカバリーモデルを使用してください。
リカバリープランで指示されている場合は、OSの再インストール時にデータディスクを取り外す
情報源のコミュニティでは、誤ったドライブを選択または変更する可能性を減らすため、OSをクリーンインストールする際はRAIDディスクを分離することが推奨されていました。現在のIceWhaleサポートが再インストール手順を提示する場合は、まずすべてのディスクにラベルを付け、ストレージのメタデータとバックアップを保全してください。
RAID 1リカバリーFAQ
情報源では、どちらか一方のディスクが完全に故障したと断定されていましたか？
いいえ。後に両方のディスクは個別に動作し、アレイには [UU] 再接続したとき。
情報源では、最終的な根本原因を1つに特定していましたか？
いいえ。RAID、SATA／電源の不安定さ、NFSの起動、OSスロットの問題が重なっていました。
現在のZimaOSにはRAID1の修復機能がありますか？
はい。IceWhaleは1.4.4で公式のRAID1修復ワークフローを追加しました。
