結論：再起動後にファイルが見つからないだけでは、RAIDを再構築する十分な根拠にならない
ログには、ZimaOSが/dev/md0のマウントを試み、保存されているファイルシステムの種類BTRFSを使用した際に失敗していることが示されています。これは調査する価値のあるマウント／メタデータ経路を示していますが、それだけでデータが消失したことや、ファイルシステムが正常であることを証明するものではありません。
まずは読み取り専用の識別チェックを実行する
lsblk -f
cat /proc/mdstat
sudo mdadm --detail /dev/md0
sudo blkid /dev/md0確認したいのは次の4点です。両方のメンバーディスクが認識されているか、mdアレイがアセンブルされているか、mdadmがどのような状態を報告しているか、そしてアセンブルされたデバイスがどのファイルシステムシグネチャを示しているかです。mdadmのマニュアルにはアレイの検査方法が記載されており、Btrfsドキュメントはファイルシステムチェックに関する上流のリファレンスです。
古いアレイを復旧できる可能性がある間は、RAIDメタデータをフォーマット、再作成、またはゼロクリアしない
新しい「RAIDを作成」操作によって、マウントの問題がデータ損失につながる可能性があります。ZimaOS RAID復旧ガイドでも同じ安全上の区別を説明しています。まず既存のアレイを保全して識別し、その後で復旧または再構築が必要かどうかを判断します。
/etc/fstabが最初の対処ではない理由
ZimaOSは独自のストレージサービスとメタデータを通じてストレージを管理します。手動マウントでファイルシステムが読み取り可能であることは確認できますが、fstabのエントリを追加しても、ZimaOSのファイルUIが想定する状態が必ずしも修復されるわけではありません。現在のZimaOSストレージガイドが、サポート対象の基本手順です。
ケースをエスカレーションするタイミング
/proc/mdstatとmdadm --detailで正常にアセンブルされたアレイが示されているにもかかわらず、ZimaOSがマウントを拒否し続ける場合は、再起動や試行錯誤を行う前に、ログと上記4つの読み取り専用出力を保存してください。その情報によって、サポート担当者は問題がアレイのアセンブル、ファイルシステムの認識、またはZimaOSのマウント管理のいずれにあるかを判断できます。
ZimaOSデータ移行ガイドが関係するのは、ストレージが正常で認識されるようになった後だけです。移行はRAID復旧の代わりにはなりません。
