バックアップがあっても、翌朝から仕事ができるとは限らない
たとえば、社内で使っているサーバーが故障したとします。バックアップは残っており、データそのものは復元できそうです。それでも翌朝、社員がいつもどおり仕事を始められるとは限りません。
データを戻す先の機器は用意できるのか。社内ネットワークは使えるのか。どのシステムから復旧するのか。誰が作業を担当し、どの順番で確認するのか。こうした点が決まっていなければ、「データはあるのに業務が動かない」という状態が起こり得ます。
ランサムウェアや機器故障でも、問題はデータを復元できるかどうかだけではありません。実際の業務を再開するまでには、機器、ネットワーク、作業手順、担当者など、複数の条件をそろえる必要があります。
ここでバックアップと分けて考えたいのが、DRです。DRはDisaster Recoveryの略で、日本語では「ディザスタリカバリ」「災害復旧」と呼ばれます。大掛かりな設備を用意することだけがDRではありません。中小企業でも、「何を、どのくらいの時間で、どこまで戻すか」を決め、復旧の手順と代替手段を準備しておくことから始められます。
DRとは何か——バックアップはデータを守り、DRは業務を再開する
バックアップの目的は「データを戻せる状態をつくる」こと
バックアップは、失われたデータを復元するための備えです。ファイルや業務データを別の場所に保存し、必要になったときに元へ戻せるようにします（→ 失敗しないバックアップ運用の記事）。
この意味で、バックアップはDRの重要な要素です。しかし、バックアップが存在することと、業務を再開できることは同じではありません。
たとえばデータを復元できても、それを動かす機器がなければ業務システムは使えません。機器があってもネットワークが使えなければ、社員がそのシステムへ接続できない場合があります。さらに、復旧作業の担当者や手順が決まっていなければ、何から着手するかの判断に時間がかかります。
DRは「仕事を再び動かすところまで」を考える
DRは、障害などで止まったIT環境を復旧し、業務を再開するまでを扱います。
違いを短く整理すると、バックアップは「データを守る」、DRは「業務を再開する」です。
この違いを意識すると、確認すべき対象が広がります。バックアップの有無だけでなく、復元先、ネットワーク、利用する端末、担当者、作業順序、通常環境が使えない場合の代替手段まで考える必要があります。
だからといって、最初から大規模なDR環境を整える必要はありません。重要なのは、自社の業務にとって何が止まると困るのかを基準に、必要な復旧方法を決めることです。
RTOとRPOは、専門用語ではなく「業務の質問」に置き換える
DRを考えるときによく使われるのが、RTOとRPOです。
RTO（Recovery Time Objective）は「復旧までの目標時間」、RPO（Recovery Point Objective）は「どの時点のデータまで戻すかの目標地点」です。
言葉だけを見ると難しく感じますが、中小企業では業務上の質問に置き換えると判断しやすくなります。
RTOは「何日、何時間止まると困るか」
RTOを考えるときは、「何時間で復旧させるべきか」といきなり数字を決めるよりも、まず業務への影響を考えます。
たとえば、請求業務について「3日止まっても業務は回るか」と考えます。もし一定期間は別の作業を進められるのであれば、その業務を最優先で復旧する必要はないかもしれません。反対に、止まることで他の業務も進まなくなるのであれば、より早い再開を目標にする必要があります。
つまりRTOは、システムの性能から決めるのではなく、「その業務をどのくらい止められるか」から逆算して考えるものです。
RPOは「どこまでデータが戻れば仕事を続けられるか」
RPOでは、「昨日の受注データが消えたら困るか」のように考えます。
前日の状態まで戻れば手作業で補える業務もあれば、直前までのデータが必要な業務もあります。重要なのは、すべてのデータに同じ基準を当てはめないことです。
RTOとRPOを業務ごとに考えると、「どのシステムを先に戻すか」「どの時点までデータを戻せるようにするか」「どこまで代替手段を用意するか」を決めやすくなります。
まずは厳密な数値を作ることより、「この業務はどれくらい止められるか」「どの時点まで戻れば成り立つか」を関係者で言葉にすることが出発点です。
中小企業のDRは、4段階で現実的に進める
1. 止まると困る業務とシステムを書き出す
最初に行うのは、システムの一覧作成ではなく、業務の優先順位を決めることです。
「止まったら翌日の仕事に影響する業務は何か」「数日後でもよい業務は何か」を考え、その業務がどのシステムやデータに依存しているかを書き出します。
ここで優先順位をつけておけば、障害時にすべてを同時に復旧しようとせず、必要なものから着手できます。
2. 復旧手順を1枚にまとめる
次に、「誰が・何を・どの順で行うか」を簡潔にまとめます。
必要なのは立派な文書ではなく、障害が起きたときに見て動ける手順です。たとえば、状況を確認する担当者、バックアップを確認する担当者、復旧対象を判断する人、業務再開を確認する人を決め、作業の順序を並べます。
担当者しか分からない手順になっている場合は、その人が対応できない状況も考える必要があります。DRでは、技術だけでなく「誰が動くか」も復旧条件の一部です。
3. 通常環境が使えないときの代替手段を決める
復旧に時間がかかる場合に備え、一時的に業務を続ける方法も決めておきます。
業務によっては、一時的に手作業へ切り替える方法があります。社内の場所が使えなければ、別の場所から業務を再開する方法を考えることもできます。必要に応じて、クラウド上の代替環境を用意するという選択肢もあります。
すべてを同じ方法で代替する必要はありません。止められない業務に絞って代替手段を考えるほうが、中小企業では現実的です。
4. 年に一度、手順どおりに動くか確認する
手順は、作っただけでは十分ではありません。年に一度は、決めた流れで復旧できるかを確認します。
確認したいのは、バックアップからデータを戻せるかだけではありません。担当者が手順を理解しているか、必要な情報にアクセスできるか、復旧後に業務を再開できるかまで見ます。
実際に確認すると、手順の抜けや、特定の担当者に依存している部分が見つかることがあります。その内容を手順へ反映し、次回の確認につなげます。
DRはBCPの「ITを復旧する部分」と考えると分かりやすい
DRとあわせて出てくる言葉に、BCPがあります。BCPはBusiness Continuity Planの略で、日本語では「事業継続計画」です。
BCPは、非常時にも事業を継続するための全社的な計画です。その中で、システムやデータなどIT環境の復旧を扱う部分がDRにあたります。
そのため、DRだけですべての事業継続対策が完結するわけではありません。IT以外も含めて全社的な計画を考える場合は、中小企業庁が公開している「中小企業BCP策定運用指針」が参考になります。
一方、まだBCP全体を整備していない会社でも、まず止まると困る業務を決め、必要なシステムの復旧手順を作ることはできます。DRを入口に、自社の事業継続を具体的に考え始める方法もあります。
まとめ——「データが戻る」と「業務が再開できる」は別に確認する
バックアップがあれば、データを復元する準備はできます。しかし、業務を再開するには、復元先の環境、ネットワーク、手順、担当者、代替手段まで含めて考える必要があります。
DRを検討するときは、まず次の点を確認すると整理しやすくなります。
- 止まると困る業務は何か
- その業務をどのくらいの時間で再開したいか
- どの時点のデータまで戻れば業務が成り立つか
- 誰が、何を、どの順で復旧するか
- 通常の環境が使えない場合に、どう業務を続けるか
- 決めた手順を実際に確認したことがあるか
バックアップの有無だけを確認して終わらせず、「この状態から本当に仕事を再開できるか」まで考える。その視点が、中小企業でDRを始めるための基準になります。
代替手段の一つである「別の場所からの業務再開」には、社外から社内システムへ安全に接続する経路が必要です。ForceLinkは、許可した利用者だけが指定した社内PC・サーバー・NASへ接続するリモートアクセスで、オフィスに入れない状況でも自宅や別拠点から業務を再開する経路として使えます。ただし、現時点で多要素認証（MFA）には未対応のため、MFAを必須要件とする場合は要件に合う構成を別途ご確認ください。攻撃を想定したバックアップ設計はランサムウェア対応型バックアップの記事で、自社の構成に合わせた考え方はお問い合わせでご相談いただけます。