マウントパスを壊さずにコンテナデータをSSDプールへ移動する方法

各コンテナ側の保存先パスを変更せずに、ホスト側のデータソースをSSDへ移行します。

安全な移行では、現在のマウント構成をインターフェース契約として扱います。コンテナ、データベース、メディアアプリは、どのディスクから提供されるかにかかわらず、/config、/data、/mediaなどのパスを前提とします。ワークフローでは、書き込みを停止し、SSDを予測可能な方法でマウントし、所有権とメタデータをコピーし、ホスト側のソースだけを更新して、起動前に新しいマウントを検証する必要があります。また、完全な復元テストに合格するまで元のデータを保持します。

現在のすべてのソースとコンテナの保存先を一覧化する

Composeファイルまたはコンテナのインスペクションデータをエクスポートし、すべてのバインドマウント、名前付きボリューム、tmpfsマウント、データベースディレクトリ、キャッシュ、トランスコードパス、メディアの場所を一覧にします。ホスト側のソースとコンテナ側の保存先は分けて記録してください。

実用的なボリューム移行ガイドでは、現在のデータの場所を特定し、新しいディスク上の場所へコピーする前にコンテナを停止することから始めます。この一覧化により、設定データがシステムディスクに残るのを防げます。

どのパスに信頼できる永続状態、再構築可能なキャッシュ、大容量メディアが含まれているかを明示します。dataという名前のフォルダーに、永続化が必要なアプリケーション状態がすべて含まれているとは限りません。

Dockerの起動前にSSDプールを予測可能な方法でマウントする

SSDのファイルシステムまたはプールを作成し、安定したUUIDまたはプール名で識別して、最終的なホスト側パスにマウントします。再起動後に空き容量、想定されるファイルシステム機能、書き込み権限を確認してください。

ディスクが存在しない場合や、起動時に別のパスへマウントされた場合、Dockerデータを外部ストレージへ移動すると失敗することがあります。最近の外部SSD事例では、Dockerストレージを移動すると、移行先のマウントパスへの依存関係が変わることが説明されています。

Dockerがシステムディスク上に空のフォールバックディレクトリを作成しないよう、サービスの起動順序または自動マウントの動作を設定します。SSDが正確に想定したパスへマウントされていない場合は、処理を停止してください。

書き込み元を停止し、メタデータを保持してデータをコピーする

データへ書き込む可能性のあるアプリケーションとすべての依存サービスを停止します。データベース、インデクサー、ダウンローダー、バックグラウンドジョブも含まれます。データベースの場合は、未加工のファイルをコピーする前に、アプリケーションと整合性のあるダンプを取得するか、正常にシャットダウンしてください。

Synologyのコンテナに関する議論では、Docker管理ボリューム内のデータを特定し、新しいバインドマウントのソースに内容を保持してから、Docker管理ボリュームをバインドマウントへ移行することが推奨されています。

所有権、権限、タイムスタンプ、リンク、ACL、対応している場合は拡張属性を保持しながら再帰的にコピーします。Composeを変更する前に、ドライランによる比較またはサンプルのチェックサム検証を実行してください。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

ホスト側のソースパスだけを変更する

コンテナ側の保存先は同じままにします。たとえば、/oldpool/app:/configを/ssdpool/app:/configに変更し、アプリケーションに新しい内部パスを設定することは避けてください。

バインドマウントは、ホスト上の正確な場所をコンテナ内の固定パスへ公開します。ストレージの概要では、この直接マッピングにより、管理者がホスト側のパスを管理できることが説明されています。

保存先を維持することで、アプリケーションのデータベース、ライブラリ参照、スクリプト、権限、コンテナ側のパスを保存する設定値が壊れるのを防げます。

所有権、ラベル、データベースの整合性を復元する

イメージが想定する数値UIDとGIDを、SSD上の所有権と比較します。また、ACL、SELinuxラベル、AppArmorの許可、ロックやメモリマップファイルに必要なマウントオプションも復元してください。

macOSでDockerストレージを移行するガイドでは、Dockerデータの移動にはストレージイメージ全体をコピーし、その後ランタイムが新しいストレージの場所を使用していることを確認する必要があると説明されています。LinuxのNASシステムでは、設定済みのすべてのソースがマウントされたSSDを参照していることが同等の確認になります。

まずデータベースだけを起動し、依存するアプリケーションを起動する前に復旧ログを確認します。破損またはファイル不足が報告された場合は、アプリケーションが空のデータベースを初期化する前に停止し、元のコピーへ戻してください。

ロールバック手順を確保して切り替え、ワークフロー全体をテストする

依存関係の順序に従ってスタックを起動し、設定、データベースレコード、権限、メディアライブラリ、アップロード、ダウンロード、更新、コンテナの再作成を確認します。新しい書き込みがSSDに保存され、システムディスクの使用量が増えなくなったことを確認してください。

Dockerのバインドマウントが突然読み取り専用になる問題に関するZimaSpaceの記事では、移行したパスはマウントされるものの書き込みが拒否される場合の次の診断方法を説明しています。

バックアップと、SSD上のパスを使用した2回目のコンテナ再構築が成功するまで、古いデータはオフラインかつ変更されていない状態で保管します。Composeファイル、マウント、データベース、アプリケーション状態を復元できることをロールバック演習で確認してから、古いソースを削除してください。