コミュニティソリューション

システム再インストール後に ZimaOS の RAID 1 を復元する

A ZimaOS 1.6.1 user documented a real RAID 1 recovery after reinstalling the OS, using read-only verification, an external offload copy, a native UI rebuild, and a verified restore.

ZimaOSを再インストールした後、既存のRAID 1が未使用ディスクとして表示されても、すぐにCreate RAIDをクリックしないでください。アレイを再作成したりフォーマットしたりすると、メンバーディスクにまだ残っているデータが破壊される可能性があります。

最初に試す復旧方法は、現在のZimaOS公式手順で、保存しておいた local-storage.db 以前のシステムインストールにあるファイル。このページの基になったコミュニティチュートリアルでは、そのデータベースをバックアップしていなかった場合の、より難しいケース向けに、さらに侵襲的な代替手順を説明しています。この代替手順はZimaOS 1.6.1でテストされていますが、破壊的なRAID操作を含むため、元のデータを別途コピーして検証した後にのみ検討してください。

第一選択肢：local-storage.dbを復元する

ZimaOSはストレージ構成情報を次の場所に保持しています。

/ZimaOS-HD/.casaos/db/local-storage.db

現在の公式復旧ガイドでは、システムを再インストールする前にこのファイルをダウンロードし、新しいZimaOSのインストール後に同じディレクトリへ戻してから再起動することを推奨しています。

再インストール後のZimaOS公式RAID復旧

以前のシステムディスクにまだアクセスできる場合は、RAIDメンバーディスクに触れる前に、このデータベースの復旧を試してください。

データアレイがまだ無傷である可能性がある理由

ZimaOSはLinuxのソフトウェアRAIDを使用します。新しいZimaOSのインストールで以前のストレージデータベースがなくなっていても、メンバーディスクにはRAIDメタデータが保持されている場合があります。そのため、ディスクが物理的には存在しているのに、UIでは元のプールが認識されないことがあります。

ZimaOS 1.6では、RAIDメタデータの復旧と再識別の動作も改善されました。そのため、あるシステムで最初に発生した問題が、すべての新しいリリースで同じように発生すると考えてはいけません。

復旧方針が決まるまで新しいRAIDを作成しないでください

ディスクに必要なデータが含まれている場合は、次の操作を避けてください。

  • いずれかのメンバーディスクをフォーマットすること
  • 同じディスク上に新しいRAIDを作成すること
  • を実行すること wipefs または mdadm --zero-superblock 早まって
  • 推測で /dev/sdX どのデバイスか

復旧作業を始める前に、デバイス名だけに頼らず、モデル、シリアル番号、容量でディスクを特定してください。

RAIDメタデータを読み取り専用で確認する

コミュニティの執筆者は、まず読み取り専用の検査を行い、両方のRAID 1メンバーがまだ同じアレイに属していることを確認しました。

lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,FSTYPE,MODEL,SERIAL

mdadm --examine /dev/sda
mdadm --examine /dev/sdb

正常なRAID 1では、両方のメンバーが同じアレイUUIDと互換性のあるRAIDメタデータを報告する必要があります。片方のメンバーが見つからない、劣化している、または異なるメタデータを報告している場合は、停止して、一般的な再構築手順に従うのではなく、復旧支援を受けてください。

古いアレイを読み取り専用で組み立ててマウントする

高度な復旧では、読み取り専用でアレイを組み立てることで、ファイルにアクセスできることを確認する際に、ソースが変更される可能性を抑えられます。

mdadm --assemble --readonly /dev/md127 /dev/sda /dev/sdb

mkdir -p /DATA/oldraid
mount -o ro /dev/md127 /DATA/oldraid

次に、ファイルシステムを確認します：

df -h /DATA/oldraid
ls -la /DATA/oldraid
du -sh /DATA/oldraid/*

上記のデバイス名はあくまで例です。実際のハードウェアと一致することを確認せずに、そのまま貼り付けないでください。

破壊的な操作を行う前に、完全なオフロードコピーを作成する

元の手順では、使用中のRAIDデータをすべて格納できる容量の外付けext4ドライブを使用していました。Linuxアプリケーションのデータには、通常の所有者情報、権限、リンク、ACL、拡張属性を保持できるため、ext4が便利です。

一般的なアーカイブ形式のコピーは次のとおりです：

rsync -aHAX --info=progress2   /DATA/oldraid/   /DATA/offload/

コピーを次の環境で実行します： tmux または、SSH接続が切断されると処理が中断される場合は、別の永続ターミナルを使用します。

先に進む前にバックアップを検証する

rsyncの終了メッセージだけに頼らないでください。ファイル数を比較し、主要なディレクトリのサイズを確認します：

find /DATA/oldraid -xdev -type f | wc -l
find /DATA/offload -xdev -type f | wc -l

du -sh /DATA/oldraid/*
du -sh /DATA/offload/*

失われると取り戻せないデータについては、独立した2つ目のバックアップを作成することを推奨します。RAID自体はバックアップではありません。

最終手段：オフロード、古いRAIDメタデータの削除、UIでの再作成

元のコミュニティ投稿者は、復旧したアレイを通常のZimaOS UI管理に戻すことを目指していました。最終手段として、次の方法を使用しました：

  1. 古いアレイを読み取り専用で検証する；
  2. すべてのデータを外付けドライブにコピーする；
  3. コピーを検証する；
  4. 古いmdアレイを停止する；
  5. 古いRAIDメタデータを削除する；
  6. ZimaOSのストレージUIを使用して、新しいRAID 1を作成する；
  7. コピーしたファイルを復元する；
  8. 復元したデータを検証します。

この手順では、古いRAIDメタデータを意図的に破壊します。この手順を実行すると、オフロードしたコピーが復旧元になります。コピーが不完全な場合や、デバイスの識別に確信がない場合は、この方法を使用しないでください。

元の手順に含まれる取り消し不能なコマンド

コミュニティで使用された手順：

mdadm --zero-superblock /dev/sda /dev/sdb

これはトラブルシューティング用のコマンドではありません。指定したディスクからRAIDメタデータを削除します。デバイスパスを間違えると、重大なデータ損失につながる可能性があります。

そのため、ZimaOSのUIがRAIDを認識しないというだけの理由で、この操作を実行することは推奨していません。復元 local-storage.db、現在のZimaOSの復旧動作を確認し、アレイに重要なデータが含まれている場合は、まずサポートに問い合わせてください。

ZimaOSのUIからアレイを再作成する理由

元のワークフローの目的は、ストレージUI外で手動構成したmdデバイスを恒久的に使用するのではなく、ZimaOSが通常どおり管理するストレージプールで終えることでした。

古いデータを安全にオフロードし、ディスクを意図的にリセットした後、現在のストレージインターフェースを使用してRAID 1を作成し、初回同期が完了するまで待ちます。

新しいプールにファイルを復元する

新しいプールを作成してマウントしたら、オフロードディスクから復元します：

rsync -aHAX --info=progress2   /DATA/offload/   /media/Storage/

置き換え /media/Storage システムに表示される実際の保存先パスに置き換えてください。

復元したプールを検証する

find /DATA/offload -xdev -type f | wc -l
find /media/Storage -xdev -type f | wc -l
du -sh /media/Storage/*
cat /proc/mdstat

RAIDの同期が完了し、ZimaOSのファイルインターフェースとデータに依存するアプリケーションから正常にアクセスできることを確認するまで、オフロード先のドライブには手を加えないでください。

次回の再インストール前にlocal-storage.dbをバックアップする

最も簡単な復旧方法は、事前に準備しておくことです。次のファイルの最新コピーを保管してください：

/ZimaOS-HD/.casaos/db/local-storage.db

システムドライブの外部にあります。現在の公式ドキュメントには、このファイルを使用した直接的な復元手順が記載されています。

どの復旧方法を選ぶべきですか？

状況 推奨される操作
local-storage.dbをバックアップしている 公式のデータベース復元方法を使用してください
古いシステムディスクがまだ読み取り可能 RAIDディスクを変更する前にlocal-storage.dbを復元してください
データベースのバックアップはなく、RAIDメタデータは正常に見える 破壊的な操作を一時停止し、サポートまたは復旧に関する助言を求めてください
完全かつ検証済みのオフロードコピーがあり、UIで管理するクリーンなアレイを意図的に作成したい場合 コミュニティのオフロード／再作成／復元方式を検討してください
RAIDメンバーのメタデータが一致しない、または劣化しています 停止して、専門家による復旧の指示を受けてください

ZimaOS RAID復旧に関するよくある質問

ZimaOSを再インストールすると、RAIDデータは自動的に消去されますか？

システムディスクの再インストールは、RAIDメンバーディスクのフォーマットとは異なります。ストレージ設定が失われても、RAIDメタデータとデータはメンバーディスク上に残っている場合があります。

古いディスクが未使用と表示されている場合、「RAIDを作成」をクリックしてもよいですか？

既存データを復旧する必要がないことを確認するまでは実行しないでください。新しいRAIDの作成は破壊的な操作になる可能性があります。

local-storage.dbをバックアップしていた場合、最も安全な復旧方法は何ですか？

現在の公式ZimaOS手順を使用して、そのデータベースを復元してから再起動してください。

mdadmのスーパーブロックをゼロクリアしても安全ですか？

RAIDメタデータを意図的に破壊する操作です。データを安全に別の場所へコピーしたうえで、検証済みの復旧計画の一環としてのみ使用してください。