このスレッドは再起動の問題から始まり、システムディスクが完全にいっぱいになった場合のZimaOSの動作、AppDataの移行、アプリの再インストール、ストレージの復旧について、コミュニティによる詳細な検証へと発展しました。元のユーザーはUSBバックアップドライブを接続せずにZimaOSを起動したところ、通常のログイン画面が初回起動時のようなアカウント画面に置き換わっていることに気付きました。NFSデータには引き続きアクセスできましたが、フロントエンドとファイル関連サービスは正常に動作しませんでした。
最も重要な発見は、ZimaOS-HDの使用率が100%に達していたことです。ユーザーは後にシステムをZimaOS 1.5.2へ更新しましたが、システムボリュームの容量不足が中心的な問題として残りました。そのため、これは過去のトラブルシューティング事例としては有用ですが、再インストールの普遍的な手順ではありません。
ZimaOS-HDが100%いっぱいになると、ファイルアプリ以外も停止する可能性がある
この事例では、ダッシュボード、ファイルサービス、アプリのインデックス作成、アカウント関連のUIが不安定になる一方で、ユーザーはNFS経由で保存データに引き続きアクセスできました。コミュニティ参加者は、これらの症状をシステムパーティションが完全にいっぱいになったことと結び付けました。
このスレッドには、使用率100%のシステムディスクを安全に復旧するためのIceWhale公式のクリーンアップコマンドは記載されていません。ユーザーはすでにコンテナを削除し、ログを消去していましたが、十分な容量を確保できませんでした。これは重要な点です。コミュニティスレッド内の推測に基づくシェル操作を、公式の復旧手順として扱わないでください。
現在のシステムおよびストレージに関するガイダンスについては、現在のZimaOSにおけるストレージと復旧の扱いを参照してください。
IceWhaleは、デフォルトの構成では再インストール後の復旧を保証できないと注意喚起した
Zima-Giorgioは、この議論に重要な訂正を加えました。多くのユーザーは、OSとユーザーデータを同じディスクに置くデフォルト構成を使用しており、その構成で再インストールしても、すべてが自動的に再インデックス化されて復元されるわけではないと説明しました。また、3-2-1バックアップルールの重要性も強調しました。
この公式の注意喚起は重要です。というのも、それ以前のコミュニティの回答では、再インストール後の復旧が実際よりも自動的に行われるように説明されていたためです。再インストール後にデータが保持されるかどうかは、障害発生前のストレージ構成によって異なります。
ユーザーの移行テストで実際に確認されたこと
スレッドの2ページ目には、専用のOSディスクと別のNVMeデータディスクを使った、繰り返しの再インストールテストが記録されています。ユーザーの結果から、実用上、次のような動作が確認されました。
- 新規インストール後、以前使用していた単一のNVMeストレージディスクを再度有効にする必要がある場合がある。
- 古いAppDataフォルダーが存在するだけでは、アプリがダッシュボードに自動的に再表示されない。
- アプリのコンテナまたはイメージは、App Storeから再度インストールする必要がある。
- 再インストール前に別のストレージへ移行しておけば、永続的なアプリケーションデータは保持できる場合がある。
- カスタムポート、コンテナ名、ネットワーク設定、権限、ダッシュボード上の表示など、ZimaOSレベルのメタデータが保持されるとは限らない。
これらはZimaOS 1.5.2で行われたコミュニティのテストであり、IceWhaleによる復旧保証ではありません。当時観察された動作として扱ってください。
移行はコンテナ全体のバックアップではない
このスレッドから得られる最も有用な教訓の一つは、アプリケーションデータとZimaOSアプリのメタデータを区別することです。ユーザーは、移行したデータによってアプリが以前とまったく同じ状態で再作成されると期待していました。しかし、テストではそうならないことが示されました。
移行によってファイルやアプリケーションが所有するデータは保持しやすくなりましたが、ZimaOSのアプリエディターで設定したすべての項目が復元されたわけではありません。たとえば、カスタムポートマッピングやその他のコンテナレベルの設定は、再インストール後に再作成する必要がありました。
この違いにより、再インストール後にアプリケーションが既存のデータベースやメディアへ再接続できても、ZimaOSダッシュボードの設定は新しい状態に見えることがあります。
単一ディスクの復旧結果をRAIDに一般化しない
スレッドでは、RAID 5アレイが新規インストール後に自動的に認識されるかどうかについても詳しく検討されました。ユーザーの環境では、既存のRAIDがそのままアプリデータ用の使用可能なターゲットとして扱われるのではなく、ストレージの作成またはフォーマットを求められました。
そのため、すべてのデータボリュームが自動的に保持され、再接続されるという以前の主張は後退しました。このスレッドから導ける最も安全な結論は、テストしたZimaOS 1.5.2のワークフローでは、別の単一ストレージディスクとRAIDアレイは同じようには動作しなかったという、限定的なものです。
現在のZimaOSのストレージ動作は、この2025年のスレッド以降に変更されています。これらのRAIDに関する観察結果を現在の製品動作として使用せず、最新のストレージドキュメントを確認してください。
このスレッドから学ぶ、より安全な再インストールの考え方
- ZimaOSのストレージ変更や再インストールを行う前に、重要なデータをバックアップする。
- OSが入っている物理ディスクと、ユーザーデータが入っているディスクを把握する。
- 移行がコンテナ構成全体の完全なバックアップを意味するとは考えない。
- 再インストール後、アプリを再インストールする前に、ストレージが有効化されマウントされていることを確認する。
- 永続データが保持されていても、アプリケーションのコンテナやイメージは再インストールが必要になると想定する。
- ZimaOSレベルのアプリ設定について、別途エクスポートまたはバックアップがない限り、手動で再設定する。
ZimaOSの再インストールと移行に関するFAQ
なぜNFSデータにはアクセスできたのに、フロントエンドが動作しなくなったのですか？
この事例では、システムボリュームの使用率が100%に達していました。スレッドでは、この状態がフロントエンドや各種サービスの障害と関連付けられている一方、一部のデータアクセスは継続して機能していました。
AppDataを移行すれば、再インストール後にインストール済みアプリが自動的に再表示されますか？
いいえ。ユーザーのテストでは、ダッシュボードは空のままで、アプリを再度インストールする必要がありました。その後、既存の永続データを再利用できる場合があります。
移行によってカスタムポートやZimaOSアプリの設定は保持されますか？
スレッド後半のテストでは、保持されると想定しないよう示されています。移行によってアプリケーションデータは比較的よく保護されましたが、各コンテナを説明するZimaOSのメタデータまでは保持されませんでした。
このスレッドを根拠に、RAID構成へ安全に再インストールできますか？
普遍的な保証は確立されていません。RAIDのテストは単一ディスクの移行テストとは異なる動作を示しており、公式回答も自動復旧を約束するのではなく、バックアップの重要性を強調していました。
