Chapter 3 — Backup方式とRestore依存関係

ある会社では、あるシステムについて、Full backupを月に一度取得し、それ以外の日はIncremental backupを取得する運用を続けていました。

ストレージには、直近数か月分のFull backupと、その間の毎日のIncremental backupが、数十個単位で残っていました。

担当者は、「これだけbackup fileが残っていれば、どの時点にでも戻せるだろう」と考えていました。

ところがある日、特定の時点までRestoreする必要が生じ、実際に作業を始めたところ、途中のIncremental backupの一つが壊れていて使えないことが分かりました。

Full backup自体は存在します。それより前後のIncremental backupも、多くは存在します。

しかし、その壊れた1つを経由しなければ届かない時点については、期待していた通りにはRestoreを進められませんでした。

このとき担当者が気づいたのは、次のことです。

「backup fileが複数残っていること」と、「必要なRestoreがそのまま成立すること」は、同じではありません。

Backupを取得する方式が違えば、Restoreのときに何が必要になるかも変わります。この章では、その関係を見ていきます。

3.1 Backup方式が違うとRestoreも変わる

Chapter 1では、Backupが存在するというだけでは、必要なときにRecoveryできることを意味しないと確認しました。

この章では、その考え方をさらに一歩進めます。Backupには、取得の仕方によっていくつかの代表的な方式があり、方式が違えば、Restoreのときに何を必要とするかも変わってきます。

ここで扱うのは、主に次の3つの代表的な考え方です。

• Full Backup
• Incremental Backup
• Differential Backup

この章では、Full Backup、Incremental Backup、Differential Backupを代表的なBackup方式として扱います。ただし、ここで示すモデルは代表的な整理であり、すべての製品や実装がまったく同じ仕組みで動くとは限りません。

この章では、それぞれの方式が「何を取得するか」だけでなく、「Restoreのときに何を必要とするか」という観点から整理していきます。

3.2 Full Backup

Full Backupは、その時点で必要な対象のすべてを、まとめて取得しておく考え方です。

Restoreを行う際は、代表的な構成では、そのFull Backup自体をRestoreの基点として利用します。

Restore dependencyという観点で見ると、Full Backupは代表的なモデルとして比較的単純です。Restoreに必要となる要素が、基本的にはそのFull Backup自体に閉じている構成が代表的だからです。

ただし、これは「Full Backupなら必ず安全」「Full Backupだけが正解」という意味ではありません。

Full Backupにも、対象の規模によっては取得や保存に一定のコストがかかる場合があります。また、Full Backup自体が壊れていたり、利用できなかったりすれば、Restoreはやはり成立しません。

「Restoreに必要な要素が少なくて済む代表的な構成である」ということと、「あらゆる場面で最も優れている」ということは、別の話です。この点は3.8で改めて整理します。

3.3 Incremental Backup

Incremental Backupは、前回のBackup（Full Backup、または前回のIncremental Backup）以降に生じた変更分だけを取得する、という考え方です。

ここで重要なのは、Restoreのときの話です。

ある時点までRestoreしようとする場合、代表的な構成では、基点となるFull Backupと、その後に必要な一連のIncremental Backup（Incremental chain）の両方が必要になります。

例えば、Full Backupの後に3回Incremental Backupを取得していたとして、3回目の時点までRestoreしたい場合には、Full Backupと、1回目・2回目・3回目のIncremental Backupが、代表的な構成ではすべて必要になります。

つまり、「取得時に何を保存するか」と「Restore時に何へ依存するか」は、分けて考える必要があります。 Incremental Backupでは、代表的な構成として、Restore時に複数のbackup setへの依存が生じます。

3.4 Differential Backup

Differential Backupは、基点となるFull Backup以降に生じた変更分を、都度まとめて取得する、という考え方です。

Incremental Backupとの違いは、「前回のBackupからの変更分」ではなく、「基点となるFull Backupからの変更分」を、毎回まとめて取得する点にあります。

Restoreのときの代表的な構成は、基点となるFull Backupと、対象時点に対応する1つのDifferential Backupです。

代表的な構成では、Incremental Backupのように複数のBackupを順番につなげる必要は生じません。

ここでも、詳細な実装や挙動は製品や構成によって異なる場合があります。この章では、Restore dependencyを理解するための代表的な考え方として扱います。

3.5 Restore dependencyを比較する

ここまでの内容を、簡単な表として整理します。

この表はあくまで代表的な整理のための目安です。実際の構成や製品によって、当てはまり方は変わります。

重要なのは、それぞれの方式について、「何を取得するか」だけでなく、「Restoreのときに何を必要とするか」を分けて考えることです。

3.6 Chainが途中で使えない場合

3.3で見たように、Incremental Backupを使ったRestoreでは、代表的な構成として、Full Backupとその後の一連のIncremental Backupへの依存が生じます。

ここで考えたいのは、この一連のBackup（chain）の一部が、欠けていたり利用できなかったりする場合です。

次のような、あくまで理解のための簡略化した図で考えてみます。

Teaching Diagram（簡略化した概念図であり、特定製品の仕様を示すものではありません）

正常な場合:
[Full] → [Incremental 1] → [Incremental 2] → [Incremental 3]

Incremental 2が利用できない場合:
[Full] -> [Incremental 1] -> [Incremental 2] -> [Incremental 3]
                                  X

[Full + Incremental 1] までの時点: OK
[Incremental 2] を必要とする時点: affected

Incremental 2が利用できない状態では、代表的な構成において、Incremental 2を経由する必要がある時点（この例ではIncremental 2やIncremental 3に対応する時点）へのRestoreが、期待通りには進められない場合があります。

ここで押さえておきたいのは、次の点です。

Restoreに必要な依存関係の一部が欠けている場合、それに基づくRestoreが期待通りに進められないことがあります。

ただし、これは「1つでも欠ければ必ずすべてのRestoreが不可能になる」という意味ではありません。影響の範囲は、欠けた要素がどの時点に関わるものか、どの方式を使っているか、どのような実装かによって変わり得ます。例えば、Full Backup自体やIncremental 1が無事であれば、Incremental 1に対応する時点までのRestoreには影響しない場合もあります。

Differential Backupの場合は、代表的な構成では依存する要素がFull Backupと1つのDifferential Backupに限られるため、Incremental Backupのように多数の要素が連なった依存関係にはなりにくいとされています。ただし、そのFull BackupやDifferential Backup自体が利用できなければ、当然Restoreは成立しません。

いずれの方式でも共通して言えるのは、「必要な対象時点までRestoreできるかどうか」は、単に「backup fileが残っているかどうか」ではなく、「その方式が必要とする依存関係が、実際に成立するかどうか」で決まる、ということです。

3.7 Recovery WindowとRestore dependency

Chapter 1では、Retentionを「何世代残しているか」だけで考えるのではなく、「どこまで過去に戻れる必要があるか」というRecovery Windowの考え方で捉える必要があることを見ました。

この章の観点から見ると、Recovery Windowを実際に成立させるためには、Restore dependencyも確認する必要があります。

ある時点までRestoreするためには、単にその時点に近いbackupが残っているだけでは足りません。その方式がRestoreのために必要とする一連のbackup set（Full Backup、必要なIncremental、対応するDifferentialなど）が、実際にすべて保持され、かつ利用できる状態になっている必要があります。

つまり、Recovery Windowを設計するときには、「その時点のbackupが残っているか」だけでなく、「その時点までRestoreするために必要な依存関係一式が、保持されているか」まで考える必要があります。

一例として、Oracle Databaseの公式ドキュメントでは、RMAN（Recovery Manager）のretention policyとして、redundancy（保持数）に基づく方式と、Recovery Windowに基づく方式の2つが文書化されており、いずれかを選択する形で構成できることが示されています。これは特定製品における設計例であり、すべてのBackup製品に共通する普遍的なルールではありませんが、「何世代残すか」と「どこまでの期間、必要な依存関係ごと戻れるか」が、別の観点であり得ることを示す一例です。

3.8 方式に単純な優劣はない

ここまで、Full / Incremental / Differentialのそれぞれについて、代表的なRestore dependencyの違いを見てきました。

ここで注意したいのは、Full / Incremental / Differentialのあいだに、あらゆる場面で当てはまる単純な「一番良い方式」はない、ということです。

例えば、次のような要素は、方式によって異なります。

• Restore時に必要となる依存関係の複雑さ
• どれくらいの頻度でBackupを取得する運用か
• どれくらいの期間、Retentionとして保持する必要があるか
• 実際に使っている製品や実装の仕様

これらは、システムや運用の要件によって重要度が変わります。したがって、「Differentialのほうが常に優れている」「Fullが常に最も安全」といった一律の優劣付けは、この章では行いません。

方式の選定は、こうした複数の観点を踏まえて考える必要がある、というのがこの章の立場です。具体的な選定方法そのものは、この章の範囲を超えます。

3.9 まとめ

この章では、Backupの取得方式によって、Restoreのときに必要となる依存関係が異なることを整理しました。

重要なのは、次の点です。

• Full Backupは、代表的な構成ではRestoreに必要な要素が比較的単純だが、それだけで常に最善とは限らない。
• Incremental Backupは、代表的な構成では基点のFull Backupと一連のIncremental chainへの依存が生じる。
• Differential Backupは、代表的な構成では基点のFull Backupと対応する1つのDifferentialへの依存が生じる。
• 依存関係の一部が欠けていたり利用できなかったりすると、それに基づくRestoreが期待通りに進められない場合がある。
• 「backupが複数残っていること」と、「必要なRestore chainが成立すること」は、同じではない。
• Recovery Windowを考えるときは、対象時点のbackupだけでなく、その時点までRestoreするために必要な依存関係一式が保持されているかまで考える必要がある。
• 方式に単純な優劣はなく、複数の観点を踏まえて考える必要がある。

実際にRestoreが確実に成立するかどうかを確認する方法については、後のRecovery Test / Exerciseの章で改めて扱います。

次のChapter 4では、技術的なBackup設計に入る前に、そもそも何を守る必要があるのか、業務影響の観点から考えるBIA（Business Impact Analysis）について見ていきます。

Chapter 3を読み終えた時点で考えてみてください

自分が担当しているシステムについて、次の質問に答えられるでしょうか。

• Full / Incremental / Differentialの違いを説明できますか。
• IncrementalをRestoreするとき、なぜ複数のbackup setが関係することがあるのか説明できますか。
• DifferentialとIncrementalのRestore dependencyの違いを説明できますか。
• backup fileが複数残っていても、Restoreできない場合があるのはなぜか説明できますか。
• 方式を単純な優劣だけで選べない理由を説明できますか。

すべて答えられなくても問題ありません。

むしろ、答えに詰まった点があれば、それがこの章で確認しておくべきポイントです。