ZFSデータセット移行ガイド:コンテナのパスを変更せずにデータを移動する

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

安全なアプローチは、レプリケート、検証、元のマウントポイントへのアトミックな切り替えを、単一のコマンドではなく、観測可能なゲートを順番に通過する手順として扱い、ロールバック用のデータセットを保持することです。

ホームサーバーのコンテナスタックを支えるZFSデータセットでは、実際のリスクは、コンテナが使用するバインドマウントのパスを維持したまま、ZFSデータセットを移動する必要があることです。現在の識別情報と復旧ポイントを記録し、最も影響の少ない判別から始め、別の変数を変更する前に成功・失敗の結果を解釈し、ストレージが不安定になった場合や、復旧可能なコピーが1つしかなく、それが露出する場合は中止します。以下の手順は、元のワークロードが正常に動作するか、証拠がエスカレーションの境界に達した時点でのみ完了します。

データセットとパスの契約を棚卸しする

ソースデータセット、子データセット、スナップショット、マウントポイント、canmountの値、暗号化ルート、クォータ、予約、ACLの動作、およびその中に配置されるすべてのコンテナのバインドマウントを記録します。契約対象はコンテナから見えるホストパスであり、その下でプール名やデータセット名が変わっても構いません。

ZFSレプリケーションではスナップショットとプロパティを保持できるため、再帰ストリームには、無条件のreceiveではなく、意図的なプロパティ確認が必要です。独立したZFS sendとreceiveを使用した移行では、データセット内部の移行にsendとreceiveを使用する方法と、切り替え前にターゲット階層を確認すべき理由が説明されています。

移行前に、最新の外部バックアップを作成するか、既存のバックアップから復元できることを確認します。ソースに隠れた子データセット、暗号化キーへの依存関係が不明な状態、または別の稼働中データセットと重複するマウントポイントがある場合は中止してください。これらの条件があると、正しいストリームでも誤った場所にマウントされる可能性があります。

本番環境に重ねてマウントせず、最初のコピーを受け取る

zfs snapshot -r oldpool/apps@move-0のような再帰スナップショットを作成し、マウントを無効にするか一時的なマウントポイントを設定したターゲットデータセットに送信します。暗号化とプロパティの要件に適したフラグを使用してください。暗号化されたrawストリームと復号済みのreceiveで、キーの動作が同じだと決めつけないでください。

receive後、両方のツリーでzfs list -r -t filesystem,snapshotとzfs get -r mountpoint,canmount,encryptionroot,quota,reservationを比較します。レプリケートされたマウントポイントプロパティに関するフォーラムの議論は、レプリケートされたマウントポイントプロパティによって、移行自体は成功していても予期しない結果が生じる理由を示しています。

データセットとスナップショットの系譜が一致し、ターゲットが本番パスから分離されたままであれば、最初のコピーは合格です。ターゲットがソースに重ねてマウントされたり、コンテナから見えるファイルが変更されたりした場合は、ターゲットをエクスポートまたはアンマウントし、増分sendを行う前にプロパティを修正します。

書き込みの空白を閉じ、マウントポイントを切り替える

アプリを稼働させたまま、ソースの別のスナップショットを取得し、増分差分を送信します。最終的な切り替えでは、すべての書き込み元を停止し、バインドマウントのパス下に開いているファイルがないことを確認してから、最終スナップショットを取得し、その差分だけを送信します。停止時間は、最終同期とパスの切り替えに限定します。

ソースを非本番用のマウントポイントまたはcanmount=noautoに設定し、元のホストパスをターゲットに割り当ててマウントします。同じマウントポイントを2つのデータセットに割り当てたままにしないでください。データベースと依存サービスをアプリケーションのフロントエンドより先に起動し、エラーが正しいレイヤーを示すようにします。

最終sendが失敗した場合は、ソースを元のパスに再マウントしてスタックを再起動します。両方のコピーに新しい書き込みを混在させないでください。ロールバック条件は明確です。ソースはそのまま保持し、最終ストリームとプロパティの確認に合格するまで、ターゲットでは本番の書き込みを受け付けません。

変更していないパスでコンテナを検証する

コンテナランタイムからバインドマウントを確認し、代表的なファイルを開き、アプリ経由で一時ファイルを作成・削除し、所有者、ACL、拡張属性、空き容量の報告を確認します。スタックを2回再起動し、コンテナの起動前にZFSがマウントされることを確認します。

メンテナンス計画に従ってスクラブまたはその他のプール健全性チェックを実行しますが、それだけを移行の証明にしないでください。スナップショットGUIDまたは代表的なハッシュマニフェストを比較し、小さな項目を1つ復元して確認します。また、ソースの系譜を廃止する前に、ZimaSpaceのテストを使用して、中断後にZFSレプリケーションを再開できるかを確認します。

少なくとも1回、通常のバックアップとアプリケーションのサイクルが成功するまで、ソースを読み取り専用で保持します。コンテナが元のパスを使用し、スケジュールされたジョブが新しいデータセットを対象とし、レプリケーションが意図した系譜から継続され、ロールバックが不要になった場合にのみソースを廃止します。それ以外の場合は、マウントポイントを元に戻し、両方の履歴を保持します。

サポートとヒント

もっと読む

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.