この事例は、ZimaOSのシステムディスクがいっぱいになると、RAIDやユーザーデータ自体が損なわれていなくても、移行が停止したように見えることを示しています。Resilio関連のインデックス作成やアプリケーションデータがOSドライブ上で増えた結果、ZimaCubeの228 GBシステムSSDは空き容量0 Bになりました。SMBとFinderからのアクセスは引き続き機能していましたが、ダッシュボードは不安定になり、移行も最初は5%で止まっていました。
移行は最終的に進み、45%、49%と進行した後、1日以上かかってようやく完了しました。元の投稿者はその後、Resilioによるシステムディスクへのインデックス作成と書き込みも停止したと述べています。現在のZimaOSのドキュメントでは、AppDataをシステムドライブに置かないことが明確に推奨されています。
システムSSDが完全にいっぱいだった
アプリデータの移行は最初、5%で停止したように見えた
進行が遅くても、移行が完全に停止したとは限らない
その後、ユーザーは移行が一晩で45%まで進み、さらに49%まで進んだことを確認しました。数か月後には、最終的に完了したと報告しており、おそらく1日以上かかったとのことです。
IceWhaleの最新ガイダンスでは、AppDataでシステムドライブをいっぱいにしないよう明確に警告しています
現在のアプリストレージパスに関するガイダンスでは、アプリケーションのデータベース、サムネイル、メタデータなどのAppDataが小容量のシステムドライブをいっぱいにし、アップデートやアプリ、デバイス自体の動作に異常をきたす可能性があると説明されています。
最新のAppDataストレージガイダンスを参照してください。
ディスクを圧迫し続けているアプリケーションを停止する
数GBの空き容量を作っても、Resilio、LLMモデル、Immichのキャッシュなど、別のコンテナがすぐに書き込んでしまうなら効果はありません。システムストレージを消費しているアプリを特定し、移行を再試行する前に停止してください。
再度移行を試す前に、作業用の空き容量を確保する
移行処理では、データベース、一時データ、ログ、アプリケーションの処理に必要な空き容量が必要です。確実に特定できたデータのみを削除または移動してください。不明なシステムディレクトリを対象に、ルート階層を一括でクリーンアップしないでください。
システムが安定してから、現在のデータ移行ツールを使う
現在のZimaOSでは、設定 > データ移行から、Dockerイメージ、Dockerアプリケーションデータ、管理対象ユーザーデータベースをストレージ間で移動できます。
小さなファイルが大量にあると、総容量から想像する以上に時間がかかることがあります
インデックスデータベース、サムネイル、メタデータのディレクトリは、大容量のメディアファイルよりも、1 GBあたりに必要なファイルシステム操作がはるかに多くなることがあります。
移行中に使用中のAppDataを手動で移動しないでください
別の参加者は、移行が停止した状態のまま、LLMのAppDataフォルダーを手動で移動しました。その結果、アプリケーションに設定されたパス、ZimaOSの移行状態、実際のファイルシステム上の場所が食い違うおそれがあります。
元の投稿者は、Resilioのファイル名に関する別の問題も報告しました
数か月後、timothyは、Resilioがサポートされていない文字を含むファイル名を変更したため、ZimaOS上でファイルが見つからないように見えていたと説明しました。ZimaOSがファイルを失ったという以前の疑いは誤りだったと、明確に訂正しています。
ダッシュボードが使えなくても、ストレージプールを失ったとは限りません
元の投稿者は、ダッシュボードからログアウトされ、移行画面の動作がおかしくなった後も、SMBとFinderを使えました。この違いは重要です。システムディスクがいっぱいになると、制御系のサービスに問題が生じる一方で、別のデータアレイはマウントされたまま読み取り可能なことがあります。
RAIDの破壊的な操作や再インストールを行う前に、その証拠を保存してください。
新たな移行を始める前にシステムディスクを調査する
システムドライブの容量を消費しているディレクトリを確認し、どのアプリケーションが使用しているか特定して、書き込みを停止してください。アプリを安全に削除・再作成できる場合は、無関係なディレクトリを削除するのではなく、対応する管理機能を使って、不要なキャッシュやイメージデータを削除してください。
十分な空き容量を確保できたら、必要に応じて影響を受けたサービスやアプリだけを再起動し、移行前に空き容量が安定していることを確認してください。
現在の移行は、全画面で行う管理された操作です
IceWhaleの最新ドキュメントによると、データ移行中はほかの操作を利用できません。データの移動対象となるアプリケーションの停止時間を計画し、同時に手動で移動することは避け、同じフォルダーを変更する前に、移行が明確な完了またはエラー状態になるまで待ってください。
再インストールは最終手段。空き容量が0 Bでも、最初に行う対応ではありません
ユーザーデータとストレージが無事なら、システムの空き容量を確保してAppDataの移行を完了することで、NASを再構築せずにシステムを復旧できます。再インストールが必要になった場合は、まずアプリケーションデータ、ストレージのメタデータ、重要なファイルをバックアップし、最新の復旧・再インストール手順に従ってください。
システムディスクがいっぱいのときのFAQ
元の移行は最終的に完了しましたか？
はい。元の投稿者はその後、1日以上経ってから移行が完了したと報告しています。
移行の進行状況バーが5%で止まっていても、データが失われた証拠になりますか？
いいえ。元の投稿者はその後、SMBとRAIDにアクセスできる状態のまま、移行が進んだと報告しています。
ZimaOS-HDの容量がいっぱいになったら、現在のユーザーはまず何をすべきですか？
書き込み中のアプリを停止し、安全に空き容量を確保してから、見慣れないシステムファイルを削除するのではなく、現在の「データ移行」や「AppData」の管理機能を使ってください。
