インフラ・運用見積もり
フルと増分バックアップを残すと合計容量はいくら？
使うツール
バックアップの容量を『元データ×世代数』だけで計算すると、増分ファイルの分を落としやすくなります。反対に、毎日フルサイズを足してしまうと過大になります。何を一世代と呼ぶか、どのフルと増分を一緒に残すか、週のどこで容量を見るかを分けると、必要量を説明しやすくなります。
週一回フル、毎日増分、フル二世代
source: 100 GB
full interval: 168 hours
increment interval: 24 hours
retained full generations: 2
change per increment: 10%
compressed size: 100%
copies: 1
phase since latest full: 0 hoursこの条件では260GBです。フル二つが200GB、前のフルに続く六つの増分が60GBになります。増分一つは100GBの10%、10GBです。フルを作る時刻には増分を重ねて作らないモデルなので、週一回フルと毎日増分の組合せは、一周期でフル一つと増分六つです。『七日だから増分七つ』とは数えません。
ここでいう二世代は、復元ポイントが二つだけという意味ではありません。フル二つと増分六つで、計算上のバックアップポイントは八つです。製品の画面が『世代』を復元ポイント総数として使っている場合は、その設定値をこのフル世代数へそのまま写せません。言葉ではなく、何を残す設定かを確認します。
同じ二世代でも、週の後半は320GB
最新フルからの経過位置を0時間から144時間へ変えます。六日分の増分が新しいフルにも追加され、フル二つ、増分十二、合計320GBになります。同じ保持設定でも、観測時点で容量は変わります。最新フルを作った直後の結果だけを最大使用量だと考えないことが大切です。
このモデルの観測位置は、増分間隔の倍数で、次のフルより前を指定します。例では0、24、48、72、96、120、144時間です。次のフルが作られると新しい周期へ移ります。作成中の一時ファイルや、古いチェーンを削除する前の一時的な重なりまで再現するものではないため、設備容量の余裕は別に検討します。
期間外のフルが、期間内の増分に必要になる
期間保持モードで168時間を残し、観測位置を144時間にします。最新フルを時刻0とすると、保持したい最古の時点は-24時間です。その増分を復元するには、さらに前の-168時間に作られたフルと、その後の必要な増分が要ります。ツールはそのチェーンも残すモデルなので、二つのフルと十二の増分、320GBになります。
『七日より古いファイルは削除』という単純な整理では、残した増分から復元できなくなる可能性があります。実製品ではチェーンの統合や合成フルなど、別の保持方式もあります。このツールはそれらをすべて再現せず、周期的なフルと増分を残すモデルです。ファイルを手作業で削除する判断には使わず、対象製品の保持規則で管理してください。
変更率10%は、増分一回ごとの仮定
このモデルでは、増分一つを元データ容量×変更率で求めます。100GBの10%なら毎回10GBで、データ全体が毎日10%ずつ複利で増える計算ではありません。同じ場所が何度も変更されることもあるため、変更率を『一週間で新しく増えた容量』と同一視しないようにします。
増分間隔を24時間から12時間へ短くしても、10%を自動的に5%へ変えません。入力した率は新しい一回にも適用されます。取得頻度だけを変えて比較するときは、その間隔に対応する変更量を測るか、仮定を明記します。頻度が高いほど常に同じ総容量になる、とも、必ず比例して増える、とも決めつけないことが重要です。
圧縮とコピーを、チェーン全体へ適用する
260GBの条件で、圧縮後サイズを50%にすると130GBです。保存コピー数を2にすれば260GBへ戻ります。この欄は百分率なので、ログ保存容量の倍率0.5とは入力表現が違い、ここでは50を使います。フルと増分へ同じ圧縮率を使うモデルであり、重複排除や共有ブロックの効果は追加で推測しません。
元データの圧縮済みサイズを入力し、さらに同じ圧縮率を掛けると二重に小さく見積もります。元容量、変更量、圧縮後割合がどの段階の数値かをそろえます。物理容量と論理容量の違いがある製品では、製品が表示する容量の意味も確認してください。
容量が足りても、復元できることは別に確認する
この計算は、バックアップが定期的に成功し、必要なチェーンを保持できるという仮定です。失敗した取得、欠けたファイル、破損、暗号鍵の紛失、復元に必要な設定などは検証しません。必要容量を見積もった後は、実際の仕組みで復元試験を行い、復旧にかかる時間も別に確認します。
報告には総容量だけでなく、フル数、増分数、観測位置、保持方式を残すと、なぜその容量になったか説明できます。二世代という短い言葉を、実際に残すチェーンへ展開することが、このツールを使う一番の利点です。
古いフルを消す前に、どの増分が必要としているかを見る
保持日数だけを見て、期間より古いフルバックアップを消すと、期間内に残した増分から復元できなくなる場合があります。増分が差分だけを持つモデルでは、その出発点のフルも必要です。この画面の容量モデルは、保持する増分に必要なフルを含める考え方を示します。結果が『保持期間のデータ量』を単純に日数倍した値より大きくても、それは不要なファイルを数えたとは限りません。保持条件を満たす復元点と、その復元点を作るためのファイル群を区別します。
同じ保持設定でも、フルを取り終えた直後と、次のフルを取る直前では増分の数が違います。必要容量を一つの瞬間の値だけで決めると、週末に容量が足りなくなるかもしれません。この記事の260GBと320GBは、条件を変えずに確認位置を変えるだけで増える例です。実際のバックアップ製品が合成フル、重複排除、圧縮ブロックの共有を使う場合、その保存方法はこの単純なチェーンモデルと同じではありません。製品の実測が得られたら、どの仮定を置き換えられるかを確認します。
複製数を増やすと必要容量は増えますが、同じ障害で一緒に失われる場所へ置いたコピーが、期待した保護になるとは限りません。容量の計算ではコピーの置き場所、権限分離、復元手順の動作は確認していません。結果は保存領域の候補を検討する材料です。復元できるか、何時間で戻せるか、必要な時点が残るかは、それぞれの検証を別に用意します。『容量を計算したのでバックアップ設計が完成』という結論にはしないでください。