自然災害からランサムウェアまで、どの組織もウェブベースのシステムで予期せぬダウンタイムが発生するかもしれないという潜在的な問題を抱えています。大規模な機能停止が発生しても自社の業務が耐えられるようにするには、準備が鍵となります。そしてそれは、何よりもまず目標復旧時間を定めることから始まります。目標復旧時間（RTO）と目標復旧時点（RPO）の算定は、障害復旧計画の成功と事業継続性の維持に欠かせません。しかし、それらは正確には何を意味するのでしょうか。RTOとは、システム停止やデータ損失が起こった場合に、業務やサービス品質保証（SLA）に甚大な影響を与えることなく、コンピューター、システム、ネットワーク、アプリケーションを復旧するために必要な時間量の最大値のことです。RTOとよく似ているのがRPOで、業務に多大な影響が及ぶことなく組織が対処できるデータ損失量の最大値を指します。
RTOは事業運営の継続性の確保にとって重要な意味合いをもっていますが、さまざまなシステムとアプリケーションのRTOの価値を考慮することは、データベースバックアップのタイミングやリカバリ戦略にも直接影響してきます。RTOとは、システム停止またはデータ損失のいずれかが発生した時点から、システムが正常に復旧してオンライン化するまでの時間量であるため、RTOをデータベースバックアップ計画に組み込んでおく必要があります。以下では目標復旧時間の重要な側面について詳しく説明していきますので、ぜひお読みください。
RTOの重要性
RTOの「目標」は、業務のシステムとデータを機能停止の発生前の状態に戻すことです。そのスケジュールは 状況に応じて異なります。設定するRTOは、システムやデータの重要度に応じて、アプリケーションとデータごとにさまざまですが、いずれのRTOもリカバリ計画を策定するうえでの基盤となります。RTOを短縮するための費用と、適切なタイミングで復旧する重要性とのバランスを考慮することが重要です。RTOの算定には、ダウンタイムが1時間（または1分）ごとに組織にもたらすコストに加え、システム復旧やデータ復元に必要なコストと手順の判断も含まれます。最も重要なのは、確実にRTOを算定することです。これは戦略を定める際に役立ちますが、貴社におけるデータ量と利用可能なリソースを考慮に入れた、一般的なRTO時間も把握しておく必要があります。ミッションクリティカルなシステムがダウンした場合に、どの程度の早さで復旧できるかを把握しておくことが大切です。
完璧なRTOとは何か、という問いの明白な答えは「ほぼゼロ」であるように思われるかもしれませんが、必ずしもそうとは言えません。貴社の事業には必要のないRTOを確保するための手順とプロセスに、過度の時間と費用を前もって費やすことになりかねないのです。当面の間、紙での請求書や書類に戻すことが簡単にできる企業であれば、完全にウェブベースの企業ほど、短時間のRTOの実現に多額の費用を費やす必要はありません。その一方で、オンラインシステムやデータへの依存度がかなり高い場合や、厳格なサービスレベル契約（SLA）を満たす必要がある場合には、ほぼゼロのRTOの実現に向けた労力とコストをかける価値があると思われます。設定したRTOが長すぎる場合、機能停止の発生後に「無事」にRTOを達成したとしても、その期間に時間、費用、評判の面で修復不能の損害が生じていることが後に明らかになるかもしれません。
データ復旧およびシステム復元にかかるコストと、それらのシステムがダウンしている間のコストとのバランスを見出すには、周到かつ徹底的なビジネスインパクト評価と障害復旧計画が必要です。どの程度の期間かにかかわらず、設定するRTOが達成可能であり、目的に適合しているよう徹底することは、あらゆる企業にとって機能停止からの復旧の鍵となります。達成不可能なRTOを設定してしまうと、最終的に、ビジネスが回復不能の損害に見舞われることになりかねません。RTOを考える際はRPOを考慮に入れる必要があります。バックアップ計画とリカバリ計画はこれらに基づいて策定されます。データ喪失事象の時系列を考えると、RPOタイマーはインシデント発生時から過去に向かってカウントされ、RTOタイマーは未来に向かってカウントされます。これらは最大許容値である点も忘れないようにしましょう。RPOを6時間に設定したワークロードにする場合は、少なくとも6時間ごとに復元可能なバックアップを取得しなければなりません。他にも、バックアップには多くの場合、プライマリストレージからバックアップストレージへの大量のデータ転送が伴うので、実際のバックアップ取得プロセスも考慮に入れる必要があります。1時間ごとのバックアップが求められるワークロードであるにもかかわらず、実際のバックアッププロセスに80分かかるのであれば、設定したRPOを達成するのはどうやっても不可能です。
説明が長くなってしまいました。例を挙げた方が分かりやすそうですね。
Zaffre Fashion Group社の人事部門は、年次休暇の予約システムにおいて、ディザスタ発生時に喪失しても構わないデータの最大量を6時間分と定めています。これが同社のRPOです。このため、同社のアプリケーションデータは毎日深夜0時、午前6時、正午、午後6時にバックアップされています。同社ではディザスタ発生時にサービスを2時間以内に復旧する必要があると定めています。これが同社のRTOです。例えば、データ喪失事象を午前9時に検知した場合、RTOのカウントダウンはその時点から開始されるため、同社は午前6時のバックアップから復旧し、午前11時までに正常な稼働状態に戻すことができます。
目標復旧時点：6時間
目標復旧時間：2時間
最後の定期データバックアップの完了：午前6時
次回の定期データバックアップ：午後12時
データ喪失インシデント：午前9時
サービス復旧：最長でも午前11時
RTOとRPOについて調べていると、「実際の復旧時間」を表すRTAという用語も目にすることでしょう。この用語は、データ喪失インシデントを検知してから、サービスを完全に復旧させるまでにかかった実際の時間を指します。多くの場合、この時間はRTOよりも短くなりますが、最長でもRTOと同じ値にする必要があります。上記の例では、Zaffre Fashion GroupのIT部門の対応はほとんど完璧で、9時12分にサービスを復旧できました。このケースでのRTA（実際の復旧時間）は12分であり、実に素晴らしい対応です。
次に、同じシナリオでも、復旧時間が12分ではなく実質的に3時間にまで延び、設定したRPOを1時間超過する形となった場合を想像してみてください。どのような悪影響が生じるでしょうか。そのような深刻な事態を回避するには、システム間およびデータ間の優先順位を定め、システム停止時間あたりのコスト（金銭面だけでなく、評判、顧客サービス、従業員の安全、SLA、法的な面での影響などもあわせて）、復旧ソリューションの費用対効果を検討することや、設定したRTOの達成に必要な手順を明確にした計画を策定しておくことが極めて重要です。
ちょっと情報が多かったですね。では、目標復旧時間の事例と解決策をいくつか見てみましょう。
目標復旧時間の事例
事業が中断される原因は、サーバー障害から自然災害にいたるまで、さらには従業員が重要なデータを誤って削除してしまったり、そうした重要なデータがランサムウェアにより暗号化されてしまったりなど、枚挙にいとまがありません。カテゴリーごとに適したRTOを達成するための選択肢も数多くあり、細かく調整されたアイテム復旧から、イミュータブルバックアップによるシステム全体の復旧まで選択可能です。運用しているシステムとデータの重要性を理解しておくことは、どのようなプロセスと復旧システムを整備しておく必要があるのかを把握するための第一歩です。また、重要なのは、そうしたシステムを復旧する最善の方法を知っておくことです。システム全体の復旧はデータベースログによるロールバックと同じ状態にサービスを復旧できる可能性が高いものの、ロールバックのほうが、より速やかに正常な稼働状態に戻せる可能性が高いため、RTO目標を達成できます。
組織は、システムとデータが事業全体に何を及ぼすか、その重要性について評価を行うことから始めます。RTOは時間を基準とした指標である点を常に念頭に置いておくことが大切です。会社の目標全般と戦略にとって絶対に不可欠なシステムやデータであっても、短いRTOを必要とするとは限らない場合もあります。例えば、従業員の研修を重視している病院で、学習管理ソフトウェア（LMS）がオフラインとなり、スタッフの研修記録データが喪失してしまうことがあるかもしれません。しかし時間的に見て、そのシステム停止がもたらす影響は、HIPAAの保護対象データに対するランサムウェア攻撃の被害の深刻さとは比べものになりません。LMSシステムのような一部のシステムでは、RTOは数週間、あるいは数か月に設定できる可能性があります。システムやデータによっては、1分単位や1時間単位のRTOが必要になる場合もあります。さらには、極めて重要であるために即時復旧が絶対条件となるシステムやデータもあります。例えば、同じ病院において、医療判断を瞬時に行うために必要な救命機器と電子医療記録（EMR）データが障害により機能停止した場合を考えてみてください。そのダウンタイムの影響は甚大で、文字通り命が危険にさらされる状況となるため、ほぼゼロのRTOが必須となります。
多くの企業は定期的なデータバックアップを頼りにしており、データは保護されているのだと安心しています。自動バックアップを組み込んでいる企業はさらなる安心感を持っています。しかし、サイバー犯罪者がますます巧妙になり、ランサムウェアが複雑化するにつれ、単純なバックアップソリューションでは、RTOを低い値かほぼゼロにする必要のあるデータに対してもはや効果的に対応できなくなっています。今日、サイバー攻撃の多くはバックアップ自体をターゲットとしており、場合によっては、時間をかけながらシステムを浸食することもあります。IT部門が攻撃を察知したころには、数週間分のデータバックアップがすでに破損していることも起こりうるのです。かつては、テープバックアップをオフサイトに保管するのが標準的な方法として通用していました。しかしながら、適時性が求められるようになった今では、極めて重要なビジネスニーズを抱えている企業にとって、テープを見つけ、運び、復元するまでとても待てないため、そのようなバックアップは非現実的となりました。
貴重なデータについては、イミュータブル方式を導入することでバックアップが確保されます。 ただし、バックアップデータを確保することに加え、それを即時復旧により復元する機能も必要です。Rubrikには、Live MountやInstant Recoveryといった機能があります。
Kern Medical CenterがRubrikを活用してどのようにランサムウェア攻撃を防御し復旧したかについては、こちらからご覧ください。その後は、RTOに関するより詳しい情報をお読みください。
RTOに関するFAQ
まとめ
結局のところ、組織にとって、危険に備えないという選択肢はほぼあり得ません。ランサムウェアは増加の一途をたどり、攻撃手法は日々複雑化しています。ランサムウェア攻撃（あるいは、システム停止を招くその他のインシデントや自然災害）をしのぎ切るには、会社を成功に導くための準備が不可欠です。データが漏洩すると、その被害は、実際の金銭的損失に加えて、評判の悪化や、果ては法的責任を伴う重大な問題にまで発展する可能性があります。適切な目標復旧時間と目標復旧時点を算定することが、データ漏洩危機を乗り越え、事業継続性を確保するための鍵となります。
忘れないでいただきたいのは、RTOとRPOはどちらも時間に関するものであり、相互に関連しているということです。 RTOは、ビジネスに重大な影響を及ぼすことなくシステムやアプリケーションをインシデント発生前の状態に復元するための最大時間です。RTOはどの企業、どの業界、どのシステムにとっても異なってきます。徹底したビジネスインパクト評価を行っておけば、RTOが企業にとってどれだけ重要かに基づいたうえでRTOのカテゴリーを決定できます。被害がハッカーによる場合、自然災害による場合、あるいは単純な人的ミスによる場合も含め、いかなる場合も、設定したRTOを達成するための適切なシステムを確実に整備しておくことで、データ喪失だけでなく、時間、費用、顧客ロイヤリティの喪失やブランド価値の毀損も軽減させることができます。