アプリデータ、バックアップ、ダウンロード用に個別のZFSデータセットを設定する方法

アプリデータ、バックアップ、ダウンロード用に個別のZFSデータセットを設定し、それぞれのワークロードに専用のマウントポイント、プロパティ、スナップショットポリシー、クリーンアップ範囲を割り当てます。

ホームサーバーでは、手軽なため、これらのフォルダーを最初は1つの大きな共有領域の下に置くことがよくあります。しかし後から、保持期間、権限、圧縮、recordsize、クォータ、復元方法をそれぞれ変える必要が生じます。そのため、安全な構成は、1つの負荷の大きいワークロードにすべての設定を左右される前に分離しておくことです。

各データセットで保護すべき対象を決める

まず、それぞれのワークロードの役割を確認します。アプリデータには一貫性のあるスナップショットと慎重な復元が必要です。バックアップには容量管理と保持期間の設定が必要で、ダウンロードには長期的な保護対象にせず、簡単に削除できる仕組みが求められます。

ZFSデータセットは、フォルダーであると同時に管理上の境界でもあります。圧縮、クォータ、予約領域、マウントポイント、スナップショットなどのプロパティをデータセット単位で管理できます。同じプール内にあってもワークロードを分離する価値があるのはこのためです。

作成前に、3つの役割を明確に書き出します。復元したいアプリの状態、保持したいバックアップデータ、削除または再ダウンロード可能なデータです。2つのフォルダーに同じ復元ポリシーとクリーンアップポリシーを適用できるなら、現時点では別のデータセットにする必要はないかもしれません。

データを移動する前に明確なマウントポイントを作成する

アプリと人の両方が分離構成を理解しやすいマウントポイントを選びます。たとえば、/srv/storageという親パスの下に、appdata、backups、downloads用の子マウントポイントを配置する方法があります。

OpenZFSのzfs-setドキュメントでは、zfs setを使ってデータセットプロパティを設定する方法が説明されています。また、より広範なプロパティのドキュメントでは、マウントポイントの動作とプロパティの継承について説明されています。これにより、共有するデフォルト値を親に設定し、異なる動作が必要な子データセットだけを上書きできます。

まず空のデータセットを作成し、想定どおりにマウントされることを確認してからデータを移動します。アプリケーションがまだ古いパスに書き込んでいる場合は中止してください。メンテナンス時間中にアプリケーションを移行すれば、問題が起きてもきれいにロールバックできます。

アプリデータには最も慎重なスナップショットポリシーを設定する

アプリデータは、データベース、設定ファイル、ユーザーアップロード、コンテナボリューム、アプリケーションの状態など、小さくても重要な変更が頻繁に発生します。1つのファイルを失うことはバックアップフォルダー全体を失うより気付きにくいかもしれませんが、誤った時点に復元するとアプリが壊れる可能性があります。

OpenZFSのプロパティドキュメントでは、データセット単位のプロパティを継承または上書きできることが説明されています。これにより、ダウンロードに同じ設定を強制することなく、アプリデータにより細かなスナップショットや異なる圧縮設定を適用できます。

アプリデータには、頻繁なスナップショット、慎重な削除、代表的なアプリ1つを使った復元テストを推奨します。アプリが稼働中のデータベースを使用している場合は、ファイルシステムのスナップショットだけでアプリケーション整合性が保たれると考えず、アプリ独自のバックアップまたは静止化方法と連携してください。

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

バックアップには容量制限と保持期間の境界を設定する

バックアップ専用のデータセットを用意すべき理由は、保持期間、重複排除メタデータ、合成フルバックアップ、レプリケーション、古いクライアントジョブなどによって、容量が気付かないうちに増える可能性があるためです。制限のないバックアップデータセットは、アプリやアクティブな共有領域に必要な容量を消費することがあります。

OracleのZFSプロパティガイドでは、クォータと予約領域をデータセット単位の制御として説明しています。これらは、バックアップの増加によって関係のないワークロードの領域が圧迫されるのを防ぐのに役立ちます。

バックアップデータセットにクォータ、または少なくともアラートのしきい値を設定し、スナップショットの保持期間をバックアップツール独自の保持設定に合わせます。バックアップアプリケーションがすでに削除したと判断しているバックアップファイルのために、ファイルシステムのスナップショットを永久に保持しないでください。

ダウンロードは再構築しやすく、削除しやすくする

ダウンロードは通常、最も重要度の低いデータセットです。多くのファイルは一時的なもの、再ダウンロード可能なもの、または整理前の一時保管データだからです。それでも専用の境界を設ける価値があります。ダウンロードはプールをすぐに満杯にする可能性があり、不要なスナップショットを継承することもあるためです。

ダウンロード専用のデータセットを使えば、長期保持を短縮または無効化し、ファイルの種類に応じて圧縮を調整し、アプリの状態やバックアップに触れることなくディレクトリをクリーンアップできます。

ダウンロードによって定期的に容量が不足する場合は、小さめのクォータまたはスケジュール式のクリーンアップを使用します。ファイルが重要になったら、使い捨て領域に長期データを残さず、新しい役割に合ったポリシーのデータセットへ移動してください。

分割後に権限、スナップショット、復元を確認する

データセットを作成しただけでは設定は完了していません。アプリが正常に起動し、バックアップが正しいデータセットに保存され、ダウンロードを安全にクリーンアップでき、スナップショットに想定どおりの境界が反映されて初めて完了です。

各クラスで1回ずつ復元チェックを行います。小さなアプリ設定を復元し、バックアップの復旧ポイントを一覧表示し、テスト用のダウンロードファイルを削除または整理します。これにより、データセットの境界と運用上の境界が一致していることを確認できます。

スナップショットにダウンロードが予期せず含まれていたり、アプリデータが含まれていなかったりする場合は、追加の自動化を行う前に中止し、マウントポイントまたはデータセットの割り当てを修正してください。理想的な完成形は退屈なものです。各ワークロードに、1文で説明できるポリシーが設定されています。

よくある質問

アプリデータとバックアップを同じデータセットに保存してもよいですか？

保持期間、クォータ、スナップショット、復元要件が本当に同じ場合に限ります。ほとんどのホームサーバーでは、アプリデータとバックアップに異なるポリシーを設定するべきです。

データがすでに存在する場合でも、データセットを分割できますか？

可能ですが、移行作業として扱ってください。新しいデータセットを作成し、書き込みを行うアプリやジョブを停止してデータを移動し、パスを更新してテストします。新しいマウントポイントを確認するまで、古いコピーを保持してください。

関連する計画作業として、データセットの境界がレプリケーション容量にどう影響するかを確認してください。ZimaSpaceの宛先プールがスナップショットレプリケーションで満杯になるのを防ぐ方法では、保持期間とデータセットの範囲を一緒に設計すべき理由が説明されています。