バックアップと復旧 — 取れていることと、戻せることは別
毎日バックアップを取っていた。3年間、一度も失敗していなかった。いざ戻そうとしたら、復旧に11時間かかると分かった。
この記事の進み方
What — バックアップは「取る」「置く」「戻す」の3つ
バックアップという言葉は、性質の違う3つをまとめて指しています。
- 1取る
- 2置く
- 3戻す
監視が見ているのはたいてい1段目だけ。2段目と3段目は、実際にやってみるまで分からない。
- RPO
- Recovery Point Objective。どこまで戻るか＝失ってよいデータの量。1日1回なら最大24時間ぶん失う。
- RTO
- Recovery Time Objective。どれだけで戻すか＝止まってよい時間。復旧の所要時間がこれを超えると約束を守れない。
- フルバックアップ
- 全体の写し。戻すのは単純だが、量と時間がかかる。
- 差分・増分
- 前回からの変化だけを取る方式。取るのは速いが、戻すときにフルと組み合わせる必要がある。
- PITR
- Point-in-Time Recovery。任意の時点に戻す仕組み。トランザクションログを継続的に保存して実現する。
RPO と RTO は、別々の約束
この2つを混ぜると議論が噛み合いません。
- RPO は「いつの状態に戻るか」 — 1日1回のバックアップなら、最悪 24 時間ぶんのデータが消えます
- RTO は「いつまでに戻るか」 — 復元に 8 時間かかるなら、その間サービスは止まります
冒頭の事故は、RPO が 18 時間、RTO が 11 時間でした。どちらも誰も知りませんでした。決めていなかったのではなく、測っていなかったので分かりようがなかった。
「取れている」は3つのうち1つしか言っていない
バックアップの監視が見ているのは、ほぼ常に1段目です。
「ジョブが成功した」「ファイルが作られた」「サイズが0ではない」。これらは全部、取れたことしか言っていません。
中身が壊れていないか、戻せるか、どれだけかかるか。これらは戻してみるまで分かりません。
Why — 戻す作業は、平常時と条件が違う
復旧が計画通りに進まないのは、戻すときの状況が平常時と違うからです。
焦っている人が、初めての手順を実行する
バックアップを戻すのは、何かが壊れた直後です。人は焦っていて、判断力が落ちています。
そこで初めて触る手順を実行することになります。読むのも初めて、打つコマンドも初めて。取り返しのつかない操作を含むこともあります。
一度でも練習していれば、この差は大きく縮みます。
依存しているものが、同時に落ちていることがある
バックアップを同じクラウドの同じリージョンに置いていれば、そのリージョンが落ちたときバックアップも取り出せません。
権限の設定を管理していた仕組みが落ちていれば、復元する権限が使えないこともあります。手順書を社内 Wiki に置いていて、その Wiki が同じ基盤に載っていれば、手順書が読めません。
消したのが「一部」のとき、全体を戻すと別の損害が出る
冒頭の事故がこれです。
1テーブルだけ消えたのに、全体を戻すと他のテーブルも 18 時間巻き戻ります。注文は受け付けている。決済も走っている。それらを巻き戻すほうが、消えたテーブルより大きな損害になることがあります。
「戻す」は常に正解ではありません。 部分的に戻す手段を持っていないと、この判断ができません。
演習 — まず自分で判断する
毎日 03:00 にフルバックアップを取っています。21:00 に障害が起きて復旧する場合、失われるデータは最大でどれくらいですか?
バックアップの監視として、最も価値が低いものはどれですか?
読み終わりましたか?
読了にすると、これを前提とする記事がロードマップで開放されます。