ある組織には、何年も前から保存され続けているデータがあります。
誰もが、それを「Archiveだ」と呼んでいます。
しかし、よく確認してみると、次のことがはっきりしていません。
- なぜそれを保持しているのか
- 将来、どうやって見つけ出すのか
- どのようなlifecycle・disposition（処分）のルールが適用されるのか
ここで、一つの疑問が生じます。
「長く残しているだけで、それはArchiveと言えるのか。」
この章では、この問いについて考えていきます。
17.1 Chapter 2で見たBackupとArchiveの違い
Chapter 2では、BackupとArchiveの違いについて、すでに整理しました。
Backupが「必要になったときに元の状態へ戻す」ことを目的とするのに対して、Archiveは、長期間保持し、将来必要になったときに参照・利用できるようにしておくことを主な目的としています。
また、BackupとArchiveは、同じストレージ技術や、同じ形式のコピーを使うことがあります。そのため、見た目だけでは区別しにくいこともあります。しかし、目的や管理の考え方が異なれば、それは別のものとして扱う必要があります。この点も、Chapter 2ですでに見たとおりです。
この章では、この違いをさらに掘り下げ、Archiveという考え方の中身と、Retentionという考え方について整理していきます。
Chapter 2では、「Archiveと、法律や規則に基づく長期保存の関係については、この章では扱いません。後の章で改めて取り上げます」と述べました。この章でも、法律や規則に関する内容までは扱いません。それは、Chapter 18で改めて扱います。
17.2 長く残せばArchiveになるわけではない
Chapter 2では、次のように整理しました。
長期間保存しているというだけで、自動的にArchiveになるわけではありません。
この考え方は、この章でも変わりません。
「何年も前のデータだから、それはArchiveだ」という判断は、それだけでは十分ではありません。保存期間の長さだけで、BackupとArchiveの区別が決まるわけではありません。
区別の基準になるのは、保存している目的や、そのデータをどのように管理していくかという考え方です。同じように長期間保存されているデータであっても、それが「復旧のための予備」として管理されているのであれば、それは依然としてBackupの一部として扱われる場合があります。逆に、「将来の参照や記録のため」という目的が明確で、それに応じた管理が行われているのであれば、Archiveとして扱われる場合があります。
つまり、期間の長さではなく、何のために、どのように保持・管理しているかが問われることになります。
17.3 Archiveとlifecycle management
では、Archiveとして何かを管理するとは、具体的にどういうことでしょうか。
Archivingは、長期間の保持を伴うだけでなく、情報のlifecycle management（ライフサイクル管理）を支える場合があります。これは、あるデータが作成されてから、最終的にどう扱われるまでを、一連の流れとして管理する考え方です。
Archiveは、この流れの中で、record search（記録の検索）やdata discovery（データの発見）、そしてretention（保持）やdisposition（処分）といった要素を、組織の要件に応じて支える場合があります。
ただし、ここで注意しておきたいことがあります。すべてのArchiveが、同じ検索機能を持っているとは限りません。また、Archiveとして扱われているというだけで、それが自動的に法的要件を満たしている、証拠としての性質を持っている、あるいは改変できない状態になっている、ということも意味しません。これらは、それぞれ別に確認する必要がある性質です。
17.4 Search / discoveryは何のためにあるのか
Archiveがlifecycle managementを支えるという話の中で出てきた、record searchやdata discoveryについて、もう少し考えてみます。
長期間保持した情報を将来参照・利用するうえでは、必要な情報を後から検索・発見できるかどうかも重要な観点になります。
そのため、Archiveの文脈では、後から必要な情報を検索・発見できることが、重要な観点として扱われる場合があります。
ただし、これは「Archiveであれば必ず検索機能が備わっている」という意味ではありません。検索・発見のしやすさは、実際にどのような仕組みで管理されているかによって変わります。単に検索可能なストレージに保存されているというだけで、それが自動的にArchiveと呼べるわけでもありません。保存先が検索可能であることと、それが長期的な保持・管理の目的を持ってArchiveとして扱われていることは、別の話です。
17.5 RetentionだけでなくDispositionも考える
Archiveというと、「とにかく残しておくもの」というイメージを持たれることがあります。
しかし、Archiveのlifecycle managementには、retention（保持）だけでなく、disposition（処分）も含まれ得ます。
Archiveは、「永遠にすべてを残しておくもの」として教えるべきではありません。disposition（処分）をどう扱うかも、lifecycle managementの一部になり得ます。
Chapter 1とChapter 3で触れたBackup / Recovery Windowを考える保持と、ここで扱うArchiveのretention / dispositionは、関連していても同じ観点ではありません。
ここで、法律や規則に基づく具体的な保持期間や、処分の義務については、この章では扱いません。特定の法令が求める保持期間や、法的な保持義務（legal hold）、プライバシーに関する削除の要件、契約上の削除条件といった内容は、Chapter 18で改めて扱います。この章で押さえておきたいのは、Archiveのlifecycle managementには、retentionだけでなくdispositionも含まれ得るという点です。
17.6 同じStorageを使っていても同じものではない
Chapter 2でも見たように、BackupとArchiveは、同じストレージ技術や、同じ形式のコピーを使うことがあります。
この章でも、改めてこの点を確認しておきます。
Backup用に使われているストレージと、Archive用に使われているストレージが、技術的には同じ仕組みを使っていることがあります。同じ媒体や、同じ形式のコピーが、BackupとしてもArchiveとしても使われることがあります。
しかし、実装が重なっているからといって、BackupとArchiveの目的や管理モデルが同じになるわけではありません。
技術的な実装が似ていても、「何のために保持しているのか」「どのように管理していくのか」という点が異なれば、それらは別のものとして扱う必要があります。
なお、Chapter 8で見たImmutable（改変不可）な保護についても、ここで一つ確認しておきます。Immutableなストレージに保存されているというだけで、それが自動的にArchiveになるわけでもありません。Immutableという性質は、変更や削除に対する保護の話であり、Archiveとしての目的や管理モデルとは、別の観点です。
17.7 VendorのArchive labelを一般定義にしない
最後に、もう一つ注意しておきたい点があります。
特定の製品やサービスには、「Archive tier」「Archive mode」「cold/archive storage」といった名前がついた機能が用意されていることがあります。
Chapter 2でも触れたように、特定の製品にある「アーカイブ用のモード」や「アーカイブ向けストレージ」といった名前がついているからといって、それが一般的なArchiveの定義そのものになるわけではありません。製品ごとの機能名と、Archiveという考え方そのものは、分けて考える必要があります。
ある製品の「Archive」という名前がついた機能を使っているからといって、それだけで、この章で見てきたようなArchiveの一般的な性質（lifecycle management、search/discovery、retention/dispositionなど）をすべて満たしているとは限りません。
製品名やストレージの階層名（tier名）は、その製品固有の機能を表すラベルであり、Archiveという考え方全体を定義するものではないという点を、改めて確認しておいてください。
17.8 まとめ
この章では、Chapter 2で見たBackupとArchiveの違いをさらに掘り下げ、Archiveのlifecycle managementや、Retentionという考え方について整理しました。
重要なのは、次の点です。
- 長期間保存しているというだけで、自動的にArchiveになるわけではない。何のために、どのように保持・管理しているかが問われる。
- Archiveは、information lifecycle management、record search/data discovery、retention/dispositionを、組織の要件に応じて支える場合がある。ただし、これらの性質がすべてのArchiveに自動的に備わっているわけではない。
- Archiveは、「永遠にすべてを残しておくもの」として考えるべきではない。retentionだけでなく、dispositionもlifecycle managementの一部になり得る。
- BackupとArchiveが同じストレージ技術や媒体を使っていても、それだけで目的や管理モデルが同じになるわけではない。Immutableな保護も、Archiveの目的や管理モデルとは別の観点である。
- 製品の「Archive」という機能名やストレージのtier名は、Archiveという考え方全体の一般的な定義にはならない。
- 法律や規則に基づく具体的な保持期間や、legal hold、プライバシーに関する削除、契約上の削除条件については、この章では扱わない。それらはChapter 18で扱う。
この章で確認する代表的な観点
ここまでの内容を、簡単な表として整理します。
| 観点 | Backupで重視されること | Archiveで重視されること |
|---|---|---|
| Purpose | 必要になったときに元の状態へ戻せるようにする | 長期間保持し、将来の参照・利用に備える |
| Lifecycle management | 実装による | retentionとdispositionの両方を含み得る |
| Search / discovery | 実装による | 後から情報を検索・発見できることが重要になる場合がある |
| Retention | Recoveryの要件との関係で設計される | 組織の長期的な要件との関係で設計される |
| Disposition | 実装による | dispositionもlifecycle managementに含まれ得る |
| Implementation overlap | 同じストレージ技術・媒体をArchiveと共有し得る | 同じストレージ技術・媒体をBackupと共有し得るが、目的・管理モデルは別 |
この表は、BackupとArchiveの間で重視される観点の違いを整理した、この本での一つの目安であり、どちらか一方に必ず当てはまる普遍的な性質を示すものではありません。実際にどの性質が当てはまるかは、実装や組織の管理方法によって変わります。
Chapter 17を読み終えた時点で考えてみてください
自分が担当しているシステムやデータについて、次の質問に答えられるでしょうか。
- 「長く保存している」というだけでは、なぜそれをArchiveと呼べないのでしょうか。
- Archiveのlifecycle managementには、retention以外にどのようなものが含まれ得るでしょうか。
- 検索可能なストレージに保存されていることと、それがArchiveであることは、なぜ同じではないのでしょうか。
- 製品の「Archive tier」や「Archive mode」といった名前が、一般的なArchiveの定義にならないのはなぜでしょうか。
- この章が、法律や規則に基づく保持期間について扱わなかったのはなぜでしょうか。
答えに詰まった項目があれば、保持期間だけでなく、目的と管理モデルの違いから見直してください。