公開2026.07.11更新2026.09.26 Webシステム

システムバックアップとは？フル・差分・増分の違いと取得手順・方式の選び方を解説

システムバックアップとは、OSや設定、アプリケーションまで含めてシステムを丸ごと複製し、障害や災害から元の状態へ戻せるようにしておく備えです。日々のファイルコピーとは目的が違い、狙いは「壊れたサーバーを短時間で立て直す」ことにあります。この記事で扱うのは、ファイルバックアップやデータバックアップとの違い、フル・差分・増分・永久増分という4つの方式の使い分けと実際の取得コマンド、RPOとRTOから逆算する設計と3-2-1ルール、オンプレミスとクラウドの保存先選び、ランサムウェアに耐える保管、そして情シス・発注者が迷う「自社で運用するか外注するか」の分岐点です。警察庁の統計ではランサムウェア被害でバックアップから戻せなかった例が多数を占めており、復旧できないバックアップを作らないための復旧テストの考え方まで具体的に示します。

まとめ：システムバックアップの種類と方式選定・委託判断の要点整理

システムバックアップの目的は、データを残すことではなく、止まったシステムを目標時間内に復旧させることにあります。まず押さえるのは、ファイル単位で守る「ファイル/データバックアップ」と、OSや設定ごと丸ごと保存してサーバーそのものを再構築できる「システムバックアップ（イメージバックアップ）」の役割の違いです。取得方式はフル・差分・増分・永久増分の4つがあり、復元の速さと保存容量・取得時間はトレードオフの関係にあります。

設計の起点は方式選びではなく、RPO（どこまで戻せれば許容できるか）とRTO（何時間で復旧するか）の2指標です。この目標から逆算して、取得頻度・保持世代・保存先が決まります。保管は3-2-1ルール（3つのコピー・2種類の媒体・1つは遠隔）を土台にし、ランサムウェア対策では書き換え不能なイミュータブル保存やオフライン保管を1本加えます。バックアップは取って終わりではありません。定期的に実際へ戻す復旧テストを組み込み、いざという時に復元できる状態を保ちます。バックアップはシステム運用の一部であり、監視や保守を含む全体像はシステム運用とは何かを解説した記事で確認できます。

要点を3行に絞るとこうなります。

方式は「週次フル＋日次の差分か増分」を基本形にし、増分の鎖は長くしない
保存先は3-2-1を満たし、うち1系統は削除も上書きもできない形で隔離する
取得の成功ではなく、別環境へ戻せたかどうかを定期的に実測して合否を決める

システムバックアップとは何かとファイルバックアップ・イメージ保存の違い

同じ「バックアップ」でも、守る対象と復旧できる範囲は方式によって変わります。まず言葉の定義と、システムバックアップが何を丸ごと残すのかを整理します。

システムバックアップの定義とデータ保護全体での位置づけの整理

システムバックアップとは、サーバーのOS・ミドルウェア・アプリケーション・各種設定を含めて、システムが動く状態そのものを保存しておく方法です。データだけを残すのと違い、ハードウェア故障やOSの破損が起きても、保存した時点の稼働状態へ戻せます。データ保護の全体像では、日々の変更を守る「バックアップ」と、災害時に事業を継続させる「DR対策（災害復旧）」が層をなし、システムバックアップは両者をつなぐ土台にあたる存在です。DR対策そのものの定義と目的はDR対策（災害復旧）とは何かを解説した記事で扱っています。なお「バックアップ」は複製を取る行為、「リストア」は複製から戻す作業、「リカバリー」は業務を再開できる状態まで立て直す工程全体を指し、言葉の区別はリカバリーとリストア・バックアップの違いを解説した記事で詳しく扱っています。

ファイルバックアップ・データバックアップとの違いと使い分け方

ファイルバックアップは、文書や画像といった個別ファイルを選んで残す方法です。誤削除したファイルを1件だけ戻すような場面に向きます。一方でサーバーが起動しなくなった場合、ファイルだけ持っていてもOSや設定を入れ直す手間が残り、復旧は長引くでしょう。システムバックアップとの違いは、この再構築の工程ごと保存する点です。実務では、頻繁に変わる業務データはファイル/データ単位で細かく、システム全体は週次や更新の節目でイメージとして、と粒度を分けて併用します。対象別の取得手順はバックアップのやり方（PC・サーバー・クラウド別）で整理しています。

イメージバックアップでOS・設定ごとシステム全体を復旧する仕組み

イメージバックアップは、ディスクの中身をブロック単位でそっくり写し取る方式で、システムバックアップの中核をなします。取得したイメージから戻せば、OSのインストールや各種設定のやり直しを省いて、保存時点のサーバーをそのまま再現できる点が強みです。物理サーバーだけでなく、仮想マシンやクラウド上のインスタンスでも、スナップショットという形で同じ考え方が使われます。復旧の速さを買う代わりに、イメージはファイル単位より容量が大きくなりやすく、保存先の設計とセットで考える必要があります。

RAIDや冗長化・スナップショットがバックアップの代わりにならない理由

「RAIDを組んでいるからバックアップは不要」という誤解は根強くあります。RAIDはディスク1本の故障で止まらないための仕組みで、誤削除・ランサムウェアによる暗号化・設定ミスは、その瞬間に全ディスクへ同じように書き込まれます。つまり壊れた状態がそのまま複製されるだけです。RAIDの各レベルの性格はRAID0/1/5/6/10の違いと構成を解説した記事、サーバーや回線を二重化する考え方は冗長化と二重化の違いを解説した記事で扱っています。

同じ理由で、本番ストレージと同じ装置の中に置いたスナップショットも単独ではバックアップと呼べません。装置そのものが壊れる、管理者権限を奪われて消される、という事態では一緒に失われるからです。冗長化は「止めない」ため、バックアップは「過去の正しい状態へ戻す」ためと役割を分け、両方を持つ前提で設計します。

フル・差分・増分・永久増分バックアップ4方式の違いと取得コマンド例

バックアップの取得方式は、次に挙げる4つの方式に整理できるものです。どれか1つが優れているわけではなく、復元の速さ・取得の速さ・保存容量のどれを優先するかで選び分けます。後半では、同じ考え方を実際のコマンドで確かめます。

フルバックアップの全体複製と復元の速さ・容量負担のトレードオフ

フルバックアップは、対象データを毎回まるごと複製する方式です。復元は保存した1セットだけで完結するため、戻す手順が単純で速く済みます。弱点は、取得のたびに全量をコピーするので時間がかかり、保存容量も大きく膨らむ点です。毎日フルだけで回すとストレージを圧迫するため、初回や週次の基準点をフルで取り、間を差分や増分で埋める組み合わせが実務の定番になります。

差分バックアップと増分バックアップの復元手順・容量差の比較整理

差分と増分は、どちらも直近のフルからの変更分だけを取る方式ですが、基準の取り方が違います。差分は「前回フル以降に変わった全て」を毎回取るため、日を追うごとにサイズが増える代わりに、復元はフルと最新の差分の2つで済みます。増分は「前回の取得以降に変わった分」だけを取るので取得は最も軽く速い反面、復元にはフルと途中の増分を順に積み重ねる必要があり、1つでも欠けると戻せません。下表に3方式の性格をまとめます。

方式	取得の速さ・容量	復元の手間	向く場面
フル	遅い・大きい	1セットで完結	基準点・週次
差分	中間	フル＋最新差分	復元速度を重視
増分	速い・小さい	フル＋全増分を順に	取得負荷を抑える

復元の速さを求めるなら差分、取得の負荷とストレージを抑えたいなら増分、という軸で選ぶと迷いません。

永久増分バックアップと世代管理で保存コストを抑える運用の考え方

永久増分は、最初に一度フルを取った後は増分だけを取り続け、古い世代を随時フルへ合成していく方式です。フルを繰り返さないので取得の負荷とネットワーク転送を軽く保てます。あわせて用いるのが世代管理で、日次・週次・月次で残す本数を決める仕組みです。祖父・父・子の3層で保持する考え方（GFS方式）では、月次を長期、日次を短期で回し、保存コストを抑えます。世代を無制限に増やすとストレージが破綻するため、RPOと保持期間から逆算して本数を絞るのが運用の勘所です。

tarコマンドでフル・差分・増分を取り分けて復元まで試す手順

方式の違いは、Linux標準のGNU tarで手元に再現できます。GNU tarの公式マニュアルの増分ダンプの章によると、--listed-incrementalで指定した「スナップショットファイル」に前回の状態を記録し、それと比べて変わったファイルだけをアーカイブに入れる仕組みです。スナップショットファイルが無い初回はレベル0（フル）になります。ここで、実行のたびに更新されるスナップショットファイルを使い回すと増分、フル直後の写しを毎回複製して使うと差分になります。

# 日曜：フル（レベル0）を取得。level0.snar が新しく作られる
tar --create --file=/backup/full.tar \
    --listed-incremental=/backup/level0.snar /etc /var/www

# 差分：毎回フル直後の状態（level0.snar）を複製してから取る
cp /backup/level0.snar /backup/diff.snar
tar --create --file=/backup/diff_mon.tar \
    --listed-incremental=/backup/diff.snar /etc /var/www

# 増分：月曜にだけ複製し、以降は inc.snar を使い回す（実行ごとに更新される）
cp /backup/level0.snar /backup/inc.snar
tar --create --file=/backup/inc_mon.tar \
    --listed-incremental=/backup/inc.snar /etc /var/www
tar --create --file=/backup/inc_tue.tar \
    --listed-incremental=/backup/inc.snar /etc /var/www

# 復元：フルから順に展開する。スナップショットファイルは不要なので /dev/null を渡す
mkdir -p /restore
tar --extract --listed-incremental=/dev/null --file=/backup/full.tar -C /restore
tar --extract --listed-incremental=/dev/null --file=/backup/inc_mon.tar -C /restore
tar --extract --listed-incremental=/dev/null --file=/backup/inc_tue.tar -C /restore

差分なら復元は「full.tar＋最新の差分1本」で済み、増分なら「full.tar＋月曜＋火曜」を順番どおりに全部展開します。火曜の増分だけ残っていても、月曜分が欠けていれば整合した状態へは戻りません。上表の「フル＋全増分を順に」は、この展開の順序を指しています。試すときは本番ではなく検証用の仮想マシンで行い、/restoreのように本番と別の場所へ展開して中身を比べます。

バックアップ方式を処理時間・復元速度・容量から選び分ける判断軸

方式選びで玉虫色に「状況次第」と逃げると設計が進みません。判断はこう言い切れます。復旧を最優先する基幹システムは、復元手順が短いフル＋差分を軸にします。データ量が多くバックアップ枠（バックアップウィンドウ）が短い夜間バッチ環境では、取得の軽い増分や永久増分が現実的です。逆に、増分を長く積み上げる構成は、1本の破損で連鎖的に復元不能へ陥る弱さを抱えます。ここを避けるには、定期的にフルの基準点を取り直し、増分の鎖を短く保つ設計にします。

Windows Server・AWS・DBでシステム全体をバックアップする手順

tarはファイル単位の取得なので、OSごと起動できる状態へ戻すには、OSやクラウドが用意する仕組みを使います。代表的な3つの場面を、公式ドキュメントに載っているコマンドで示します。

Windows Serverのwbadminでベアメタル復旧用のイメージを取る

Windows Serverでは、標準の「Windows Server バックアップ」をコマンドから操作するwbadminが使えます。Microsoft Learnのwbadmin start backupのリファレンスでは、-allCriticalを「オペレーティングシステムの状態を含むボリューム」をすべて含める指定で、ベアメタル復旧用のバックアップを作る場合に便利なものと説明しています。-backupTargetと組み合わせないと失敗する点も、同リファレンスに明記された注意事項です。

rem 管理者として実行したコマンドプロンプトで、E: へシステム全体を取得する
wbadmin start backup -backupTarget:E: -allCritical -systemState -quiet

rem 取得済みのバックアップ（世代）の一覧を確かめる
wbadmin get versions

同じリファレンスには、既定はコピーバックアップで、-vssFullを付けると他のバックアップ製品が作る増分・差分の系列を崩す恐れがあるとの注意もあります。別製品と併用している環境では付けないのが安全です。また、リモート共有フォルダーへ同じ宛先で取り直すと前回分が上書きされ、失敗時には手元にバックアップが残らない場合があるとも書かれています。世代を残したいときは宛先をサブフォルダーで分けます。

AWSのスナップショットとAWS Backupで取得と保持をまとめて管理する

クラウドでは、EC2のボリュームやRDSのデータベースをスナップショットとして取り、保持期間や遠隔リージョンへのコピーをAWS Backupのバックアッププランで一括管理する構成が一般的です。対応サービスや料金、プランの作り方と復元の手順はAWS Backupの使い方を解説した記事にまとめています。クラウドだから安全というわけではなく、同じアカウント・同じリージョンの中だけに置くと、権限を奪われた場合に一緒に消される点はオンプレミスと変わりません。後述のObject Lockのような削除できない保管と組み合わせます。

データベースはファイルコピーでは整合しないのでDBの仕組みで取る

稼働中のデータベースのデータファイルを、tarやファイルコピーでそのまま写すと、書き込み途中の状態が混ざり、戻しても起動しない・中身が食い違う事態になりがちです。データベースは、ダンプ（論理バックアップ）や、ベースバックアップに更新ログを重ねて任意の時点へ戻すPITR（ポイントインタイムリカバリ）など、DB自身の仕組みで取るのが原則です。PostgreSQLを例にした使い分けと復旧検証はPostgreSQLのバックアップ設計を解説した記事で扱っています。システムバックアップのイメージとDBのバックアップは、役割を分けて両方取ります。

RPOとRTOから決めるバックアップ設計と3-2-1ルール・世代管理の考え方

方式の話より先に決めるべきは、どこまでの損失を許せて、何時間で戻すか、という目標値です。ここが曖昧なままツールを選ぶと、過剰投資か復旧不能のどちらかに振れます。

RPOとRTOの設定でバックアップ頻度と保持世代を決める手順

RPO（目標復旧時点）は、障害でさかのぼって失われるデータの許容幅を指します。RPOを1時間に置けば、少なくとも1時間ごとの取得が要るでしょう。RTO（目標復旧時間）は、復旧完了までに許される時間で、これが短いほど復元の速い方式や即時に切り替えられる構成が求められます。設計はこの順で進めます。

業務ごとに停止の影響度を洗い出し、許容できる損失時間（RPO）と停止時間（RTO）を数値で決める
RPOから取得頻度（毎時・日次など）を、RTOから方式と保存先の速さを決める
保持世代（何日・何世代残すか）を法定保存期間や業務要件から確定する

RPO・RTOを詰めずに「毎日フルを取る」だけの設計は、コスト過多か復旧遅延を招きやすく、まず数値合わせから入るのが近道です。どの業務をどの順で戻すかは、会社全体の事業継続計画とそろえて決めます。業務単位の優先順位と目標復旧時間の決め方はBCP（事業継続計画）の意味とRTOの決め方を解説した記事が参考になります。

3-2-1ルールで媒体分散とオフサイト保管を確保する設計指針

保管の土台になるのが3-2-1ルールです。データのコピーを3つ持ち、2種類の異なる媒体に分け、そのうち1つは物理的に離れた遠隔地へ置く、という指針です。米国の旧US-CERT向けにCarnegie Mellon Universityが2012年に作成した資料「Data Backup Options」（CISA掲載のPDF）では、「重要なファイルは1つの原本と2つのバックアップの計3コピーを持つ」「異なる危険に備えて2種類の媒体に保存する」「1つは自宅や事業所の外に置く」と説明されています。同資料は写真家Peter Krogh氏の著書を出典に挙げており、もともとはデジタル資産管理の実務から広まった考え方です。同じディスク・同じ拠点にコピーを固めると、機器故障や火災・水害で一度に全て失いかねません。本番ストレージに加えてバックアップ用ストレージ、さらに遠隔地のクラウドやデータセンター、と分散させることで、単一障害点をなくします。

オンプレミス・クラウド・BaaSの保存先を条件で選ぶ判断材料

保存先は復旧の速さとコスト、遠隔性のバランスで選びます。オンプレミスの外部ストレージは復元が速い反面、同一拠点だと災害に弱くなります。クラウドストレージは遠隔保管と容量の伸縮に向き、3-2-1の「1つは遠隔」を満たしやすい選択肢です。運用まで任せたい場合は、取得・保管・監視をまとめて提供するBaaS（Backup as a Service）も候補になります。下表で性格を比べます。

保存先	復元の速さ	遠隔性	運用負荷
オンプレ外部	速い	低い	自社で担う
クラウド	回線に依存	高い	中程度
BaaS	提供条件次第	高い	委託で軽い

復旧の速さを最優先するならオンプレの近距離コピー、災害耐性と手離れを求めるならクラウドやBaaS、と目的で割り切ると選びやすくなります。

ランサムウェア対策の3-2-1-1-0とバックアップ運用を内製・外注で分ける基準

攻撃者はバックアップごと暗号化しにきます。取得しているだけでは守り切れない前提で、公的統計に表れた実態を確かめたうえで、保管の強度と運用体制まで踏み込みます。

警察庁の統計に見る企業・団体のランサムウェア被害時のバックアップ復元率

警察庁は半期ごとに「サイバー空間をめぐる脅威の情勢等」を公表しており、ランサムウェア被害に遭った企業・団体からの回答をもとに、バックアップの取得状況と復元結果を集計しています。2026年9月時点で最新の令和8年上半期（2026年1〜6月）の統計データから、該当部分を抜き出すと次のとおりです。

項目（令和8年上半期）	件数
バックアップを取得していた	50件中44件
バックアップから復元できた	40件中11件
復元できなかった	40件中29件
理由：暗号化・消去された	29件中14件
理由：運用の不備	29件中8件

9割近くが取得していたのに、戻せたのは回答の3割に届きません。前年の令和7年通年でも、回答99件のうち79件が復元できなかったと集計されています。件数は回答のあった事案に限られるため全体の比率とは言い切れませんが、「取っていた」と「戻せた」の間に大きな溝がある点は、年をまたいで一貫しています。失敗理由の最多は、バックアップ自体が暗号化・消去されたことでした。次の2項は、この2つの失敗理由にそれぞれ対応する手当てです。

ランサムウェアに備えるイミュータブル保存とオフライン保管の要点

ランサムウェア被害では、共有ネットワーク上のバックアップまで暗号化され、復旧手段を失う事例が上の統計のとおり多く報告されています。対策の軸は、一定期間は上書き・削除ができないイミュータブル（変更不能）保存と、ネットワークから切り離すオフライン（エアギャップ）保管です。3-2-1ルールを拡張し、1本はオフラインまたはイミュータブル、復元検証でエラーをゼロにする「3-2-1-1-0」を提唱するベンダーもあります。少なくとも1系統は攻撃者の手が届かない場所へ隔離し、そこから戻せる状態を保つ構成が現実的でしょう。異常の早期検知には監視も効き、考え方はシステム監視とは何かを解説した記事で補えます。

クラウドでイミュータブル保存を作る例として、Amazon S3のObject Lockがあります。AWSの公式ドキュメントによると、Object LockはWORM（Write Once Read Many）のモデルで保存し、コンプライアンスモードでは保持期間中はAWSアカウントのrootユーザーを含めて誰も上書き・削除できず、保持期間の短縮もできません。ガバナンスモードは特別な権限を持つ利用者だけが設定を外せる、より緩い形です。既定の保持期間はAWS CLIのput-object-lock-configurationで設定できます。

# Object Lockを有効にしたバケットを東京リージョンに作る（作成時に指定する）
aws s3api create-bucket --bucket example-backup-vault \
    --region ap-northeast-1 \
    --create-bucket-configuration LocationConstraint=ap-northeast-1 \
    --object-lock-enabled-for-bucket

# 置いたバックアップを30日間は誰も消せないようにする既定ルール
aws s3api put-object-lock-configuration --bucket example-backup-vault \
    --object-lock-configuration '{"ObjectLockEnabled": "Enabled", "Rule": {"DefaultRetention": {"Mode": "COMPLIANCE", "Days": 30}}}'

コンプライアンスモードは期限前に消す手段がアカウント削除しか残らないほど強いので、保持日数を長く設定しすぎると保存料金を止められません。まずガバナンスモードと短い日数で運用を試し、世代数と費用を確かめてからコンプライアンスモードへ切り替える順序が安全です。バケット名は例なので、実際の名前に置き換えてください。

復旧できないバックアップを避けるための復旧テストの設計と頻度

取得の成功と復元の成功は別物です。世代の破損、設定漏れ、暗号鍵の紛失などで、いざ戻そうとして初めて復元不能に気づく失敗は珍しくありません。警察庁の統計で失敗理由の2番目に挙がった「運用の不備」は、まさにこの型です。これを避けるには、定期的に別環境へ実際に戻すリストアテストを組み込みます。四半期に一度は基幹システムの全体復旧を試し、RTO内に戻せるかを実測しておくと安全側に倒せるでしょう。テストでは次の3点を記録に残します。

どの世代を、どの環境へ戻したか（取得日時と復元先）
復元開始から業務で使える状態になるまでの実測時間と、RTOとの差
OSの起動・アプリの動作・直近データの有無を誰がどう確かめたか

テストの記録を残し、手順の属人化を防ぐことも復旧の確実さにつながります。

バックアップ運用を内製で回すか外注へ委託するかを分ける損益分岐

方式と保存先を決めても、取得の監視・失敗時の再取得・復旧テストを継続できなければ絵に描いた餅です。判断はこう分かれます。24時間365日の障害対応要員を自社で組めて、複数拠点の復旧手順を維持できるなら内製が合理的です。当番を組めない、担当者が兼任で運用が形骸化している、といった状態なら、取得から復旧支援までを担うMSP（マネージドサービスプロバイダー）への委託が現実的です。委託先の選び方や役割はMSPとは何かを解説した記事で整理しています。保守契約の範囲にバックアップからの復旧作業が含まれるかは契約ごとに違うため、システム保守の範囲と契約形態を解説した記事も確認しておくことが、委託後の抜け漏れを防ぐための備えです。設計から運用の代行、内製化の伴走まで含めた相談先が必要なら、一創の保守運用・内製化支援サービスで対応できます。

システムバックアップを採用する条件と見送ってよい場面の線引き

すべてのサーバーにイメージ単位のシステムバックアップが必要なわけではありません。採用すべきなのは、次のどれかに当てはまる場合です。OSやミドルウェアの設定が手作業で積み上がっていて、作り直す手順書が無い。RTOが数時間以内で、OSの再インストールから始めていては間に合わない。ライセンス認証や周辺機器の設定など、再現に社外の手配が要る要素を抱えている。

逆に、構成をコードで定義して数分で同じサーバーを作り直せる環境や、使い捨てのコンテナで動く処理は、イメージを取るより「構成定義とデータのバックアップ」を守る方が復旧は速く、保存費用も抑えられます。サーバーを更新せず作り直す運用の考え方はイミュータブルインフラの実装と採用判断を解説した記事で扱っています。この場合でも、データベースとファイル群のバックアップは省けません。見送ってよいのはイメージであって、データの保護ではない点を取り違えないでください。

よくある質問

システムバックアップの方式選びや運用でよく寄せられる質問に、発注者・情シスの視点で簡潔に答えます。

システムバックアップとファイルバックアップはどちらを選ぶべきですか？

二者択一ではなく併用が基本です。誤削除したファイルを素早く戻すにはファイルバックアップ、サーバー故障やOS破損からシステムごと立て直すにはシステムバックアップ（イメージ）が向きます。頻繁に変わる業務データは細かい単位で、システム全体は節目でイメージとして、と粒度を分けて両方を持つと、復旧の場面ごとに最短の手を選べます。

フルバックアップと増分バックアップはどのくらいの頻度で行いますか？

頻度はRPOから逆算します。目安として、週次または月次でフルを基準点として取り、日次や毎時で増分・差分を挟む構成が一般的でしょう。RPOを1時間に定めるなら毎時の取得が要り、日次で足りる業務なら夜間の1回で済みます。フルの間隔と増分の頻度を決める判断材料は、取得の負荷とストレージ、許容できるデータ損失幅の3点です。増分を挟む場合は、鎖が長くなるほど復元に要る本数が増えるため、フルの間隔を空けすぎないようにします。

バックアップデータはどこに保管するのが安全ですか？

3-2-1ルールに沿い、3つのコピーを2種類の媒体に分け、1つは遠隔地へ置くのが基本線です。本番と同じ拠点・同じディスクにコピーを固めると、火災や機器故障で一度に失います。オンプレの外部ストレージに加え、遠隔のクラウドを組み合わせると災害耐性が上がります。ランサムウェア対策としては、1系統をオフラインまたは書き換え不能な形で隔離しておくと確実です。

ランサムウェア対策としてバックアップだけで十分ですか？

取得しているだけでは足りません。警察庁の令和8年上半期の統計では、回答40件のうち29件がバックアップから復元できず、最多の理由はバックアップ自体の暗号化・消去でした。上書き・削除を一定期間禁じるイミュータブル保存や、回線から切り離したオフライン保管を1系統加えます。あわせて、実際に戻せるかを確かめる復旧テストと、侵入や異常を早く捉える監視を組み合わせて、初めて復旧できる備えになります。

バックアップの運用を外部に委託する費用の目安はどれくらいですか？

費用は保護対象の容量、取得頻度、RTO/RPOの厳しさ、24時間対応の有無で大きく変わるため、一律の相場より要件定義が先です。データ量が多く復旧時間の要求が厳しいほど、保存先の冗長化や即応体制のぶんコストは上がります。まず守るべきシステムと目標復旧時間を洗い出し、その要件に対して内製と委託の総額を比べる進め方が、過不足のない見積もりにつながります。