スナップショットのレプリケーションによる保存先プールの容量逼迫を防ぐ方法

保持されているスナップショットと変更ブロックの蓄積速度が、保存先のクリーンアップポリシーによる解放速度を上回ると、スナップショットレプリケーションによって保存先プールがいっぱいになります。

予防策は、ソースの保持期間、保存先の保持期間、レプリケーションの実行間隔、空き容量アラームを1つのポリシーとして設計することです。レプリカがソースより多くの履歴を正当に保持する場合もありますが、その選択には上限を設ける必要があります。増分の基点として必要なスナップショット、古いスナップショットが固定している一意のデータ量、ブックマークでソース上のローカルスナップショットの一部を置き換えられるか、次の大規模な変更セットが到着するまでにどれだけ余裕があるかを追跡してください。

保存先の保持ポリシーを明示的に設定する

保存先で保持する毎時、毎日、毎週、毎月の復元ポイント数を決め、その履歴がソースと異なる理由を文書化します。ソースで古いスナップショットを削除すれば、レプリケーションソフトウェアが保存先の古いスナップショットもすべて自動的に削除すると考えてはいけません。

ZFSレプリケーションの概要では、レプリケーションにはスナップショットポリシーが必要だと説明されています。スナップショットは復旧ポイントであると同時に、増分転送の境界でもあるためです。

具体的な復旧価値がない限り、変更の多いデータセットには最も短い保持期間を適用します。変更の少ないアーカイブは別のスケジュールで保持し、頻繁な復元ポイントの価値がほとんどない場所で、1つのグローバルポリシーが容量を浪費しないようにします。

古いスナップショットが固定する変更量を見積もる

大規模な削除、移動、メディアの交換、VMの書き換えの前後で、スナップショットのUSED、スナップショット間の書き込みデータ量、保存先プールの空き容量を測定します。ライブデータが消えた後も、スナップショットによって古いブロックが保持されることがあります。

TrueNASのレプリケーションに関する注記では、現在のライブデータセットが小さくなっても、スナップショットの変更によって古いブロックが保持されると警告しています。

この変更率を使って保持期間を決めます。急速に変化するVMイメージを30日間保持する保存先は、ライブサイズが同じでも、ほぼ追記のみの家族写真用データセットよりはるかに大きな容量を必要とする場合があります。

次回のレプリケーション用にプールの空き容量を確保する

現実的に想定される最大の受信増分データ、ローカルスナップショットの増加量、通常のファイルシステムオーバーヘッドを考慮して、運用上の空き容量下限を設定します。プールがほぼ満杯になってからではなく、その下限に達する前に警告を出してください。

Oracleのスナップショット保持に関する説明では、スナップショットの作成が当初は低コストだからといって無料とみなすのではなく、保持設定によってスナップショットの増加を制御すると説明しています。

保存先が緊急状態に達する前に、重要度の低いデータの保持期間を一時停止または短縮します。レプリケーション先には新しいブロックを受信して確定するための余裕が必要です。そのため、現在のライブデータセット分しか空き容量を残さない計画は安全ではありません。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

増分履歴を維持できる場合はブックマークを使用する

ZFSのバージョンとレプリケーションツールがブックマークをサポートしている場合、古いソーススナップショットがローカルの完全な復元ポイントとして不要になった後も、ブックマークで増分送信の参照を維持できるか検討します。

オフサイトバックアップの設計では、ブックマークが増分の基点を維持する方法を示しています。これにより、スナップショットの保持設定を独立して管理できます。

すべてのスナップショットをブックマークに置き換えてはいけません。保存先の復元履歴には実際のスナップショットが必要であり、レプリケーションツールによって共通の基点の管理方法も異なります。保存先の復旧目標を弱めることなく、ソース側を簡素化できる場合にのみブックマークを使用してください。

レプリケーションに必要なスナップショットだけを保護する

削除を行う前に、ソースと保存先で共有されている最新の共通スナップショットを特定します。ツールがホールドまたは同等の保護機能を使用する場合は、クリーンアップジョブがそれらを尊重し、不要になったホールドが最終的に解除されることを確認してください。

FreeBSDのZFSハンドブックでは、ホールドが共有スナップショットを保護するのは、ホールドが明示的に解除されるまでだと説明しています。

必要な共通基点が1つあるからといって、すべての過去のスナップショットを保持する必要はありません。レプリケーションに実際に必要な少数のスナップショットだけを保護し、それより古く独立した復元ポイントは保存先の保持ポリシーに任せます。

バックアップ履歴とは分けてレプリケーション用スナップショットを監査する

ツールによっては、スケジュール設定した毎時または毎日のスナップショットに加えて、独自の同期用スナップショットを作成します。保存先でこの2種類を一覧表示し、ツールが生成したスナップショット群がクリーンアップルールなしに増え続けないようにします。

SanoidとSyncoidに関する議論では、同期用スナップショットが安全策として機能するのであり、すべてのレプリケーション用スナップショットが長期バックアップ履歴を目的としているわけではないと説明しています。

保存先を毎月、または大規模なデータセット移動の後に確認します。想定した復元ポイントが残り、次回の増分に有効な共通基点があり、プールの空き容量が設定した下限を上回っていれば、ポリシーは健全です。保存先がすでに予想外に満杯になっている場合は、スナップショット容量の診断に関する関連ZimaSpace記事が復旧への分岐点になります。

よくある質問

保存先ではソースとまったく同じスナップショットを保持すべきですか？

必ずしもそうする必要はありません。バックアップ先でより長い履歴を保持することは可能ですが、その違いは意図的で、容量を検証済みであり、独自の保持ポリシーによって管理されるべきです。

ソースでファイルを削除すれば、保存先の容量はすぐに解放されますか？

いいえ。レプリケーションされたスナップショットは、ライブファイルが消えた後も古いブロックを参照し続けることがあります。保持されているスナップショットやその他の参照がそれらのブロックを必要としなくなった場合にのみ、容量が解放されます。

最も古いスナップショットを削除すれば、常に最大の容量が解放されますか？

いいえ。スナップショットの容量は複数の復元ポイントで共有されています。一意に参照されている容量を見積もるか測定し、増分レプリケーションにまだ必要な共通スナップショットを保護してください。