このスレッドは、後に組み込み機能となった実際の製品上の不足を記録しています。ZimaOS 1.4.1では、750 GBドライブ1台の故障後、2台構成のRAID 1が劣化／読み取り専用状態になりました。交換用ディスクは正常な別のHDDとして表示されましたが、ストレージUIには明確な「交換して再構築」操作がありませんでした。
IceWhaleは当初、エンジニアリングサポートとCLI診断を通じて影響を受けたユーザーに対応しました。その後、Zima-GiorgioはZimaOS 1.4.4でより包括的なRAID 1修復プロセスを提供すると発表しました。現在の公式1.4.4リリースノートでは、劣化または損傷したアレイ向けにRAID1修復が追加されたことが確認されています。
元のRAIDはProtecting／読み取り専用状態になった
交換用HDDは別個に検出された
1.4.1のストレージページは新しいディスクが必要だと警告していた
IceWhaleはユーザーにリスクの高い自己修復を避けるよう呼びかけた
Zima-Giorgioはエンジニアリングサポートを提供し、経験豊富なユーザーには収集するよう求めました lsblk および mdadm -D /dev/md0 出力。破壊的な再構築手順は公開しませんでした。
エンジニアが後から問い合わせたユーザーのアレイを非公開で修復した後、彼は十分な知識やエンジニアからの直接の指示なしに、rootレベルのRAID操作を実行しないよう明確に警告しました。
ZimaOS 1.4.4でWebUIにRAID 1修復機能を追加
2025年9月4日、Zima-Giorgioは1.4.4でより包括的なRAID 1修復プロセスを提供すると述べました。別のユーザーが1.4.4でのCLIサポートを求めた際、Giorgioは1.4.4ではWebUIから修復を実行できると回答しました。
現在のIceWhaleのリリースノートには、次のように記載されています。「RAID1修復機能を追加：RAID1アレイが劣化または破損している場合でも修復を実行できます。」
古いroot/mdadmの検証を再現するのではなく、公式のZimaOS 1.4.4 RAID 1修復機能を使用してください。
1.4.4では復旧時に以前使用されていたディスクの問題も修正
同じリリースノートには、以前使用されていたディスクをRAID復旧時に選択できなかった問題をZimaOSで修正したと記載されています。これは、古い署名が残っていたり、別途初期化されていたりする可能性のあるディスクを交換用ドライブとして使用する手順に直接関係します。
故障したメンバー以上の容量を持つ交換用ディスクを使用してください
RAID 1の再構築には、アレイの既存のデータレイアウトに十分対応できる容量の交換用メンバーが必要です。公称容量が同じ「750 GB」や「2 TB」のドライブでもセクター数がわずかに異なる場合があるため、使用可能容量が少ないドライブは拒否されることがあります。
可能な場合は、リスクの高い復旧を行う前に読み取り可能なデータをバックアップしてください
劣化したRAID 1では、すでに冗長性が失われています。再構築中に残りのディスクが故障すると、アレイが失われる可能性があります。アレイが読み取り可能で、データがまだバックアップされていない場合は、侵襲的な復旧を実行する前に、かけがえのないデータを独立したドライブにコピーしてください。
既存のメンバーディスク上で「RAIDを作成」をクリックしないでください
ZimaOSで古いRAIDメンバーが未使用または単独のディスクとして表示される場合、新しいRAIDを作成するとメタデータが上書きされる可能性があります。続行する前に、既存の劣化したアレイを修復するのか、意図的に新しい空のアレイを作成するのかを確認してください。
RAID 1の再構築は、稼働中のディスクに高負荷がかかる期間です
再構築中、ZimaOSは交換先に書き込みながら、稼働中のメンバーディスクを広範囲に読み取る必要があります。残っている古いディスクがすでに限界に近い状態であれば、このタイミングで読み取り不能セクターやその他の故障が発生する可能性が最も高くなります。
そのため、劣化したアレイがまだ読み取り可能であれば、再構築の前にかけがえのないデータを外部にバックアップしておく必要があります。
交換先が別ストレージとして表示されるだけで、フォーマットしないでください
元のケースでは、ユーザーはすでに新しいディスクをフォーマットしており、ZimaOSにはHDD-Storageとして表示されていました。その後の1.4.4の修正では、以前使用されていたディスクがRAID復旧に利用できない問題に具体的に対処しました。
現在のシステムでは、RAID修復ワークフローに従い、選択した交換用ディスクの準備をZimaOSに任せてください。先にフォーマットしたり別のストレージ領域を作成したりすると、復旧UIが対処しなければならないメタデータが追加される可能性があります。
読み取り専用の診断は手動でRAIDを変更するより安全
Zima-Giorgioが要求したコマンド—lsblk および mdadm -D /dev/md0—デバイスとアレイの状態を特定するために診断用の読み取り操作が使われました。これは、メンバーの追加、スーパーブロックの消去、強制的なアセンブル、アレイの再作成を行うコマンドとはまったく異なります。
サポートからCLIの出力を求められた場合は、要求された読み取り専用の情報をそのまま収集し、関係のないLinuxチュートリアルを参考に破壊的なmdadm操作を独断で行わないでください。
再構築完了後にアレイを確認する
交換用ディスクが認識された時点で復旧完了と考えないでください。同期または再構築が完了するまで待ち、RAIDが正常または保護中の状態に戻ったことを確認し、代表的なファイルを開いて、プールに依存するアプリケーションが正常に動作することを確認してください。
これらの確認が完了するまで、外部バックアップには手を加えないでください。
アレイが正常なうちに次のディスク障害に備える
RAID 1は故障したメンバーを交換するための時間を確保しますが、バックアップが不要になるわけではありません。重要なデータは別の場所にもコピーを保持し、ディスクのモデルとシリアル番号を記録し、定期的に健全性を確認して、2台目のメンバーが故障する前に劣化状態を把握できるようにしてください。
RAID 1復旧に関するFAQ
ZimaOS 1.4.1のUIにはRAID 1の修復機能がありませんでしたか？
元の投稿者は劣化したアレイと交換用ディスクを確認できましたが、通常の修復操作はありませんでした。
IceWhaleは後にWebUIの修復フローを追加しましたか？
はい。IceWhaleは、1.4.4でWebUIからRAID 1を修復できるようになったと述べており、公式リリースノートにもRAID1の修復が新機能として記載されています。
現在のユーザーは、以前のスレッドにあるroot権限のmdadmコマンドを実行すべきですか？
いいえ。IceWhaleは、リスクを理解しているかエンジニアから指示を受けていない限り、root権限でRAID操作を行わないようユーザーに明確に警告しました。
