Chapter 2 — Backupと周辺技術の境界

ある会社では、業務システムのデータを2つのデータセンターへ常時複製していました。

さらに、ディスクは冗長構成になっており、1台が壊れてもサービスは止まりません。

担当者は、

「これだけ二重化していれば、バックアップは別に要らないだろう」

と考えていました。

ところがある日、片方のデータセンターで重要なファイルが誤って削除されました。

その変更は、ほぼ同時にもう一方のデータセンターへも反映されていました。

冗長化していたディスクにも、当然同じ状態が保たれていました。

つまり、二重化・複製・冗長化のいずれも、

「削除される前の状態」

を残してはいなかったのです。

このとき重要なのは、似ている技術に見えても、それぞれが守っているものは同じではないということです。Backupと、Replication、Snapshot、Archiveは、名前も機能も似て見えることがあります。しかし、何のためにあり、何を守り、何を守らないのかは、技術ごとに違います。この章では、これらの違いを整理します。

2.1 なぜ似ている技術を区別する必要があるのか

Chapter 1では、「バックアップがあるか」だけでなく、「必要になったときに戻せるか」が重要だと整理しました。この考え方は、Backup以外の技術にもそのまま当てはまります。

現場では、

• 複製している
• 冗長化している
• スナップショットを取っている
• 別の場所にも保存している

といった説明を、「バックアップと同じようなもの」として扱ってしまうことがあります。しかし、これらの技術は、それぞれ別の目的のために作られています。名前が似ていることと、守っている内容が同じであることは、別の問題です。

この章では、

• Replication
• Snapshot
• Archive
• Redundancy

を、Backupとの違いという観点から一つずつ整理していきます。

まだ、それぞれの技術の具体的な設計方法までは扱いません。まずは、それぞれが何を守り、何を守らないのかを区別できるようになることが目標です。

2.2 Replication — 何を守り、何を守らないか

Replication（レプリケーション）は、あるシステムのデータや状態を別の場所にも複製する仕組みです。可用性や耐障害性を高めるために利用されることがあります。その代表的な使い方の一つが、一方を利用できなくなったときにも別の側でサービスを継続できるようにすることです。

ここで注意が必要なのは、Replicationが何を複製しているかです。Replicationは、元のデータに起きた変更を、複製先へも反映する仕組みです。

そのため、元のデータが誤って削除されたり、壊れたりした場合、その変更が複製先にも反映されることがあります。構成によっては、変更がほぼ即座に複製先へ届くため、「削除される前の状態」が複製先にも残っていない、ということが起こり得ます。

これは、Replicationという仕組みの欠陥ではありません。Replicationは、そもそも「常に最新の状態を別の場所にも用意しておく」ことを目的とした技術だからです。

したがって、ReplicationとBackupは同じものではありません。Replicationは可用性を保つのに役立ちますが、それだけで「過去のある時点の状態に戻れること」までは保証されません。

2.3 Snapshot — 何を保持し、何を保証しないか

Snapshot（スナップショット）は、ある時点でのシステムやデータの状態を記録しておく仕組みです。「これを取っておけば、あとでこの時点の状態を確認したり、戻したりできる」という考え方で使われます。ここまでは、Backupの考え方と似ているように見えます。

しかし、Snapshotという名前がついているからといって、それだけで独立したBackup copyが存在するとは判断できません。

Snapshotは、元のデータと同じストレージ基盤に依存する構成もあります。その場合、基盤自体に障害が起きると、Snapshotも元のデータと一緒に影響を受ける可能性があります。Snapshotがあることと、独立したBackup copyがあることは、同じではありません。

もちろん、Snapshotが役に立たないという意味ではありません。ある時点の状態を素早く記録できることは、多くの場面で有用です。

ただし、それが元のシステムから独立した場所に保護されているかどうかは、Snapshotという名前だけでは分かりません。その仕組みが実際にどこへ、どのように保存されているのかを確認する必要があります。

2.4 Backupとの違いを整理する

ここまでの内容を、Chapter 1で整理したBackupの考え方と並べてみます。Chapter 1では、Backupとは、復旧に利用するためのデータや状態を保持することであると整理しました。

Replicationは、可用性を保つための仕組みであり、変更をそのまま伝えてしまう性質を持ちます。Snapshotは、ある時点の状態を記録する仕組みですが、名前だけでは独立した保護になっているかは分かりません。どちらも、それぞれの目的のためには有効な技術です。

しかし、「必要になったときに、必要な状態へ戻せるか」という観点で見ると、ReplicationやSnapshotだけでは足りない場合があります。

大切なのは、その技術が何のために存在し、何を保証していないのかを知っておくことです。

2.5 Archiveとの違い

Archive（アーカイブ）は、Backupとはさらに違う目的を持つ考え方です。Backupが「必要になったときに元の状態へ戻す」ことを目的とするのに対して、Archiveは、長期間保持し、将来必要になったときに参照・利用できるようにしておくことを主な目的としています。

ここでよくある誤解が一つあります。「長期間保存しているデータ」を、そのままArchiveと呼んでしまうことです。

しかし、長期間保存しているというだけで、自動的にArchiveになるわけではありません。保存している目的が、「復旧のため」なのか、「将来の参照や記録のため」なのかによって、扱い方は変わってきます。

BackupとArchiveは、同じストレージ技術や、同じ形式のコピーを使うことがあります。そのため、見た目だけでは区別しにくいこともあります。しかし、目的や管理の考え方が異なれば、それは別のものとして扱う必要があります。

また、特定の製品にある「アーカイブ用のモード」や「アーカイブ向けストレージ」といった名前がついているからといって、それが一般的なArchiveの定義そのものになるわけではありません。製品ごとの機能名と、Archiveという考え方そのものは、分けて考える必要があります。

Archiveと、法律や規則に基づく長期保存の関係については、この章では扱いません。後の章で改めて取り上げます。

2.6 Redundancy / Independent copy

Redundancy（冗長性）は、同じ役割を持つ構成要素を複数用意しておくことで、一つが使えなくなってもサービスを止めないようにする考え方です。ディスクの二重化や、サーバーの複数台構成などが、この一例です。Redundancyは、サービスを止めにくくするうえで役立ちます。

ただし、ここでも注意すべき点があります。現在の状態を複数持っていることと、以前の正常な状態へ戻れることは、同じではありません。冗長化された構成のどちらか一方に問題が起きた状態が、そのまま他方にも反映されてしまえば、「壊れる前の状態」はどこにも残っていない、ということが起こり得ます。

ここまで見てきた技術は、それぞれ役割が異なります。ただし、いずれも名前だけでは、独立したBackup copyとして必要なRecoveryを実現できるかまでは判断できません。

ここでは、「独立したコピー（independent copy）」という考え方についても触れておきます。これは特定の製品名や、決まった技術方式を指す言葉ではありません。障害や意図しない変更の影響を、元のデータと同時には受けにくい、独立性を持ったコピーを考えるための、一般的な整理の仕方です。ある技術が「これを満たせば独立したコピーである」と単純に決められるわけではなく、実際にどこに、どのように保存されているかによって変わります。

2.7 比較表 — Backup / Replication / Snapshot / Archive / Redundancy

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

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

なお、Backupの中にも、Full・Incremental・Differentialのように方式による違いがあり、それぞれRestoreの際に必要となる情報が異なります。この点は次の章で扱います。

2.8 まとめ — 何を見れば技術を区別できるか

この章では、Backupと似ている技術について整理しました。重要なのは、次の点です。

• ReplicationとBackupは同じものではない。可用性を支えるために使われ、構成によっては変更や削除も複製先へ反映される。
• Snapshotという名前だけでは、独立したBackup copyがあるとは判断できない。
• ArchiveはBackupとは目的が異なり、長期間保存しているというだけで自動的にArchiveになるわけではない。
• Redundancyは今の状態を複数持つ仕組みであり、過去の正常な状態へ戻れることを保証するものではない。

どの技術が使われているかを名前だけで判断せず、それが何を守っていて、何を守っていないのかを確認することが大切です。

次のChapter 3では、Backupの中でもFull・Incremental・Differentialといった方式の違いと、Restoreするときに必要になる依存関係について見ていきます。

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

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

• ReplicationとBackupの違いを、自分の言葉で説明できますか。
• Snapshotがあるだけでは独立したBackup copyとは言えない理由を説明できますか。
• ArchiveとBackupの目的の違いを説明できますか。
• Redundancyと、過去の状態へ戻れることの違いを区別できますか。
• 名前ではなく、何を確認すれば技術を区別できるか説明できますか。

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

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