これだけは覚えて!
「RPO」と「RTO」
バックアップの必要性はわかってくれたかね。
ではもう少し深く考えよう。
深く…… ですか?
うむ。バックアップは有事の際、
データを取り戻すために行っているものなんじゃ。
つまりデータが戻らなければ意味がない。
そこで 「どの時点まで戻したいのか?
今すぐに戻さなければいけないのか?」

考えなければいけないんじゃ。
はぁ……
つまりRPOとRTOの考え方じゃ。
RPO とは
RPO(Recovery Point Objective)とは、障害発生時、過去の「どの時点まで」のデータを復旧させるかの目標値である。例えば更新頻度の少ないシステムでは、障害発生の24時間前までのデータ(RPO=1日)で復旧できれば支障ないこともある。逆に24時間365日連続的にサービスを提供する通販サイトでは、復旧時に停止直前までのデータ(RPO=0秒)が求められる。
「昨夜の状態」に復旧できればいいRPOの場合には「最長1日」、1時間前に復旧が必要であればRPOは「最長1時間」となる。もちろん、RPOが短くなればなるほど頻繁にバックアップする必要があるからコストは高くなる。
RTO(Recovery Time Objective)とは、障害発生時「どのくらいの時間で(いつまでに)」 復旧させるかを定めた目標値である。言い換えると、RTOは「システム停止やサービス中断が許される時間」とも言える。
例えば、通販サイトで障害が起きたとしよう。
平均で1時間に100万円の利益を出す通販サイトの場合には、復旧までの時間が長ければ長いほど損失は大きくなる。こんな場合には冗長化といって同じサイトを2つ用意し、「障害が起きた際にもう1つのサーバーで動かす」ということも考えなければいけない。
そうじゃ、冗長化の話もしておこう。
それと同時に考えなければいけないのがRTOじゃ。
RTO とは
冗長化 とは
このように、RTOは 「いつまでに復旧するのか」 の目標値を
考えて設定するんじゃ。
これもやはり、RTOが短いほど、そのコストは高くなる。
つまりRTOもRPOも利益損失を最小限にとどめるためには、
契約(SLA:Service Level Agreementなど)で定められた
ペナルティや提供しているサービスの状況を考えて
定めておくことが必要じゃな。
RPOやRTOのことはなんとなくわかりました。
簡単に言うと「データをどこの時点まで戻すか?
どのぐらいの時間をかけて戻すか?」

を考えればいいんですよね。
そうじゃ! よくできたな。
でもそれはどうやって実現するのですか?
お客様の要件で5分前に戻したい!
とか決められるものですか?
では次にどうやってその要件を実現するか?
「バックアップの方法」を見ていこう!

pagetop