データバックアップサービスとは？主な方式・費用・導入手順

社内のサーバーや端末、SaaSにデータが分散すると、担当者は「どこまで複製できているのか」「障害時にいつの状態まで戻せるのか」を把握しにくくなります。保存処理が毎日成功していても、必要なファイルを業務再開までに取り出せるとは限りません。

データバックアップサービスは、データを別の場所に複製し、事故・攻撃に備えて復元可能な状態を保つサービスです。本記事では、その仕組みや方式、類似手段との違い、費用、選び方、導入法、要件化まで解説します。

1. データバックアップサービスとは

システム障害や誤削除、ランサムウェアなどによって業務データを失うと、システム自体が復旧しても必要な情報を元に戻せないことがあります。こうしたデータ消失へ備える手段の一つが、データバックアップサービスです。

データバックアップサービスでは、ファイルやサーバーなどのデータを別の保存先へ複製し、必要になったときにバックアップから復元できる環境を用意します。端末やSaaS上のデータを対象にできるか、どの時点まで戻せるかはサービスごとに異なります。

導入時に重視したいのは、バックアップを取れることだけではありません。事故後にどのデータを復元し、誰が復旧作業を担うのかまで想定した上で、必要な条件を満たすサービスを選びましょう。

2. データバックアップの仕組み

データバックアップは、対象データを別の領域へ複製し、必要な時点へ戻せるように保管する仕組みです。バックアップ後は実行結果や復旧ポイントの状態を監視し、障害や誤削除が起きたときに必要なデータを復元します。

主な流れは次のとおりです。

保存状況だけで終わらせず、復元まで実行できる状態を保つことがバックアップ運用の基本です。詳しい仕組みについて、順を追ってご説明します。

2-1. 対象データを収集する

最初にバックアップするサーバーや端末、アプリケーションなどを決め、サービスが対応する方法でデータをバックアップ先へ複製します。

新しい端末やシステムを追加したときは、バックアップ対象にも反映します。対象から漏れたデータは復元できないため、保護する範囲を決めておくことが必要です。

2-2. 世代と保持期間を管理する

バックアップは通常、異なる時点のデータを復旧ポイントとして保持します。複数の時点を残しておけば、直近のデータに破損や誤削除が含まれていても、それ以前の状態を選んで復元できます。

どの時点をどの程度残せるかは、バックアップ方式やサービスの保持設定によって異なります。必要な復旧時点を踏まえ、取得頻度と保持期間を決めます。

2-3. 障害時にデータを復元する

障害や誤削除が発生したら、復旧するデータと復旧ポイントを選び、元の環境や指定した復元先へデータを戻します。

復元処理の完了後は、ファイルやシステムが実際の業務で利用できる状態まで戻っているかを確かめます。バックアップを定期的に取得するだけでなく、必要なときに復元できる状態を維持します。

3. バックアップの主な方式

バックアップ方式を選ぶときは、保存容量だけでなく、障害発生後にどのデータをどこまで戻したいかを考える必要があります。取得方法によって、保存するデータ量と復元時に必要な処理が変わるためです。

フルはすべてのデータ、差分は直近のフルバックアップ以降に変更されたデータ、増分は直前のバックアップ以降に変更されたデータを保存します。

また、イメージバックアップはこれらとは考え方が異なり、OSやアプリケーション、設定などを含めてシステム全体を一つの単位としてまとめて保護する方式です。詳しく見ていきましょう。

3-1. フル：全データを保存する

フルバックアップは、バックアップ対象として指定したデータを毎回すべて保存します。過去のバックアップとの差を取る方式ではないため、1回の取得だけで対象全体のデータを保持します。

差分・増分バックアップを利用する際も、フルバックアップが基点になる構成があります。対象全体を取得する分、保存するデータ量や転送量は大きくなるため、データ容量と実行頻度を考えて運用します。

3-2. 差分：前回フルとの差を保存する

直近のフルバックアップから現在までに変更されたデータをまとめて保存する方式です。新しい差分を取得しても基点は変わらず、次にフルバックアップを取得するまで同じフルとの差を取り続けます。

このため、フル取得後に変更が増えるほど、後から取得する差分バックアップのデータ量も増えます。復元時は基点のフルと最新の差分を使うため、過去の差分を一つずつ適用する仕組みではありません。

3-3. 増分：直前との差を保存する

増分バックアップでは、直前のバックアップ取得後に変更された部分だけを保存します。差分が直近のフルを基点に変更分を積み上げるのに対し、増分は取得するたびに比較する基点が前へ進みます。

ただし、復元時には複数のバックアップデータの関係が影響することがあり、具体的な処理は製品によって異なります。取得効率と併せて、復元の仕組みも把握しておきましょう。

3-4. イメージ：システム全体を保存する

ファイルだけを抜き出して保存するのではなく、OS・アプリケーション・設定・データなどを含む環境をまとまりとして保護する方式です。

データファイルだけを戻す用途より、サーバーや仮想マシンをシステム単位で復旧したい場面に適しています。イメージバックアップの内部でフル取得や変更ブロックの取得を組み合わせる製品もあるため、フル・差分・増分とは別の観点で考えます。

4. 同期・クラウドストレージ・DRとの違い

同期・クラウドストレージ・DR（ディザスター・リカバリー：災害復旧）は、いずれもデータの保護や利用に関わりますが、目的と対象範囲が異なります。

バックアップは、障害や誤削除などでデータを失ったときに、保存しておいたデータから復元するための仕組みです。

一方で、同期は複数環境の状態をそろえ、クラウドストレージはファイルの保存・共有、DRは重大な障害からシステムや業務を復旧する役割を担います。それぞれの違いをご紹介します。

4-1. 同期との違い：変更の反映

同期とバックアップでは、データに変更があったときの扱いが異なります。

• バックアップ：保存したデータを復元に利用できるよう保持する

• 同期：ファイルの追加・更新・削除などを複数の環境へ反映し、状態をそろえる

同期では、一方でファイルを変更・削除すると、その内容が同期先にも反映されることがあります。過去の状態へ戻せるかは、バージョン履歴やごみ箱など、利用するサービスの機能によって変わります。

誤削除や上書きが起きる前のデータを一定期間残したいときは、同期機能だけで判断せず、バックアップで保持できる世代や復元方法も確かめましょう。

4-2. クラウドストレージとの違い：復元管理

クラウドストレージとバックアップでは、データを保存する主な目的が異なります。

• バックアップ：障害や誤削除などが起きたときの復元に備えてデータを保持する

• クラウドストレージ：クラウド上へファイルを保存し、端末からのアクセスや利用者間の共有に使う

クラウドストレージにも、ごみ箱やバージョン履歴などからデータを戻せるサービスがあります。

クラウドへ保存していることだけを根拠にバックアップが不要とは判断せず、自社が必要とする時点や範囲までデータを戻せるかを確かめます。不足する範囲があれば、別途バックアップを用意します。

4-3. DRとの違い：事業復旧

DRとバックアップでは、障害発生後に復旧する対象の広さが異なります。

• バックアップ：失われたデータやシステムを保存済みのデータから復元する

• DR：重大な障害が発生したときに、システムや業務を再開するための復旧方法を定める

DRではデータの復元だけでなく、代替環境への切り替えや復旧の手順、担当者なども対象になります。バックアップは、その復旧に必要なデータを確保する手段としてDRに組み込まれることがあります。

重要なシステムでは、データをどこまで戻すかに加えて、どの環境でシステムを動かし、どの順序で業務を再開するかまで決めておきましょう。

5. バックアップサービスのメリット

バックアップサービスを利用すると、データの複製や保管、実行状況の監視などをサービスの機能で管理できます。対応するサービスでは遠隔地にもバックアップを保持でき、障害発生時の復旧作業も共通の手順で進められます。

5-1. バックアップ運用の負担を減らせる

バックアップサービスには、スケジュールに沿ったバックアップの実行や保持期間の管理、処理結果の監視などを自動化できるものがあります。担当者が毎回手作業でバックアップを実行したり、複数の環境を個別に管理したりする負担を減らせます。

自動化できる範囲はサービスによって異なります。導入時には、バックアップの設定や失敗時の対応など、自社に残る作業も把握しておきましょう。

5-2. 遠隔地へバックアップを保管できる

対応するバックアップサービスでは、本番データとは異なる地域へバックアップを複製できます。同じ拠点だけにデータを置かないことで、拠点や地域全体へ影響する障害が起きたときにも復旧手段を残せます。

遠隔地へ保管できるかに加え、障害時にそのバックアップをどのように取り出して復元するのかもサービスごとに異なります。保管場所だけで判断せず、遠隔地のデータから復元できる範囲まで見ておきましょう。

5-3. 復旧作業を標準化できる

復元機能を備えたバックアップサービスでは、復旧するデータや復旧ポイントを選び、決められた手順に沿って復元作業を進められます。その手順を文書化し、担当者への訓練と実施記録を組み合わせれば、作業のばらつきを抑え、障害時の対応経過も追いやすくなります。

6. データバックアップの利用時に起こりやすい失敗例

バックアップを取得していても、事故が起きたときに必要なデータを戻せるとは限りません。対象漏れやバックアップ自体の被害、保持期間の不足、復元テストの未実施があると、復旧に使えるデータを確保できないことがあります。

バックアップが「成功」と表示されているかだけで判断せず、実際の復旧まで想定して運用しましょう。以下、データバックアップ利用時に起こりやすい失敗例をご紹介します。

6-1. バックアップ対象が不足する

事故後に必要なデータを戻そうとしても、そもそもバックアップ対象に含まれていなければ復元できません。システムや保存場所が増えたのに、以前のバックアップ設定を使い続けていると対象漏れが生じるおそれがあります。

保護すべきデータと現在の設定を定期的に比べ、新しく追加したデータも対象に含まれているかを確かめましょう。

6-2. 本番と同時に暗号化・削除される

本番データとバックアップの両方が同じ攻撃の影響を受けると、復旧に使える複製まで失う可能性があります。

IPA（独立行政法人情報処理推進機構）は、本番環境から物理的に離してバックアップを保管する方法や、複数世代を保持する方法を推奨しています。バックアップ先を用意するだけで終わらせず、本番環境で被害が起きたときにもデータを残せる構成にしましょう。

参考：独立行政法人情報処理推進機構（IPA）「中小企業の情報セキュリティ対策ガイドライン 第4.0版」

6-3. 保持期間が業務要件に合わない

誤った更新やデータ破損に気付くまで時間がかかると、正常だった時点のバックアップがすでに削除されていることがあります。

複数世代を保持し、どこまで過去へ戻せる状態が必要かを先に決めましょう。保存期間や世代数だけでなく、容量上限に達した後のデータの扱いもサービス仕様で把握します。

7. バックアップサービスが向く企業

バックアップする拠点や端末、システムが増えると、設定だけでなく、実行状況の把握や保管、復元まで継続して管理する負担も大きくなります。こうした運用を自社だけで続けることが難しくなってきた企業では、バックアップサービスを検討する時期です。

一方、現在の方法でバックアップから復元まで安定して運用できているなら、すぐにサービスへ切り替える必要はないでしょう。

7-1. バックアップサービスの導入を検討したい企業

バックアップは一度設定すれば終わりではなく、対象追加やエラー対応、容量管理、復元テストなどの運用が続きます。これらの負担が大きくなった場合は、サービス利用を検討します。

7-1.1 専任担当者が不足している企業

システムやアカウントの管理を兼務していると、バックアップの実行結果やエラーへの対応まで手が回らないことがあります。こうした企業では、監視や通知、運用支援を受けられるサービスが候補になります。

とはいえ、外部サービスを利用しても、自社で何も決めなくてよくなるわけではありません。保護するデータや復元の優先順位、事故時の連絡窓口など、自社で担う範囲を決めておきましょう。

7-1.2 拠点・端末・SaaSが増えている企業

事業の拡大や働き方の変化によって拠点や端末、利用するSaaSが増えると、保存場所ごとにバックアップを管理する負担も増えていきます。

複数の対象をまとめて管理できるサービスなら、バックアップの実行状況を把握する作業を集約できるため重宝します。

7-1.3 自社運用の負担が大きい企業

バックアップを自社で運用する場合、保存先の確保や容量の管理、バックアップが正常に実行されているかの確認、障害が起きたときの対応、さらにデータを元に戻す復元作業まで、すべて継続して行う必要があります。

運用支援やマネージド機能を備えたバックアップサービスなら、監視や保守など、運用・管理の一部を提供会社へ任せられます。

7-2. バックアップサービスの導入を急がなくてもよい企業

サービスを利用すること自体が目的ではありません。現在の方法で必要なデータを継続して保護でき、事故を想定した復元まで行える企業は、自社運用を続ける方法もあります。

7-2.1 自社でバックアップ運用を継続できている企業

担当者と運用手順が決まり、バックアップの実行状況を把握しながら復元テストまで続けられているなら、外部サービスへ切り替えず、現行の自社運用を継続する方法もあります。

ただし、特定の担当者だけが設定や復元方法を把握している状態では、その担当者が不在になったときに運用が止まるおそれがあります。担当者が変わっても同じ手順を続けられるかまで確かめておきましょう。

7-2.2 保護対象が限られ、現在の方法で復元できている企業

バックアップ対象となるシステムやデータが限られていれば、自社で管理できるケースもあります。必要な世代を保持し、事故時に求める範囲まで復元できているなら、現在の運用を続ける方法もあります。ただし、法令・契約・監査上の要件も併せて確認しましょう。

8. バックアップサービスの費用を左右する主な条件

バックアップサービスの費用は、保存するデータ量や保持期間、データの転送・復元、サポート範囲などによって変わります。課金対象はサービスごとに異なるため、自社のバックアップ方法を想定した上で総額を見積もります。

8-1. バックアップするデータ量

保存容量に応じて課金されるサービスでは、バックアップするデータ量が多いほど費用も増えます。現在のデータ量だけでなく、日々増えるファイルやデータベースも含めて必要な容量を見積もりましょう。

8-2. バックアップの頻度と保存期間

バックアップを取得する頻度や、過去のデータをどの程度残すかも保存量に影響します。複数の復旧ポイントを長期間保持すると、必要なストレージ容量が増えることがあります。

どの時点まで戻す必要があるかを決め、その条件に合うバックアップ頻度と保持期間を設定してください。保存期間によって料金区分が変わるサービスでは、その条件も費用に含めます。

8-3. データ転送・復元の回数

バックアップデータの転送や復元は、データ量に応じて料金が発生する場合があります。特に、別の拠点やリージョンへデータを複製する場合、障害時に大量のデータを復元する場合は、費用に影響しやすいです。

8-4. 導入・運用サポートの範囲

初期設定やデータ移行、監視、障害対応、復元支援などを提供会社へ依頼すると、その範囲に応じて費用が変わることがあります。通知だけを受け取るサービスと、障害発生後の対応まで依頼できるサービスでは、自社に残る作業も異なります。

9. バックアップサービスを選ぶ5つのポイント

バックアップサービスを選ぶ前に、どの時点までデータを戻す必要があるかをRPO、どの程度の時間で業務を再開する必要があるかをRTOとして決めます。

各要件を満たせるサービスを候補にして、費用・操作性・対応範囲・安全管理・支援の5つの観点から比べましょう。

公式資料で候補を絞った後は、実際にデータを復元し、必要な時点のデータを目標時間内に戻せるかを試します。

9-1. 費用対効果をRPO・RTOで判断する

RPO・RTOを先に定め、その目標を満たすバックアップ方法にどの程度の費用がかかるかを比べます。基本料金だけでなく、保存容量やデータ転送、復元、サポートまで含めた総費用で判断しましょう。

なお、RPO・RTOは短ければよいとは限りません。業務停止やデータ損失による影響を踏まえ、必要な復旧水準と費用のバランスを見ます。

9-2. 管理画面と復元操作を試す

実際の担当者が、バックアップ対象の設定や実行状況の把握、復旧ポイントの選択、データの復元まで操作します。日常の管理画面だけでなく、障害時に必要となる復元操作まで無理なく進められるサービスを選びます。

9-3. 対象・連携・拡張範囲を調べる

現在利用しているサーバーやOS、データベース、端末、SaaSがバックアップ対象に含まれるかを調べます。製品やバージョンによって対応条件が異なるため、自社の利用環境を基準に公式仕様を読みます。

9-4. 安全管理と運営企業を見極める

バックアップデータの転送・保管時の暗号化や多要素認証、アクセス権限、操作ログなどを見ます。バックアップの変更・削除に関わる権限を必要な利用者だけに制限できるかもポイントです。

9-5. 復元・障害支援の範囲を把握する

バックアップの失敗や障害が発生したときに、提供会社へどこまで対応を依頼できるかを見ます。監視や原因調査、再実行、復元支援など、自社で対応が難しい作業を任せられるかが選定のポイントです。

10. バックアップサービスの導入手順

バックアップサービスは、守るデータと復旧条件を決め、サービスの仕様を確かめた上で、初回バックアップと復元テストまで実施して本稼働へ移します。

導入の完了を「バックアップが取得できた時点」とせず、必要なデータを想定する条件で復元できるところまで試してください。ここでは、データバックアップサービスの導入手順をご説明します。

10-1. 重要データと責任者を定める

最初に、停止や消失によって自社の業務へ大きな影響が生じるデータやシステムを特定します。あわせて、バックアップ設定の管理者と、障害発生時に復元を判断・承認する担当者を決めておきましょう。

提供会社へ運用の一部を任せるときも、自社と提供会社がそれぞれ担う範囲を決めておく必要があります。

10-2. RPO・RTO・保持期間を決める

重要な業務ごとに、障害やデータ消失が起きた場合にどの時点まで戻す必要があるかをRPO、どのくらいの時間で業務を復旧させる必要があるかをRTOとして設定します。

RPOはバックアップ頻度やレプリケーション方式など、データ保護方法を設計する基準となり、RTOは復旧手順・復旧環境・要員体制を検討する基準になります。

10-3. 対象と除外を棚卸する

サーバーや端末、SaaSなど、自社で保護するデータとシステムを洗い出し、バックアップ対象を決めます。

対象外とするデータがあるときは、再作成できるのか、ほかの仕組みで保護されているのかなど、対象から外す理由も残します。

10-4. 公式資料と復元条件を確認する

候補となるサービスでは、対応する環境、バックアップ頻度、保持期間、復元できる単位、権限管理、監視・通知、復元支援などを公式資料で確かめます。

10-5. 初回バックアップを検証する

サービスを設定したら、対象としたデータが実際にバックアップされているかを確かめます。失敗や異常が起きたときに通知を受け取れるかも試しておきましょう。

設定や製品の仕様によっては、意図したデータが対象から漏れていても、設定済みの範囲ではバックアップ処理が完了扱いになる場合があります。設定した対象と実際に取得されたデータを比べてから、本稼働へ進みます。

10-6. 復元テストと訓練を続ける

初回バックアップが完了したら、実際にデータを復元します。必要なデータがそろっているか、復元後に利用できるか、想定する時間内に作業を終えられるかを試しましょう。

復元テストは導入時だけで終わらせず、本稼働後も定期的に実施します。テスト結果がRPO・RTOを満たさないときは、バックアップ頻度や復元手順を見直します。

11. バックアップサービスのよくある質問

最後に、データバックアップサービスに関するよくある疑問にお答えします。

11-1. 復元テストをどれくらい行う？

一般論として、復元テストに一律の実施回数はありません。自社のリスクとRPO・RTOに応じて定期的に実施し、必要なデータを実際に復元できるかを試します。

システム構成やバックアップ設定を変更したときも、復元手順が有効かを再確認しましょう。業界規制や契約で最低頻度が定められている場合は、その要件に従います。

11-2. 終了時にバックアップを返却できる？

契約終了時にバックアップデータを取得できるかは、サービスや契約条件によって異なります。契約前に、取得できるデータの範囲や形式、利用できる期限、データ削除の扱いを把握してください。

11-3. 障害時の復元責任を誰が負う？

障害時に提供会社と利用企業が担う範囲は、サービス内容や契約によって異なります。復元操作を提供会社へ依頼できるのか、自社が復旧ポイントを選んで作業するのかを導入前に決めておきましょう。

11-4. SaaSデータも保護できる？

SaaSのバックアップに対応するサービスなら、クラウド上のデータも保護できます。ただし、対応するSaaSや取得できるデータ、復元できる単位はサービスごとに異なります。

12. まとめ

データバックアップサービスを選ぶときは、まず自社が守るデータと、障害時にどの時点まで・どの程度の時間で復旧したいかを決めます。その条件をもとに、対応範囲や保持期間、復元方法、安全管理、支援内容を比べましょう。

自社だけで決めきれない項目は、資料や公式情報を調べた上で提供会社へ尋ねます。導入時にはバックアップを取得して終わらせず、必要なデータを実際に復元できるところまで試してください。

事故が起きたときに必要な業務を再開できるかを基準に、自社の運用に合うサービスを選びましょう。