基礎知識
バックアップでよく聞く「RPO/RTO」とは？
2021年2月25日
デジタルデータは、保存している機器の故障、地震や火災などの災害、人的なミスなどの原因によって、喪失してしまう危険と常に隣合わせです。そのため、あらかじめデータのコピーを別の場所に保存しておく、いわゆる「データのバックアップ」が欠かせません。
しかし、どれだけデータ喪失の危険性が叫ばれても、バックアップの重要性が理解されないケースは依然として存在します。また、バックアップの重要性は理解できていても、具体的なバックアップ方法がわからず、適切なバックアップが行えていないケースも多いのではないでしょうか。
本記事では、バックアップを正しく行うための基礎的な知識を解説します。
まずはバックアップの重要性を理解しよう
デジタルデータは、ほんの小さなミスや障害によって、一瞬にして喪失してしまう可能性があります。重要なファイルをうっかり消してしまったり、あるいは間違ったデータで上書き保存してしまったというオペレーションミスは、どなたでも経験があるのではないでしょうか。また、データを保存しているストレージやファイルサーバーといったハードウエアの障害によって、データを読み込めなくなってしまうことも決して珍しいものではありません。さらに、最近では障害以外にもデータを暗号化して人質に取る「ランサムウエア」による被害も増えています。このような万が一のデータ喪失に備えて、あらかじめデータのコピーを保存しておくことを「バックアップ」と呼びます。
喪失してしまったのが個人の作業データなど、時間をかければ取り戻せるデータであれば、バックアップがなくても（損失は発生するものの）致命的な事態とはならないでしょう。しかし、企業が保持しているデータの中には、一度喪失したら二度と戻ってこないデータも多く存在します。もしも、運用中のサービスのデータベースを喪失してしまい復旧が不可能となると、場合によっては企業の存続にも関わる事態を招く可能性も否定できません。
どれだけ注意深くシステムを運用したとしても、発生する障害を100%回避することは不可能です。そのため、万が一の事態を想定したバックアップを作成し、データ喪失への備えを怠らないことが、結果としてサービスや企業を守ることに繋がります。
バックアップの指標となるRPO/RTO
バックアップの戦略を立てる前に、まずはそのバックアップに求められる要件を明確にする必要があります。なぜならば、「どのデータを」「どのような手段で」「どのくらいの頻度で」「どのくらいの期間」保存する必要があるのか、という点があやふやな状態では、具体的なバックアップ手法を決定できないためです。
バックアップの手法はさまざまで、手法ごとにバックアップにかかるコストや、復旧までにかかる時間が異なってきます。データを保全するという点から言えば、すべてのデータを高頻度で、無限に保存するのが理想的です。しかしそれでは、手間もかかるコストも大きくなってしまいます。安全とかかるコストはトレードオフの関係にありますから、対象となるデータの重要度、更新頻度、サイズ、保存期間などを考えた上で、完璧を求めるのではなく、どこで折り合いをつけるかを判断することが大切です。
そして、こうした判断を定量的に行うための指標となるのが、RPOとRTOです。
RPO（Recovery Point Objective）とは
障害が発生した際に、システムを過去のどの時点まで復元するかを定めた目標値を「RPO（Recovery Point Objective）」と呼び、日・時・分・秒といった単位で表します。
RPOを小さく（短く）すればするほど、障害時に喪失するデータを少なくすることができます。仮にRPOを1秒としたら、障害発生の1秒前までのデータを復旧できることを意味します。しかし、これは言いかえると、秒単位の頻度でバックアップを取得し続ける必要があるということでもあります。これだけの高頻度でバックアップを取得すれば、当然バックアップにかかるコストは大きくなってしまうでしょう。対して、RPOを1日とするとバックアップの頻度は1日1回で良いことになります。この場合は、バックアップにかかるコストは小さくなりますが、障害発生時から最大で過去24時間分のデータを喪失する可能性があります。
1日に1回しか更新されないデータとリアルタイムに更新され続けるデータでは、求められるRPOは異なってきます。RPOは、データの更新頻度とバックアップにかかるコストの双方を考慮して決定する必要があるでしょう。
RTO（Recovery Time Objective）とは
システムの復旧までにかかる時間の目標値をRTO（Recovery Time Objective）と呼び、RPOと同様に日・時・分・秒といった単位で表します。
RTOを小さく（短く）すればするほど、システムを短時間で復旧できることを意味します。しかし、RTOを小さくするためには、単純にデータのバックアップを取得しておくだけではなく、システム全体を冗長化して待機させておくなど、ダウンタイムを短くするための別の工夫も必要となります。
RPOとRTOをどこまで小さくするべきかは、対象システムの経過時間によるビジネスインパクトを考慮して、慎重に決定する必要があります。また、これらの数値は企業のBCP（Business Continuity Plan、事業継続計画）とも密接に関わってきます。どちらも小さいに越したことはありませんが、コストを度外視して最小値を目指すのではなく、ビジネスの規模に合わせた最適な値を探る必要があるでしょう。
