災害復旧計画入門｜中小企業が最低限やるべきBCP対策とバックアップ

なぜ中小企業こそ災害復旧計画が必要なのか

「災害復旧計画（DR: Disaster Recovery）は大企業がやるもの」と考えていませんか。実際には、中小企業こそ災害への備えが重要です。なぜなら、大企業と比べて経営資源が限られており、システム停止による影響が致命的になりやすいからです。

東日本大震災の際、適切なバックアップを持っていなかった中小企業の約25%が、データ損失により廃業に追い込まれたというデータがあります。また、総務省の調査によれば、BCP（事業継続計画）を策定している中小企業は全体の約15%に留まっており、多くの企業が「いつか対応しよう」と先延ばしにしているのが現状です。

しかし、災害復旧計画は決して難しいものではありません。クラウドサービスの普及により、低コストで実効性の高いDR体制を構築できるようになりました。本記事では、中小企業が今日から始められる災害復旧計画の立て方を、実務者の視点で解説します。インフラ設計全般については、少人数チームのインフラ設計も合わせてご覧ください。

中小企業が直面する災害復旧の課題

1. 「何から始めればいいか分からない」問題

多くの中小企業では、災害復旧計画の必要性は理解していても、具体的に何から手を付ければいいのか分からないという状況に陥っています。

実際に私が支援した製造業のA社（従業員60名）では、「バックアップは取っている」と言われましたが、詳しく聞いてみると、以下のような状況でした。

バックアップの保存場所: サーバーと同じオフィス内のNAS
バックアップ頻度: 週1回（手動で実行）
復旧テスト: 一度も実施したことがない
復旧手順書: 存在しない

これでは、オフィスが被災した場合、バックアップデータも一緒に失われてしまいます。また、復旧テストをしていないため、いざという時に本当に復旧できるか分かりません。

2. 予算の制約

「災害復旧システムにはお金がかかる」というイメージが先行し、取り組みが進まないケースも多く見られます。確かに、オンプレミスで完全なDR環境を構築しようとすると、数百万円〜数千万円の投資が必要になります。

しかし、クラウドを活用すれば、月額数万円からでも実効性の高いDR体制を構築できます。重要なのは、「完璧なDR」ではなく「現実的で実行可能なDR」を目指すことです。

3. 「うちは小さいから大丈夫」という油断

「大企業と違って、うちは小さな会社だから、システムが止まっても何とかなる」という考えは危険です。むしろ、中小企業の方がシステム停止の影響は深刻です。

EC サイトを運営するB社（従業員25名）では、サーバー障害により2日間サイトが停止した結果、売上が約80万円失われました。さらに、顧客からの信頼を失い、その後の売上にも影響が出ました。適切なDR体制があれば、数時間以内にサービスを復旧でき、被害を最小限に抑えられたはずです。

4. IT専任者がいない

中小企業では、専任のIT担当者がいないか、いても1-2名という場合が多く、災害復旧計画まで手が回らないという実情があります。

この問題を解決するには、「複雑なDR環境を構築する」のではなく、「シンプルで管理しやすいDR環境を構築する」ことが重要です。また、クラウドサービスの自動バックアップ機能を活用することで、日常的な管理負荷を大幅に軽減できます。

RTO と RPO の理解と設定

RTO と RPO とは

災害復旧計画を立てる上で、まず理解すべきなのが RTO と RPO という2つの指標です。

RTO（Recovery Time Objective: 目標復旧時間）: システムが停止してから、復旧するまでの目標時間です。例えば、「RTO = 4時間」であれば、災害発生から4時間以内にシステムを復旧させることを目指します。

RPO（Recovery Point Objective: 目標復旧時点）: どの時点のデータまで復旧できるかを示す指標です。例えば、「RPO = 1日」であれば、最大で1日分のデータ損失を許容します。

RTO と RPO の関係

一般的に、RTO と RPO を短く設定するほど、コストは高くなります。

RTO	RPO	コストレベル	適用対象の例
数分	ほぼゼロ	非常に高い	金融機関の基幹システム
1-4時間	1時間	高い	ECサイト、予約システム
4-24時間	1日	中程度	営業支援システム、業務アプリ
1-3日	1週間	低い	アーカイブデータ、過去の資料

業務ごとの RTO/RPO 設定例

卸売業のC社（従業員80名）では、以下のようにシステムごとに RTO/RPO を設定しました。

ECサイト（最優先）:

RTO: 2時間（売上に直結するため）
RPO: 1時間（最大1時間分の注文データ損失を許容）
理由: 2時間以上停止すると、顧客が他社に流れるリスクが高い

基幹システム（受発注・在庫管理）:

RTO: 4時間（営業時間内に復旧が目標）
RPO: 4時間（最大4時間分のデータ損失を許容）
理由: 停止すると業務が止まるが、半日程度なら手作業で対応可能

メール・グループウェア:

RTO: 24時間（1営業日以内）
RPO: 1日（前日夜時点まで復旧）
理由: 一時的に使えなくても、代替手段（電話、携帯メール）で対応可能

会計システム:

RTO: 3日（月次処理に間に合えば良い）
RPO: 1日（前日時点まで復旧）
理由: 日次での即時利用は必須ではない

このように、業務の重要度に応じて RTO/RPO を設定することで、コストを抑えながら実効性の高い DR 体制を構築できます。

RTO/RPO 設定のワークショップ

実際に RTO/RPO を設定する際は、IT部門だけでなく、各部門の責任者を集めてワークショップを実施することをおすすめします。

ワークショップの流れ:

システム一覧の作成（30分）全社で使っているシステムをリストアップします。
停止時の影響評価（60分）各システムが1時間、4時間、1日、1週間停止した場合の影響を議論します。

売上への影響
顧客への影響
業務への影響
法令・契約上の問題

RTO/RPO の設定（60分）影響評価をもとに、各システムの RTO/RPO を決定します。
予算とのバランス調整（30分）設定した RTO/RPO を実現するためのコストを概算し、予算内に収まるよう調整します。

ITコンサルティング会社のD社（従業員45名）では、このワークショップを実施した結果、「全システムを同じレベルで守る必要はない」ことが明確になり、メリハリのある DR 体制を構築できました。

3-2-1 バックアップルールの実践

3-2-1 ルールとは

バックアップの基本原則として、「3-2-1 ルール」があります。これは以下の3つの要素からなるルールです。

3: データのコピーを3つ持つ（本番1 + バックアップ2）
2: 2種類以上の異なる媒体に保存する（例: HDD + クラウド）
1: 1つは離れた場所（オフサイト）に保管する

このルールに従うことで、さまざまな災害シナリオに対応できます。

なぜ3つのコピーが必要か

シナリオ1: ローカルバックアップのみの場合

製造業のE社（従業員55名）では、サーバーのデータを毎日外付けHDDにバックアップしていました。しかし、落雷によりサーバーと外付けHDDが同時に故障し、全データを失いました。

もし、クラウドにも保存していれば、クラウドからデータを復元できたはずです。

シナリオ2: 単一媒体のみの場合

物流会社のF社（従業員70名）では、全てのバックアップをテープに保存していました。しかし、いざ復旧しようとしたところ、テープドライブが故障していて読み取れませんでした。

もし、一部をクラウドやHDDにも保存していれば、別の媒体から復元できたはずです。

実践例: 3-2-1 ルールの実装

小売業のG社（従業員40名）では、以下のように 3-2-1 ルールを実装しました。

1つ目のコピー: 本番環境（AWS）

本番サーバー上のデータ
場所: AWSの東京リージョン

2つ目のコピー: 日次バックアップ（AWS S3）

毎日深夜に自動バックアップ
保存先: AWS S3（オブジェクトストレージ）
保存期間: 30日間
場所: AWSの東京リージョン（本番と同じリージョン）

3つ目のコピー: 週次バックアップ（AWS S3 別リージョン）

毎週日曜日に自動バックアップ
保存先: AWS S3
保存期間: 13週間（約3ヶ月）
場所: AWSの大阪リージョン（本番と異なるリージョン）

4つ目のコピー: 月次バックアップ（Google Cloud Storage）

毎月1日に手動でバックアップ
保存先: Google Cloud Storage（別のクラウドプロバイダー）
保存期間: 12ヶ月
場所: Google Cloudの東京リージョン

この構成により、以下のシナリオに対応できます。

サーバー障害: 2つ目のコピー（日次）から数時間で復旧
AWS東京リージョン障害: 3つ目のコピー（週次、大阪）から復旧
AWS全体の障害: 4つ目のコピー（月次、Google Cloud）から復旧
ランサムウェア攻撃: 過去のバックアップから復旧

月額コスト: 約3.5万円

AWS S3（東京）: 約2万円
AWS S3（大阪）: 約1万円
Google Cloud Storage: 約5千円

バックアップの自動化

手動バックアップは必ず忘れるため、可能な限り自動化します。

自動化の例:

AWS Backup: AWS 上のリソースを自動バックアップ
Azure Backup: Azure 上のリソースを自動バックアップ
Google Cloud のスナップショットスケジュール
Veeam, Acronis などのバックアップソフトウェア

これらのツールを使えば、設定後は人手をかけずにバックアップが継続されます。

バックアップの暗号化

バックアップデータは機密情報を含むため、必ず暗号化して保存します。多くのクラウドサービスは、デフォルトで暗号化機能を提供しています。

AWS S3: サーバーサイド暗号化（SSE）を有効化
Azure Storage: Storage Service Encryption を有効化
Google Cloud Storage: デフォルトで暗号化される

さらにセキュリティを高めるには、バックアップ前にデータを暗号化してから保存する「クライアントサイド暗号化」も検討します。クラウドのセキュリティ設定については、クラウドセキュリティ基礎で詳しく解説しています。

クラウドを活用した低コスト DR 構築

クラウド DR のメリット

従来、DR 環境を構築するには、本番環境と同等のサーバーを別の場所に用意する必要があり、莫大なコストがかかりました。しかし、クラウドを活用することで、以下のメリットがあります。

初期費用がほぼゼロ: サーバーを購入する必要がなく、使った分だけ課金
平常時のコストが低い: DR 環境を常時稼働させる必要がなく、データ保存コストのみ
災害時に即座にスケール: 必要な時だけサーバーを起動し、必要なスペックで利用
地理的分散が容易: 複数の地域（リージョン）にデータを分散保存

Warm Standby と Cold Standby の選択

クラウド DR には、主に2つのアプローチがあります。

Warm Standby（ウォームスタンバイ）:

DR 環境を小規模ながら常時稼働させておく
災害時はスペックを拡張して切り替え
RTO: 数十分〜数時間
コスト: 中程度（本番の20-50%程度）

Cold Standby（コールドスタンバイ）:

平常時は DR 環境を停止し、バックアップデータのみ保存
災害時にサーバーを新規作成してデータを復元
RTO: 数時間〜1日
コスト: 低い（本番の5-10%程度）

中小企業には、コストを抑えられる Cold Standby がおすすめです。ただし、RTO が短いことが必須の重要システムには Warm Standby を検討します。

実践例: Cold Standby の構築

人材派遣会社のH社（従業員65名）では、以下のような Cold Standby 環境を構築しました。

本番環境（通常運用）:

場所: AWSの東京リージョン
Webサーバー: 2台
データベースサーバー: 1台
月額コスト: 約25万円

DR環境（平常時）:

場所: AWSの大阪リージョン
サーバー: 全て停止（稼働なし）
バックアップデータ: 毎日自動でS3に保存
自動構築スクリプト: 準備済み
月額コスト: 約2万円（ストレージのみ）

DR環境（災害時）:

自動構築スクリプトを実行
サーバーが自動的に作成される（約15分）
最新のバックアップからデータを復元（約45分）
DNSを切り替えてDR環境に向ける（約5分）
合計RTO: 約65分

年間コスト比較:

Cold Standby: 約24万円（月2万円 × 12ヶ月）
Warm Standby: 約120万円（月10万円 × 12ヶ月）
削減額: 約96万円

この構成により、低コストながら1時間強で復旧できる体制を実現しました。

DR 自動化のポイント

Cold Standby で重要なのは、復旧作業を自動化しておくことです。手作業に頼ると、災害時のパニック状態で手順を間違える可能性があります。

自動化すべき項目:

サーバーの作成（IaC: Infrastructure as Code）
アプリケーションのデプロイ
データの復元
DNSの切り替え
監視設定

Terraform、AWS CloudFormation、Azure Resource Manager などのツールを使えば、インフラ構成をコードとして管理でき、ワンコマンドで環境を再現できます。

復旧訓練の実施

なぜ復旧訓練が必要か

「バックアップは取っているから大丈夫」と思っていても、いざという時に復旧できなければ意味がありません。実際に復旧訓練を実施してみると、以下のような問題が発覚するケースが多くあります。

よくある問題:

バックアップファイルが壊れていて復元できない
復旧手順書が古く、現在の環境と合わない
復旧に必要なパスワードが分からない
復旧作業に想定以上の時間がかかる
データは復元できたが、アプリケーションが起動しない

これらの問題は、訓練をしなければ本番の災害時に初めて発覚します。

復旧訓練の頻度と内容

推奨頻度:

年2回（6ヶ月ごと）: フルスケールの復旧訓練
四半期ごと: バックアップからの部分復元テスト
月次: バックアップデータの整合性チェック

フルスケール復旧訓練の内容:

訓練のシナリオを決定（例: 「東京のデータセンターが被災」）
訓練開始時刻を予告（例: 土曜日の午前10時）
実際にDR環境を構築し、データを復元
アプリケーションが正常に動作するか確認
実際のエンドユーザーにテストしてもらう（一部の社員）
復旧にかかった時間を記録
問題点を洗い出し、改善策を検討

実践例: 訓練で発覚した問題と改善

不動産管理会社のI社（従業員50名）では、初めての復旧訓練で以下の問題が発覚しました。

発覚した問題:

データベースのパスワードが不明 前任者が設定したパスワードが引き継がれておらず、復旧できませんでした。 → 改善: パスワード管理ツール（1Password）にすべてのパスワードを記録
復旧手順書が古い 手順書は2年前に作成されたもので、現在のシステム構成と異なっていました。 → 改善: 手順書を最新化し、システム変更時に必ず更新するルールを策定
外部サービスとの連携設定が抜けていた 決済サービスとの連携設定が復旧手順に含まれておらず、決済ができませんでした。 → 改善: 外部サービスとの連携設定も復旧手順に追加
想定以上に時間がかかった RTO 4時間を目標にしていましたが、実際には7時間かかりました。 → 改善: 復旧作業を自動化し、次回訓練で2時間を達成

このように、訓練を実施することで初めて分かる問題が多くあります。訓練を繰り返すことで、実際の災害時にも落ち着いて対応できるようになります。

訓練結果の記録と改善

訓練後は必ず以下を記録し、改善に活かします。

記録すべき項目:

訓練実施日時
参加者
訓練シナリオ
実際の復旧時間（RTO達成度）
発覚した問題点
改善策
次回訓練の予定

これらを「復旧訓練報告書」としてまとめ、経営層にも共有します。

失敗しやすいポイントと対策

1. バックアップの保存場所が本番と同じ

失敗例: サーバーと同じオフィス内にバックアップを保存していたため、火災で両方とも失われた。

対策:

必ず離れた場所（オフサイト）にバックアップを保存する
クラウドストレージを活用する
最低でも1つは別の都市・地域に保存する

2. 復旧テストを一度もしていない

失敗例: バックアップは毎日取っていたが、いざ復旧しようとしたらバックアップファイルが壊れていて使えなかった。

対策:

少なくとも年2回は復旧訓練を実施する
月次でバックアップファイルの整合性チェックを行う
自動テスト機能があるバックアップツールを使う

3. 復旧手順書が存在しない、または古い

失敗例: 復旧手順書がなく、災害時に誰も復旧方法が分からなかった。または、手順書が古くて役に立たなかった。

対策:

詳細な復旧手順書を作成し、常に最新の状態に保つ
システム変更時は必ず手順書も更新する
手順書を見ながら訓練を実施し、手順の妥当性を確認する
復旧手順をできるだけ自動化する

4. RPO を誤解している

失敗例: 「毎日バックアップを取っているから、RPO は1日」と思っていたが、実際には最大2日分のデータ損失が発生しうる設計だった（深夜にバックアップを取り、翌日の夜に障害が発生した場合）。

対策:

RPO を正しく理解し、業務要件と照らし合わせて適切に設定する
バックアップ頻度と RPO を明確に紐付ける
重要なシステムはバックアップ頻度を上げる（数時間ごと、リアルタイムなど）

5. 復旧訓練が形骸化する

失敗例: 最初の1-2回は真剣に訓練を実施したが、次第に形骸化し、「訓練をやった」という記録を残すだけになった。

対策:

訓練のシナリオを毎回変える（様々な災害パターンを想定）
訓練結果を経営層に報告し、重要性を認識してもらう
訓練で発覚した問題の改善状況を次回訓練で確認する
外部の専門家に訓練を評価してもらう

導入事例: 食品卸売業J社の災害復旧体制構築

企業概要

業種: 食品卸売業
従業員数: 90名
システム: 受発注システム、在庫管理システム、ECサイト
課題: バックアップは取っているが、復旧できるか不安。実際に復旧テストをしたことがない。BCP対策が進んでいない。

Before（対策前の状況）

バックアップ体制:

バックアップ頻度: 週1回（日曜日の深夜）
保存場所: オフィス内のNAS（サーバーと同じ建物）
保存期間: 4週間（過去4回分）
復旧テスト: 一度も実施していない

想定される問題:

オフィスが被災した場合、バックアップも失われる
最大1週間分のデータ損失の可能性（RPO = 1週間）
バックアップから復旧できるか不明
復旧手順が明文化されていない

きっかけ: 取引先の大手スーパーから、「BCP対策の状況を報告してほしい」と要請があり、対策が不十分であることを認識。また、台風で同業他社が被災し、1週間営業できなかったニュースを見て、自社の体制に危機感を持った。

対策プロセス（4ヶ月）

Phase 1: 現状分析と RTO/RPO 設定（1ヶ月目）

まず、各システムの重要度を評価し、RTO/RPO を設定しました。

システム	停止時の影響	RTO	RPO
受発注システム	業務停止、顧客に迷惑	4時間	4時間
ECサイト	売上損失、信頼低下	2時間	1時間
在庫管理システム	業務効率低下	8時間	1日
会計システム	一時的には影響小	3日	1日

Phase 2: バックアップ体制の見直し（2ヶ月目）

3-2-1 ルールに基づき、バックアップ体制を再構築しました。

新バックアップ体制:

本番環境: AWSの東京リージョン
日次バックアップ: AWS S3（東京）、毎日深夜に自動実行、30日間保存
週次バックアップ: AWS S3（大阪）、毎週日曜に自動実行、13週間保存
月次バックアップ: Google Cloud Storage、毎月1日に自動実行、12ヶ月保存

コスト:

月額バックアップコスト: 約4万円
以前のNASの保守費用（年間12万円）を削減し、差額で対応

Phase 3: DR 環境の構築（3ヶ月目）

Cold Standby 方式で DR 環境を構築しました。

DR 環境: AWSの大阪リージョン
平常時は停止（コストは最小限）
復旧スクリプトを整備（Terraform で自動構築）
目標復旧時間: 2時間以内

コスト:

平常時の月額コスト: 約2万円（ストレージのみ）
災害時の月額コスト: 約30万円（本番並みのサーバーを稼働）

Phase 4: 復旧訓練と改善（4ヶ月目）

初回の復旧訓練を実施し、以下の問題が発覚しました。

発覚した問題:

ECサイトの画像ファイルが復旧スクリプトに含まれておらず、商品画像が表示されなかった
外部決済サービスとの連携設定が手順書に記載されていなかった
DNS切り替え後、反映されるまで想定以上に時間がかかった（20分）
復旧作業に2.5時間かかり、目標の2時間を超過した

改善策:

画像ファイルも含めて全データを復旧スクリプトに追加
外部サービス連携の手順を詳細化
DNSのTTL（Time To Live）を短く設定（24時間 → 5分）
復旧作業をさらに自動化し、手作業を減らした

2回目の訓練（1ヶ月後）:

復旧時間: 1時間20分（目標達成）
全ての機能が正常に動作
エンドユーザー（従業員10名）によるテストも実施し、問題なし

After（対策後の成果）

定量的な成果:

RPO: 1週間 → 1-4時間に短縮（システムにより異なる）
RTO: 不明（おそらく数日） → 2時間以内に確定
バックアップの保存場所: 1箇所 → 4箇所（3-2-1ルール達成）
復旧訓練: 未実施 → 年2回実施体制を確立

定性的な成果:

災害時の復旧に自信が持てるようになった
取引先からの信頼が向上した
従業員の安心感が増した
BCP対策が進んでいることを対外的にアピールできるようになった

取引先の反応:

大手スーパーのBCP監査で高評価を獲得
「中小企業でここまでやっているのは珍しい」と評価された
新規取引先との商談で、DR体制が評価材料になった

経営層のコメント: 「初期費用もほとんどかからず、月額4万円程度で安心を買えた。訓練を実施してみて、対策していないことがいかに危険だったかを実感した。今では、災害が起きても事業を継続できる自信がある。」

投資対効果

初期費用: 約70万円

コンサルティング費用: 50万円
DR環境構築費用: 10万円
訓練実施費用: 10万円

年間ランニングコスト: 約72万円

バックアップコスト: 月4万円 × 12ヶ月 = 48万円
DR環境維持費: 月2万円 × 12ヶ月 = 24万円

削減できたコスト: 約12万円/年

NAS保守費用の削減

実質年間コスト: 約60万円

期待される損失回避効果:

システム停止1日あたりの損失見込み: 約200万円（売上損失、信頼低下など）
適切なDR体制により、損失を最小限に抑制
5年に1度の災害を想定した場合の期待値: 約200万円 × 6日削減 ÷ 5年 = 年間約240万円の損失回避

正味の効果: 約180万円/年（損失回避 240万円 - コスト 60万円）

まとめ: 今日から始める災害復旧計画

災害復旧計画は「大企業がやるもの」「コストがかかるもの」ではありません。クラウドを活用すれば、中小企業でも低コストで実効性の高いDR体制を構築できます。

今日から始められる3つのステップ

Step 1: 現状を確認する（1週間）

現在のバックアップ体制を確認する
バックアップの保存場所を確認する（オフサイトにあるか？）
各システムの重要度を評価する
RTO/RPO を仮設定してみる

Step 2: 3-2-1 ルールを実現する（1ヶ月）

クラウドストレージにバックアップを保存する
バックアップを自動化する
異なる地域・媒体にバックアップを分散する

Step 3: 復旧訓練を実施する（2ヶ月）

復旧手順書を作成する
小規模でも良いので、実際に復旧訓練を実施する
問題点を洗い出し、改善する

最後に

「災害はいつか起きるもの」として、今から備えることが重要です。完璧な DR 体制を目指す必要はありません。まずは「現実的で実行可能な DR 体制」を構築し、徐々に改善していくアプローチをおすすめします。

もし専門的なアドバイスが必要な場合は、クラウドベンダー（AWS、Azure、Google Cloud）や、DR専門のコンサルタントに相談するのも良いでしょう。多くのベンダーが、中小企業向けの DR ソリューションを提供しています。

重要なのは、「いつか対応しよう」と先延ばしにせず、「今日から一歩ずつ進める」ことです。本記事が、あなたの会社の災害復旧計画の第一歩となれば幸いです。