Recovery Point Objective は目標復旧地点である。あくまで目標値 (Objective) である。
例えば、とあるソシャゲが3日に1回バックアップをとっているとしよう。もしもこのゲームがトラブルで停止し、データがすべて吹き飛び復旧不能になったとする。その場合、バックアップからの復旧となる。最悪の場合、3日分の巻き戻しが発生する。この場合、 RPO は3日となる。
この3日間に☆5やら SSR やらをガチャで引いていたとしてもそれらは消し飛ぶ。残念なことだが。RPO は短ければ短いほど良い。
Recovery Time Objective は目標復旧時間である。あくまで目標値 (Objective) である。サービスがトラブルで停止した場合に回復するまでにかかる時間の目標値 (Objective) だ。
SLA (Service Level Agreement) はサービスの品質に関する約束 (Agreement) だ。約束だから破ったらペナルティがある。ペナルティを含めての約束である。
Amazon EC2 サービスレベルアグリーメント に AWS の SLA に関して記述がある。超単純化して書くと、この記事を書いている時点では「月間の 0.05% 停止時間があったら1割お金を返す。1% 以上の停止時間があったら3割を返す」ということをうたっている。
RTO は SLA のペナルティを回避できるような数字である必要がある。AWS であれば月間1296秒 (月30日として0.05%。大体21分半) 止まったら返金が発生してしまう。最低でも RTO はこれよりも短くしないといけない。
Recovery Time Capability。最近知った概念である。実際に回復にかかる時間であり、RTO とは対照的な概念ともいえるだろうか。
RTO が SLA やその他の要請から定められるのに対し、RTC はリアルにかかる時間である。計測したりするのは難しいが、想定はしておかなければならない。さらに言えば RTC は RTO 以内の時間であるべきである。
とはいえ、実際のところビジネス上の要求は実際に可能なそれよりも厳しいことがほとんどだろうから、RTC の方が大きいケースの方が多いのだろうが……
Closing the Delta Between RTO and RTC - Disaster Recovery Journal
ただいまコメントを受けつけておりません。