バックアップとアーカイブの違いとは？保存目的・期間・復旧要件で整理

バックアップとアーカイブが混在する現場で起きること

はじめに押さえておきたいのは、多くの現場で困りごとが起きるのは、バックアップとアーカイブを区別しないまま運用しているためだ、という点です。

よくあるのは、こんな状況です。日々のバックアップは動いている。ところが数年前の契約書や図面を監査や取引先対応で求められたとき、「その時点のデータ」がどこにも残っていない。あるいは逆に、念のためとバックアップを何世代も長期保持し続けた結果、ストレージが逼迫し、どれを消してよいか誰も判断できなくなる。どちらも、目的の異なる 2 つの仕組みを 1 つの運用に押し込めたときに起きやすいものです。

判断のポイントは、いま保存しているデータが「元に戻すため」なのか「残して後から参照するため」なのかを切り分けることです。この切り分けをしないまま容量やコストの相談を始めると、議論が噛み合わなくなります。

ここで注意したいのは、「バックアップを長く残せばアーカイブの代わりになる」という考え方です。一見合理的に見えますが、バックアップは最新の状態を復旧するための仕組みであり、長期保管・検索・改ざん防止といったアーカイブに求められる要件を満たすとは限りません。次章から、まず両者の定義を整理していきます。

バックアップとアーカイブの違いを目的から整理する

要点は、バックアップは「元に戻す」ための仕組み、アーカイブは「長期に保管・参照する」ための仕組みで、目的そのものが違うということです。

バックアップは、障害・誤操作・ランサムウェアなどでデータが失われたときに、ある時点の状態へ復旧することを目的とします。守りたいのは事業の継続性で、関心の中心は「どれだけ早く・どの時点まで戻せるか」にあります。一方アーカイブは、法令対応や監査、業務上の長期参照のために、データを長期間そのまま保管しておくことを目的とします。関心の中心は「何年残すか・改ざんされずに取り出せるか」です。

両者の違いを整理すると、次のようになります。

向いているケースを整理すると、日々更新される業務データや基幹システムの復旧はバックアップ、会計書類や契約書、設計データなど「後から原本として参照する」データはアーカイブが適します。逆に、頻繁に上書きされるデータをアーカイブに固定しても意味は薄く、長期参照が目的のデータをバックアップの世代管理だけで賄おうとすると、保持期間の設計に無理が生じます。

注意点として、「コピーを取る」という動作が同じでも、更新頻度・保持期間・求められる要件は異なります。同一視すると、後述する保存先やコストの設計を誤りやすくなります。

区別が難しい理由と、判断を誤りやすいポイント

なぜ両者の使い分けが難しいのか。理由はシンプルで、どちらも「データのコピー」に見えるからです。

現場で判断がぶれるのは、コピーという行為の表面だけを見てしまうときです。復旧を速くしたいのか、それとも長期の保存性や改ざん耐性を確保したいのか。求めるものが違えば、最適な保存先も保存方式も変わります。ところが「とりあえずコピーがあれば安心」という感覚で進めると、この違いが見えなくなります。

判断ミスが起きやすいポイントを、2 つ挙げておきます。1 つは、バックアップを長期保持してアーカイブ代わりにするケースです。世代が積み上がって容量とコストが膨らみ、しかも古い世代から目的のファイルを探し出すのは容易ではありません。もう 1 つは、コスト削減のためにアーカイブを安価なコールドストレージへ寄せたものの、いざ取り出そうとすると時間や追加費用がかかり、必要なときにすぐ参照できないケースです。

つまり、アクセス頻度と復旧要件を取り違えると、コスト過多になるか、参照・復旧が遅れるか、どちらかに振れてしまいます。この失敗を避けるために、次章では判断の軸を整理します。

RPO/RTO と保存期間で使い分けを設計する

ここが本記事の中心です。バックアップとアーカイブは、RPO/RTO と保存期間という別々の軸で設計する、と考えると整理しやすくなります。

まず RPO/RTO は、主にバックアップ設計の軸です。

• RPO (目標復旧時点):
  障害時に、どの時点のデータまで戻せればよいか。言い換えると、どれだけのデータ損失を許容できるか。

• RTO (目標復旧時間):
  障害発生から、どれくらいの時間で復旧させる必要があるか。どれだけの停止時間を許容できるか。

RPO を短くするほど取得頻度を上げる必要があり、RTO を短くするほど復旧の速い構成が求められます。これらは事業への影響度から逆算して決める要件です。

一方、保存期間はアーカイブ設計の軸です。何年残すかは、法令・監査・社内規程・業務上の参照といった「なぜ残すか」から決まります。ここには RPO/RTO とは異なる論点として、改ざん防止 (イミュータブル) の要否や、保存期間が満了したデータをいつ・誰の承認で削除するか、という削除ルールまで含まれます。

判断のポイントは、この 2 軸を分けて要件化することです。「基幹システムは RPO 1 時間・RTO 4 時間」というのはバックアップの要件であり、「会計書類は 7 年保存・満了後に承認削除」というのはアーカイブの要件です。両者を混ぜて 1 つのルールにまとめようとすると、必ずどこかに無理が出ます。

注意点として、RPO/RTO と保存期間は独立した軸です。片方だけで設計すると、復旧はできるが長期保存の根拠が説明できない、あるいは長期保存はしているが復旧速度が要件を満たさない、といった要件漏れが起きます。

なお、決めた RPO/RTO を実際にどう保存へ落とし込むかについては、コピーの数・媒体・保管場所を定める [321 ルール] の考え方が土台になります。あわせて確認すると、保存方式まで含めた設計に進めやすくなります。

保存目的別に見る保存先と方式の比較

要点は、バックアップ用とアーカイブ用では重視する条件が異なるため、保存先も分けて検討したほうが整理しやすい、ということです。

保存先を選ぶときの評価軸は、主に復旧速度・容量単価・改ざん耐性・取り出し頻度の 4 つです。用途ごとの目安を整理すると、次のようになります。

この軸で見ると、バックアップは復旧速度と改ざん耐性のバランスが取れた保存先、アーカイブは容量単価が低く長期保存・改ざん防止に向いた保存先、という方向で検討することになります。オブジェクトストレージのイミュータブル機能を長期保管に使う、といった選択肢も、この整理の延長線上にあります。

向いているケースと向いていないケースも押さえておきます。頻繁に参照するデータを取り出しの遅いコールドストレージに置くと、必要なときに待たされます。逆に、めったに参照しない長期保管データを高速・高単価な保存先に置き続けると、コストが見合いません。用途を取り違えないことが、無駄のない設計につながります。

注意点として、安価なコールドストレージは取り出しに時間や費用がかかる場合があります。月額の保存単価だけで判断せず、取り出し時の条件まで含めて確認することが望まれます。

運用で見落としやすい注意点

保存先を決めた後にこそ、見落としやすい論点があります。設計より運用フェーズで問題化しやすいポイントを整理します。

第 1 の注意点

バックアップは「取れている」ことではなく「戻せる」ことが目的だ、という点です。現場でよくあるのが、バックアップジョブは正常終了しているのに、いざ復旧しようとすると手順が分からない、あるいはデータが壊れていて戻せない、というケースです。戻せるかどうかは、実際に復旧テストをしてみないと分かりません。テストの頻度・担当者・記録方法まで決めておくことが望まれます。

第 2 の注意点

 改ざん防止です。ランサムウェアは、オンラインでつながったバックアップやアーカイブも暗号化の対象にします。書き換えできないイミュータブルな保存や、ネットワークから切り離した保管を、必要なデータに対して用意しておくと、被害時に戻せる可能性が高まります。こうしたランサムウェア対策を、自社が現状どこまで整理できているかを見極める段階では、ランサム NAVI ドック のように「診断を受ける前に整理すべきこと」からたどる方法もあります。  

第 3 の注意点

保存期間が満了したデータの削除ルールです。残すルールだけを決めて消すルールを決めないと、データは増え続けます。いつ・誰の承認で削除するかを運用に組み込んでおくことが必要です。

そして、これらはツールだけでは解決できない論点でもあります。どれほど高機能な製品を導入しても、復旧テストを実施する人、記録を残す体制、担当者が代わっても引き継げる手順がなければ、いざというときに機能しません。運用体制の整備までを含めて設計することが、実務では欠かせません。

使い分けを実務に落とすステップ

最後に、ここまでの整理を実務の手順に落とし込みます。要点は、いきなり保存先の製品を選ぶのではなく、データの棚卸しから順に進める、ということです。

進め方の一例は、次のとおりです。

1. データの棚卸し: 社内にどのようなデータがあるかを洗い出す。

2. 目的分類: それぞれを「戻すため (バックアップ)」か「残すため (アーカイブ)」か、あるいは両方かに分ける。

3. 要件設定: バックアップには RPO/RTO を、アーカイブには保存期間と削除ルールを設定する。

4. 保存先選定: 用途ごとに、復旧速度・容量単価・改ざん耐性・取り出し頻度で保存先を選ぶ。

5. 復旧テスト: 実際に戻せるかを確認し、手順と体制を整える。

向いている進め方は、既存のバックアップ運用にアーカイブを後付けする場合でも、まず現状のデータと要件を棚卸ししてから足すやり方です。逆に、要件整理を飛ばして製品選定から入ると、後から要件と合わずにやり直しになりやすい点に注意が必要です。

注意点として、自社だけで要件を固めきれない場合は、構成の確認や小規模な検証を通じて絞り込む選択肢もあります。最適な組み合わせは、データの性質・法令要件・運用体制によって環境ごとに異なります。

なお、この棚卸しから復旧テストまでの手順は、記事末尾で案内している記入例つきの「保存要件整理チェックシート (サンプル)」に沿って進められます。データの棚卸しや RPO/RTO と保存期間の整理を、書き込みながら形にしたい場合の材料としてご活用ください。

よくある質問

Q1. バックアップを長期保存すれば、アーカイブは不要になりますか。

必ずしもそうとは言えません。バックアップは最新の状態を復旧するための仕組みで、世代を長期保持しても、長期参照や改ざん防止、検索性といったアーカイブの要件を満たすとは限りません。目的が異なるため、別の仕組みとして設計することが望まれます。環境によっては両方が必要になります。

Q2. RPO と RTO は、どう決めればよいですか。

事業への影響度から逆算して決める考え方が一般的です。RPO はどの時点のデータまで戻す必要があるか (許容できるデータ損失)、RTO はどれくらいで復旧させる必要があるか (許容できる停止時間) を表します。業務が止まったときの影響が大きいシステムほど、RPO・RTO を短く設定する方向で検討することになります。

Q3. アーカイブのコストを抑えるには、どうすればよいですか。

容量単価の低いコールドストレージなどが選択肢になります。ただし、取り出しに時間や費用がかかる場合があるため、参照頻度が低いデータに向いています。安さだけで選ぶと、必要なときにすぐ取り出せないことがあります。保存単価と取り出し条件の両方を確認することが望まれます。

Q4. 既存のバックアップ運用に、アーカイブを後から足せますか。

足すこと自体は可能な場合が多いですが、先にデータの棚卸しと要件整理を行うことが望まれます。何を長期保存すべきか、保存期間と削除ルールをどうするかを決めないまま追加すると、運用が複雑になりやすいためです。責任範囲を整理したうえで進めると、混乱を避けやすくなります。

まとめ

バックアップとアーカイブは、どちらもデータのコピーという点では似ていますが、目的が根本的に異なります。バックアップは障害や誤操作から「元に戻す」ための仕組みであり、アーカイブは法令対応や長期参照のために「残す」ための仕組みです。この違いを曖昧にしたまま、バックアップを長期保持してアーカイブの代わりにしようとすると、世代が積み上がって容量とコストが膨らみ、必要なデータを探し出すことも難しくなります。まずは自社のデータを「戻すため」か「残すため」かで切り分けることが、すべての出発点になります。

設計にあたっては、復旧要件と保存要件を別の軸として扱うと整理しやすくなります。バックアップは RPO/RTO をもとに、どの時点まで・どれくらいで戻すかを決めます。アーカイブは保存期間と削除ルールをもとに、何年残し、いつ・誰の承認で消すかを決めます。この 2 軸を分けて要件化することで、要件の抜け漏れを防ぎやすくなります。そのうえで保存先は、復旧速度・容量単価・改ざん耐性・取り出し頻度といった観点から、用途ごとに選び分けていくことになります。

そして忘れてはならないのが、バックアップは「取れている」ことではなく「戻せる」ことが目的だという点です。復旧テストを実施し、手順や運用体制まで整えて初めて、いざというときに機能します。ツールを導入するだけでは完結しない領域であることを踏まえ、体制の整備まで含めて設計することが望まれます。要点を改めて挙げると、次の 2 点に集約されます。

• バックアップ (復旧) とアーカイブ (長期保管) は目的が異なる別レイヤーであり、RPO/RTO と保存期間という別軸で設計する。

• 「取れている」ではなく「戻せる」ことを、復旧テストと運用体制の整備によって担保する。

本記事の内容を自社にあてはめて整理できるよう、記入例つきの「保存要件整理チェックシート (サンプル)」をご用意しています (A4・全 5 ページ / PDF)。データの棚卸しから目的分類、RPO/RTO と保存期間の設定、保存先選定、復旧テストまでを 1 枚ずつ書き込みながら確認できる構成です。以下からダウンロードのうえ、まずは現状整理の材料としてご活用ください。実際の記入時は、シート内のサンプル行を自社のデータに置き換えてお使いいただけます。

横河レンタ・リース株式会社は日本ヒューレット・パッカード社の Platinum パートナーとして、IT 機器のレンタル・販売に加え、サーバーやストレージの構成設計から更改、運用保守までを組み合わせて提供しています。保存先の構成確認や、復旧テストの進め方について判断が難しい部分があれば、既存環境や運用方針を踏まえてご相談いただくことも可能です。

お問い合わせ (総合) | 法人向けパソコン (パソコン) ・計測器レンタルなら横河レンタ・リース