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

ZimaOSのデータ移行に失敗:まずファイルシステムをチェック

A reproducible ZimaOS user-database migration failed on an NTFS target and succeeded after the target was reformatted as EXT4.

要点:この解決済みのケースではNTFSが根本原因でしたが、すべての移行失敗を説明できるわけではありません

再現テストでは、ZimaOSは途中までデータをコピーした後、NTFSの移行先で最終的な権限コピーの段階を完了できずに失敗しました。移行先をEXT4で再フォーマットすると、その移行は成功しました。その後の返信では別の構成でも失敗が報告されているため、「すべてをEXT4でフォーマットする」ことはケース固有の対処であり、有用な事前確認ではあるものの、万能な解決策ではありません。

sda1へのユーザーデータベース移動中に問題が発生したと表示されるZimaOSの移行エラー画面
元の失敗画面には、ZimaOS-HDからsda1へのデータ移動中にユーザーデータベースの移行が中止された様子が表示されています。

現在の移行は、サポート対象のデータ移行ツールから開始してください

移行先としてsda1を選択したZimaOSユーザーデータベースの保存場所ダイアログ
移行ワークフローで、ユーザーデータベースの新しい保存場所としてsda1が選択されています。
移行中はDockerサービスが一時停止することを警告するZimaOSの移行準備ダイアログ
確認画面には、移行モードが有効な間はDockerサービスが一時停止することが示されています。
進行率70パーセントのZimaOSユーザーデータベース移行進捗画面
テストした移行は、その後失敗しましたが、転送は70%まで進みました。

現在のZimaOSデータ移行ガイドでは、Dockerイメージ、Dockerアプリケーションデータ、ユーザーフォルダーをカテゴリー別に移動します。ZimaOS移行パスガイドは、実際に何が移動されるのかを判断するための、現時点で最適な補足資料です。

開始ボタンを押す前に移行先のファイルシステムを確認する

lsblk -f
blkid

移行先のデバイス、ファイルシステムの種類、空き容量、マウント状態を確認してください。移行先がLinuxの所有権や権限の扱いが異なるファイルシステムの場合、アプリデータの移行は単純なドラッグ&ドロップによるコピーよりも影響を受けやすくなります。lsblkのマニュアルext4のドキュメントは、確認に役立つ参考資料です。

移行中に「Dockerを停止」と表示される理由

これは想定された動作であり、失敗そのものではありません。コンテナがデータに書き込み続けている状態では、アプリデータを安全に移動できません。移行ワークフローではDockerを一時停止し、管理対象のデータをコピーして保存場所を更新した後、サービスを再開します。

sda1への1.08 GBの移動後に表示されたZimaOSの移行エラー画面
大容量のテストでも、コピー段階が完了したように見えた後に「問題が発生しました」と表示されて終了しました。
アプリデータ、アプリイメージ、ユーザーデータベースの移行場所を表示するZimaOSのアプリ設定
この画面には、アプリデータ、Dockerイメージ、ユーザーデータベースの移行カテゴリーが個別に表示されています。

EXT4でも移行に失敗する場合

すぐに再フォーマットしないでください。移行元と移行先のファイルシステム、空き容量、移行カテゴリー、ZimaOSのバージョン、移行先が単一ディスクかRAIDかを記録してください。可能であれば、小規模なカテゴリーで再現を試みます。Zimaで作成したストレージでも後から失敗したという事実は、ファイルシステムの種類が判断材料の一つにすぎないことを示しています。

破壊的な再試行を行う前に、ZimaOSバックアップワークフローで重要なデータを保護してください。