このスレッドは高度なストレージ移行の失敗報告であり、サポート対象のインポート手順ではありません。ソースアレイは Linux カーネルレベルでは構成されましたが、ZimaOS のストレージレイヤーがそれを適切に引き継げず、ユーザーは解消しない UI エラーに遭遇しました。
カーネルレベルでのアレイ検出は、ZimaOS による管理を意味しない
Linux システムは RAID メタデータやファイルシステムを認識できても、アプライアンス型のストレージマネージャーには、そのプールを安全に管理するために必要なライフサイクル状態が備わっていない場合があります。RAID 復旧ワークフローでは、ZimaOS がすでに認識しているアレイについて、既存の RAID メタデータを保持し、最初の手順としてアレイを再作成しないという、より安全な原則が示されています。
OpenZFS には明確なエクスポートおよびインポートのライフサイクルがある
公式のOpenZFS プールのエクスポートの説明では、プールをエクスポートすると、そのデータセットがアンマウントされ、デバイスがエクスポート済みとしてマークされるため、後で移動してインポートできます。OpenZFS プールのインポートでは、別のホストが利用可能なプールを検出してインポートする方法が説明されています。
現在の ZimaOS 開発者向けドキュメントでも、zpool export などの ZFS CLI 操作が公開されています。ただし、これは任意の mdadm+Btrfs、ネイティブ Btrfs、ZFS プールをインポートするための汎用 GUI ウィザードと同じものではありません。
現在公開されているドキュメントには、あらゆる外部プールに対応するウィザードの説明がない
現在のストレージウィザードは、ZimaOS ストレージの作成と管理に重点を置いています。一方、公開されている ZFS 開発者向けガイドでは、手動による ZFS 操作が説明されています。実際の目的が外部アレイを引き継ぐことではなく、管理対象の ZimaOS データを新しいストレージへ移行することである場合は、ZimaOS データ移行が、現時点ではより安全な方法です。破壊的なストレージ操作を行う前に、ZimaOS バックアップワークフローを計画に含めてください。
唯一のコピーに対してインポート復旧フラグを強制しない
OpenZFS は、強制インポートや復旧インポートによって、最近のトランザクションが破棄されたり、その他の危険が生じたりする可能性があると警告しています。重要なデータの唯一のコピーに対して、復旧フラグの実験や破壊的な再フォーマットを行わないでください。
要点
1.6.1 で発生したコミュニティの障害事例は、カーネルが認識した外部アレイが、自動的に ZimaOS 管理下のプールになるわけではないことを示しています。ZFS には定義済みのエクスポート／インポートのライフサイクルがありますが、現在公開されている ZimaOS ドキュメントには、あらゆる外部 RAID／ファイルシステムの組み合わせを引き継ぐための、単一の汎用 GUI ワークフローは記載されていません。
