--- title: "サーバーのBCP対策｜サーバーダウンに備えるRTO・RPOの決め方と構成・バックアップ" url: "https://www.issoh.co.jp/column/details/10986/" published: 2026-02-16 updated: 2026-10-12 categories: ["インフラ"] publisher: "株式会社一創" --- # サーバーのBCP対策｜サーバーダウンに備えるRTO・RPOの決め方と構成・バックアップ サーバーのBCP対策とは、地震や停電、故障、サイバー攻撃でサーバーが使えなくなっても、業務を決めた時間内に再開し、失ってよい範囲を超えてデータを失わないための事前の備えです。中身は「どのサーバーを、何時間以内に、どの時点のデータで戻すか」を決め、その目標に届く構成とバックアップを用意し、切り替えを訓練しておくことに尽きます。この記事では、停止原因の整理、目標値の決め方、構成の選び方、ランサムウェアを前提にしたバックアップ、切替が遅れる原因、障害発生時の初動の順に解説します。BCPそのものの意味は[BCPとは？事業継続計画の意味と防災計画との違い、RTO・RLOの決め方](/column/details/10933/)を参照してください。 ## まとめ：サーバーBCP対策の要点 - サーバー停止は原因（地震・故障・攻撃）ではなく「サーバーが使えない」「データが失われた」という結果で整理すると、対策が重複しない - 目標はサーバー単位でなく業務単位で決め、RTO（何時間で戻すか）とRPO（どの時点まで戻すか）をサーバーに割り当てる - AWSの代表的な復旧戦略はバックアップ復元・パイロットライト・ウォームスタンバイ・マルチサイトの4つ。必要な目標を満たす構成から、費用と運用負荷を比べて選ぶ - 令和7年のランサムウェア被害でバックアップから復元できたのは99件中20件。バックアップは攻撃者が触れない場所に置き、復元テストまでして初めて有効になる - 切替が遅れる原因になりやすいのはDNS・認証基盤・ライセンスなど周辺の依存先。定期的に実際に切り替えて時間を測る ## サーバーダウンの原因と、BCPで「結果」から考える理由 サーバーダウンは、サーバーが停止または応答しなくなり、その上で動く業務やサービスが使えなくなる状態を指します。原因は大きく、ハードウェアの故障（ディスク・電源ユニット・メモリ）、電源や回線の途絶（停電・通信障害）、処理の過負荷（アクセス集中・リソース枯渇）、ソフトウェアの不具合や設定・操作ミス、サイバー攻撃の5系統に分かれます。Webサーバーが503を返す場合の切り分けは[503エラーとは？原因の切り分けと復旧・再発防止をサーバー実装目線で解説【2026年版】](/tech/details/13172/)で扱っています。 BCPの計画では、この原因を一つずつ章立てにする必要はありません。内閣府の[事業継続ガイドライン](https://www.bousai.go.jp/kyoiku/kigyou/pdf/guideline202303.pdf)（令和5年3月）は「BCMでは、自社に生じた事態を原因事象（例えば、直下型地震）により考えるのでなく、結果事象（例えば、自社の○○拠点が使用不能）により考え、対応策を検討することが推奨される」としています。サーバーに当てはめると、結果は次の3つに集約できます。 | 結果事象 | 主な原因 | 効く対策 | | -------------- | ----------- | ------------- | | サーバーが一時的に使えない | 故障・停電・過負荷 | 冗長化・UPS・自動切替 | | 拠点ごとサーバーが使えない | 地震・水害・建物の停電 | 別拠点やクラウドの復旧環境 | | データが壊れた・暗号化された | 攻撃・操作ミス・不具合 | 隔離した世代バックアップ | 注意したいのは3つ目です。冗長化やレプリケーションは1つ目と2つ目には効きますが、データの破損や暗号化もそのまま複製先へ伝わります。冗長化をバックアップの代わりにはできません。冗長化の方式は[冗長化とは？二重化との違い・種類と構成、企業の設計判断まで解説【2026年版】](/column/details/13356/)で詳しく比べています。 ## サーバーごとのRTO・RPOの決め方 RTO（目標復旧時間）は停止から業務を再開するまでの時間、RPO（目標復旧時点）は復旧後のデータがどの時点のものになるか、つまり失ってよいデータの幅です。RTOは構成と手順で、RPOはバックアップやレプリケーションの頻度で決まります。 ### 業務からサーバーへ目標を割り当てる手順 サーバー単位で目標を決める前に、そのサーバーを使う業務と停止による影響を整理します。ファイルサーバーなら、受注処理や出荷指示など、共有ファイルを使う業務ごとに許容停止時間を確認します。次の順で業務から逆算します。 1. 止まると売上・顧客対応・法令上の期限に響く業務を選ぶ（受注、出荷、決済、給与など） 2. 業務ごとに、停止による影響が許容限界に達する前の復旧目標時間（RTO）と、失っても業務上許容できるデータの範囲に対応する復旧時点（RPO）を担当部門と決める 3. その業務が使うサーバーと、サーバーが依存する周辺（DNS、認証基盤、データベース、ネットワーク機器）を洗い出す 4. 複数の業務が使うサーバーには、最も厳しい目標を当てる 4つ目が予算超過の原因になりがちです。たとえば受注システムと社内掲示板が同じ仮想基盤に載っていると、掲示板まで受注と同じ構成で守ることになります。重要度の違う業務は、移行の機会にサーバーを分けておくと費用を抑えられます。 ### IPA非機能要求グレードによるRTO・RPOの段階 部門と目標値を話し合うときは、IPAの「[非機能要求グレード2018](https://www.ipa.go.jp/archive/files/000066170.pdf)」の段階が共通の物差しになります。業務停止を伴う障害時の目標復旧水準として、次のレベルが定義されています。 | レベル | RTO（目標復旧時間） | RPO（目標復旧地点） | | --- | ----------- | ---------------------- | | 0 | 1営業日以上 | 復旧不要 | | 1 | 1営業日以内 | 5営業日前の時点（週次バックアップ） | | 2 | 12時間以内 | 1営業日前の時点（日次バックアップ） | | 3 | 6時間以内 | 障害発生時点（日次バックアップ＋アーカイブ） | | 4 | 2時間以内 | （定義なし） | 同じグレードでは稼働率も95%以下から99.999%までの6段階で示されています。24時間365日稼働を前提にすると、99.9%は年間約8.8時間、99.99%は年間約53分の停止に当たります。稼働率の計算と高可用性の設計は[可用性とは？稼働率の計算と高可用性の設計をインフラ実装目線で解説【2026年版】](/tech/details/13423/)で扱っています。 ## RTO・RPOから選ぶサーバーの復旧構成 目標が決まれば、構成の候補を絞り込めます。AWSのWell-Architectedフレームワーク（[信頼性の柱 REL13-BP02](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel%5Fplanning%5Ffor%5Frecovery%5Fdisaster%5Frecovery.html)）は、復旧構成を4つに分け、それぞれの目安を示しています。 | 構成 | RPOの目安 | RTOの目安 | 平常時の復旧側 | | ------------------- | ------ | ------- | --------- | | バックアップと復元 | 時間単位 | 24時間以内 | バックアップのみ | | パイロットライト | 分単位 | 数十分 | データ複製のみ稼働 | | ウォームスタンバイ | 秒単位 | 分単位 | 縮小構成で常時稼働 | | マルチサイト（アクティブ/アクティブ） | ほぼゼロ | ゼロもあり得る | 本番と同等で稼働 | 同じページは「必要以上に厳格な戦略の実装は避けるべき」とも書いています。RTOを12時間以内、RPOを1営業日前に設定する社内システムでは、日次バックアップと復元手順が候補になります。ただし、環境の準備、データ復元、業務再開の確認を含む訓練で、目標を満たせるか検証が必要です。ウォームスタンバイ以上は、数十分の停止が売上、安全、法令上の義務などに重大な影響を与え、より簡素な構成では目標を満たせないサーバーで検討します。各構成の作り方とDR計画の書き方は[DR対策とは？構成4パターンのRPO・RTO目安とDR計画の作り方](/column/details/9439/)にまとめています。 ### オンプレミスとクラウドで変わる手段と費用の出方 オンプレミスで別拠点に復旧環境を持つと、使わない期間もラック・回線・機器の費用がかかり、機器の更新も二重になります。AWSのパイロットライトでは、復旧側のデータ複製などの中核部分を維持し、アプリケーションサーバーなどを障害時に起動・追加します。常時稼働するリソースや保存データには平常時も費用がかかります。一方で、クラウドに移しても利用者側の設定ミスやデータ削除は事業者が戻してくれるとは限りません。何が事業者の責任で、何が自社の責任かは契約とSLAで確認します。判断の手順は[BCP対策はクラウドとオンプレミスどちらに置くか｜責任分界とSLAで決める判断基準](/column/details/10989/)で解説しています。 オンプレミスに残すサーバーには、構成とは別に設置環境の手当てが要ります。UPSで停電直後の数分〜数十分をつなぎ、その間に安全に停止するか発電機へ切り替える設定、ラックの転倒防止、浸水しない階への設置です。UPSは停電に備えるものですが、自動停止のスクリプトを試していなければデータベースが不正終了するので、停止動作まで確かめておきます。 ## ランサムウェアを前提にしたバックアップ設計 サーバーBCPで最も前提が変わったのがランサムウェアです。警察庁「[令和7年におけるサイバー空間をめぐる脅威の情勢等について](https://www.npa.go.jp/publications/statistics/cybersecurity/data/R7/R07%5Fcyber%5Fjousei.pdf)」によると、令和7年の被害報告は226件でした。攻撃者は侵入後に重要データやバックアップを物色し、同資料は「復旧を妨害するため、バックアップも一緒に暗号化される場合が多い」と書いています。 結果は数字に出ています。同資料の統計編（被害組織へのアンケート）で、バックアップから復元できたのは有効回答99件のうち20件でした。復元できなかった理由（有効回答72件）は、バックアップの暗号化・消去が48件、運用不備が19件、その他が5件です。「バックアップを取っている」ことと「戻せる」ことの間には大きな差があります。調査・復旧費用の総額が1,000万円以上だったのは、この設問の有効回答89件中46件で5割を超えます。復旧期間の設問（有効回答107件）では、1か月未満で復旧したのは60件で、25件は回答時点でも復旧中でした。 アスクルの事例が典型です。同社の[第13報](https://prtimes.jp/main/html/rd/p/000000500.000021550.html)（2025年12月12日）は、物流システムが暗号化され「同データセンター内のバックアップファイルも暗号化されたため、復旧に時間を要しました」と説明し、攻撃者がランサムウェアの展開と同時に「バックアップファイルの削除も同時に行われた」ことも確認しています。経緯は[アスクルのシステム障害はいつ復旧した？受注停止から全面再開までの経緯と現状【2026年10月】](/column/details/9401/)にまとめています。 ### 攻撃者が届かないバックアップの条件 米CISAの[#StopRansomware Guide](https://www.cisa.gov/stopransomware/ransomware-guide)は、重要データのバックアップをオフラインかつ暗号化して保持し、災害復旧の想定で可用性と完全性を定期的にテストするよう推奨しています。サーバーBCPに落とすと、次の4点を満たすかで判断できます。 - **オフライン保管と変更不能な保管を区別して確保する**：テープや取り外す外付け媒体はネットワークから切り離せるオフライン保管、クラウドのオブジェクトロックのように書き換え・削除を一定期間禁止する機能は変更不能な保管で、接続は残る。両者は別物なので、最低1世代はオフラインに置く - **バックアップの管理権限が本番と別**：ドメイン管理者を奪われてもバックアップ装置にはログインできない認証にする。共通のActive Directoryに参加させない - **複数世代を保持している**：暗号化に気づくまでの潜伏期間より長く遡れる世代数を持つ - **復元テストをしている**：運用不備で戻せなかった19件は、取得の失敗や手順の不在が原因になり得る。少なくとも重要サーバーは実際に別環境へ戻して時間を測る フル・差分・増分の選び方と取得手順は[システムバックアップとは？フル・差分・増分の違いと取得手順・方式の選び方を解説](/column/details/13448/)、NASが暗号化された大学の事例は[佐賀大学のランサムウェア被害と事務NASの暗号化｜4日で業務再開した初動と戻せるバックアップ](/tech/details/18097/)で取り上げています。 ### サイバー攻撃後の復元前に必要な安全性確認 地震や故障なら、目標時間内に戻すことが最優先です。攻撃の場合はそうはいきません。警察庁の同資料は、ランサムウェアによる暗号化は物理的災害とは被害の状況が異なり、調査・復旧作業や広報も異なる対応が求められるため、サイバー攻撃を想定したBCPを事前に準備しておく必要があるとしています。侵入経路が残ったまま復元すれば、再び暗号化されるからです。アスクルは「汚染の可能性を残した既存環境を部分的に修復するのではなく、安全が確認された新しい環境をゼロから構築する方式」を採りました。攻撃用のシナリオでは、RTOに調査と環境の再構築の時間を含めて見積もり直します。 ## 切替が遅れる原因：DNS・認証・ライセンスの見落とし 復旧環境もバックアップもあるのに切替に時間がかかり、復旧が遅れることがあります。確認対象には、対象サーバー以外の依存先も含まれます。DNS、認証基盤、ライセンスなどを設計書と照合し、切替訓練で動作を確認します。 | 見落としやすい依存先 | 切替時に起きること | 事前の手当て | | ------------ | ---------------- | --------------- | | DNSのTTL | 旧IPへの接続がTTLの間残る | 切替対象のTTLを短くしておく | | 認証基盤（AD・IdP） | 復旧側でログインできない | 認証基盤も復旧側に置く | | ライセンス・証明書 | ホスト名やMAC変更で起動しない | 復旧側の認証方式を確認 | | IP許可リスト | 取引先や外部APIが接続を拒否 | 復旧側のIPを事前登録 | | 暗号鍵・パスワード | バックアップを復号できない | 鍵を本番と別の場所に保管 | 人の要素も同じです。切替を判断できる権限者が被災して連絡がつかない場合や、手順書が本番環境の中にあって読めない場合も想定します。判断の代行順位と、手順書の紙またはオフラインの控えを用意しておきます。 ## サーバー障害が起きたときの初動手順 障害の発生時は、原因の特定より先に影響範囲と切替判断を進めます。初動の順序は次のとおりです。 1. **検知と影響範囲の把握**：止まっている業務と、止まったサーバー・依存先を特定する 2. **原因の大分類**：ハードウェア・電源・回線か、ソフトウェア・設定か、攻撃の疑いかを切り分ける。暗号化されたファイルや脅迫文があれば攻撃として扱う 3. **攻撃の疑いがあれば隔離と保全**：ネットワークから切り離し、ログを保全する。メモリ上の痕跡を保全するため、原則として電源断・再起動・初期化を避ける。ただし、ネットワークから隔離できず感染拡大を止められない場合は、電源断による封じ込めを検討する 4. **切替の判断**：障害発生からの経過時間と切替所要時間を含めてRTO内に再開できるか判断する。攻撃が疑われる場合は、復旧環境と復元データの安全性を確認してから切り替える 5. **関係者への連絡**：社内、取引先、保守ベンダーに加え、攻撃なら警察や個人情報保護委員会への報告要否を確認する 6. **復旧後の検証**：データの欠落範囲（RPOとの差）を確認し、欠けた分の再入力手順を業務部門と決める システムが戻るまでの間、業務を手作業でつなぐ代替手順は、サーバー側ではなくIT-BCP全体の論点です。[情報システム担当者が最初に押さえるべきIT-BCPの定義と通常BCPとの本質的な違い](/column/details/10997/)もあわせて確認してください。 ## 計画書の章立てと訓練・見直しのタイミング 計画書の章立ては、内閣官房 国家サイバー統括室の「[政府機関等における情報システム運用継続計画ガイドライン（第3版）](https://www.cyber.go.jp/pdf/policy/general/itbcp1-1%5Fr7.pdf)」（令和7年7月）の構成が参考になります。目的と基本方針、危機的事象発生時の対応計画、事前対策計画、教育訓練計画・維持改善計画、計画策定の根拠とした調査・分析・検討の5部構成です。政府機関向けの資料ですが、章立ての型は民間のサーバーBCPにもそのまま使えます。なお、内閣サイバーセキュリティセンター（NISC）が令和3年4月に作成した旧第3版は、組織改正に伴い令和7年7月に廃止され、同月に国家サイバー統括室名義で作成し直されています。 訓練は次の3種類を分けて行います。 - **切替訓練**：重要サーバーを実際に復旧環境へ切り替え、RTO内に業務が再開できるかを時間で測る - **復元テスト**：バックアップから別環境へ戻し、データが読めるか、RPOどおりの時点かを確かめる - **机上訓練**：攻撃シナリオで、隔離・連絡・切替判断を誰が行うかを確認する 実施間隔に一律の決まりはありません。この記事では年1回を最低ラインとして勧め、重要度が高く構成の変更が多いサーバーほど間隔を詰めます。加えて、サーバーの更改、クラウド移行、担当者の異動のたびに見直します。構成が変わったのに計画が古いままだと、手順書の切替先がすでに存在しないといったずれが起きます。測った復旧時間がRTOを超えたら、構成を上げるか、業務部門と目標を見直すかを決めます。訓練で測った値が、次の予算を説明する根拠になります。 ## よくある質問 ### サーバーダウンとは何ですか？ サーバーが停止または応答しなくなり、その上で動く業務やWebサービスが使えなくなる状態です。原因はハードウェア故障、停電・回線障害、アクセス集中による過負荷、ソフトウェアの不具合や設定ミス、サイバー攻撃に分かれます。 ### 冗長化していればバックアップは不要ですか？ 不要にはなりません。冗長化は機器や拠点の停止に備えるもので、データの破損や暗号化は複製先にも伝わります。誤削除やランサムウェアから戻すには、本番と切り離した世代バックアップが別に必要です。 ### RTOとRPOの違いは何ですか？ RTOは停止から業務再開までの目標時間、RPOは復旧したデータがどの時点のものになるかの目標です。RTOは復旧構成と手順で、RPOはバックアップやレプリケーションの頻度で決まります。 ### ウォームスタンバイとは何ですか？ 復旧側に本番より小さな構成を常時稼働させておき、障害時に規模を拡大して切り替える方式です。AWSの目安ではRPOは秒単位、RTOは分単位で、中核部分だけを維持するパイロットライトに比べ、起動・追加する処理を減らせる一方、平常時の稼働リソースは増えます。 ### クラウドに移せばサーバーのBCP対策は終わりですか？ 終わりません。事業者側の設備障害には強くなりますが、利用者の設定ミスやデータ削除、認証情報の窃取による被害は利用者の責任範囲に残ります。別リージョンや別アカウントへのバックアップ、切替訓練は自社で用意します。 ## 関連記事 - [DR対策とは？構成4パターンのRPO・RTO目安とDR計画の作り方](/column/details/9439/) - [冗長化とは？二重化との違い・種類と構成、企業の設計判断まで解説【2026年版】](/column/details/13356/) - [システムバックアップとは？フル・差分・増分の違いと取得手順・方式の選び方を解説](/column/details/13448/) - [BCP対策とは？企業が備える具体策を6つの観点で整理｜費用・事例・体制](/column/details/10933/) - [BCP対策はクラウドとオンプレミスどちらに置くか｜責任分界とSLAで決める判断基準](/column/details/10989/) --- 出典: [サーバーのBCP対策｜サーバーダウンに備えるRTO・RPOの決め方と構成・バックアップ]()（株式会社一創）