小規模なチームにおける災害復旧は、たいていの場合、誰も開いたことのないドキュメントの中の一行で終わっています。バックアップは有効になっています、という一文です。その記述自体は事実ですが、何かの答えになっているわけではありません。実際に障害が起きたときに戻ってくるデータがどれだけ古いものなのか、復元にどれくらいの時間がかかるのか、そしてこれまでに誰か一人でも最後まで復元をやり切ったことがあるのか、そのどれについても何ひとつ語っていないからです。

バックアップを持っているという状態と、実際に復旧できるという状態のあいだには、はっきりとした隔たりがあります。ほとんどの障害が本格的なインシデントへ変わるのは、まさにその隔たりの中でのことです。存在していて、内容も十分に新しく、しかし一度も復元されたことのないバックアップは、まだ仮説にすぎません。そしてその仮説を初めて検証する瞬間というのは、仮説が間違っていたと知るには最悪の瞬間です。

二つの数字が、意見を計画に変えます。 どれだけのデータを失っても事業として耐えられるのか、そしてどれだけの時間止まっていても耐えられるのか。それがあなたの目標復旧時点と目標復旧時間です。事業側の誰かがこの二つを言葉にするまで、バックアップの取得頻度をめぐる技術的な議論はいつまでも決着しません。何を基準に是非を判断すればよいのか、その基準そのものが存在しないからです。

RPOとRTOをかみ砕いて説明する

目標復旧時点、すなわちRPOは、失ってよいデータの量を表します。夜間バックアップだけを取っている運用は、RPOが24時間だということです。夕方の17時に障害が起きれば、前の晩のバックアップ以降に積み上がったものはすべて消えます。それが受け入れられないのであれば、間違っているのはバックアップのスケジュールそのものであり、ほかの場所でどれだけ丁寧に作り込んでも、この損失を埋め合わせることはできません。

目標復旧時間、すなわちRTOは、止まっていてよい時間を表します。ここにはすべての工程が含まれます。障害に気づくこと、復旧を始めると決めること、必要な資源を用意すること、実際に復元すること、正しく戻ったことを検証すること、そしてトラフィックを元に戻すことまで、全部です。多くのチームは復元の工程だけを見積もり、残りの五つを忘れてしまいます。現実の復旧が想定の何倍もの時間を要してしまうのは、まさにこれが理由です。

どちらも技術的な判断ではなく事業上の判断であり、どちらも基準を厳しくするほど費用がかかります。RPOを5分に設定するのであれば、継続的なレプリケーションが必要になります。RTOを1時間に設定するのであれば、自動で作り直せるインフラが必要になります。強い圧力のかかった状況で、一時間以内に手作業でサーバーを設定し切れる人など、現実にはいないからです。

生産的な会話とは、結局のところ取引の会話です。それぞれの水準を実現するのにいくらかかるのかを事業側に伝え、事業側に選んでもらってください。技術側だけで勝手に数字を決めておいて、その数字が一度も口に出されたことのない期待値と偶然一致することを祈る、という進め方よりも、はるかに健全な決め方になります。

テストしていないバックアップはバックアップではない

本当に痛い失敗が、バックアップの不在から生じることはめったにありません。多くの場合に痛いのは、いざ必要になった瞬間に使えないと判明したバックアップのほうです。

よくある原因は次のとおりで、どれも実際に復元してみるまで表に出てきません。失敗と同じ熱心さで成功を監視する人がいないために、ジョブが何週間も静かに落ち続けている。ダンプはスキーマを取得したものの、中身のデータは取得していない、あるいは誰かが以前に除外リストへ入れたせいで一部のテーブルしか入っていない。ファイルは暗号化されているのに、その鍵が、よりによって壊れた当のマシンの上に置かれていた。バックアップが、それが守るはずの対象とまったく同じアカウント、同じリージョンに置かれている。

最後の項目は、以前よりもはるかに重い意味を持つようになりました。本番と同じ環境に置かれたバックアップが守ってくれるのはハードウェア故障だけであり、それ以外の何からも守ってくれません。アカウントの乗っ取りにも耐えられず、アカウント単位でのうっかりした削除にも耐えられず、同じ資格情報で到達できるものすべてに到達してしまうランサムウェアにも耐えられません。

バックアップが機能すると知る唯一の方法は、実際に復元してみることです。予定表に組み込み、少なくとも四半期に一度は実施し、そのたびに所要時間を計測してください。そうして測った時間こそが、ドキュメントに書かれている数字ではなく、あなたの本当のRTOです。

災害復旧が対象にすべき範囲

データは誰もが真っ先に思い浮かべる部分であり、そして復旧を遅らせる原因になることは、むしろ稀です。復旧を長引かせるのは、ほとんどの場合、誰も一覧に書き出さなかったもののほうです。

データベース、これは全員が覚えています。アップロードされたファイルは別の場所に置かれていることが多く、そもそもバックアップが一切存在しない場合も珍しくありません。設定とシークレットは、稼働中のマシンの上にしか存在していないことがよくあります。DNSと証明書は、それらを保持しているアカウント自体が失われた対象であった場合、短時間で作り直すことができません。インフラそのもの、つまりサーバーやネットワークや各種のルールは、コードとして定義されていれば素早く再構築できますが、管理画面をクリックして作られたものであれば、苦痛なほど時間がかかります。

そして、それら全体がどう噛み合っているのかという知識は、小規模チームにおいて復旧時間を左右する最大の単一要因です。一人の人間が記憶だけで組み直せるシステムは、復旧時間がその人の在席状況とまったく同じになってしまいます。それは計画とは呼べません。

計画を書くより先に、棚卸しの一覧を書いてください。多くのチームは、その一覧を作っている最中に、バックアップがまったく存在しない構成要素を少なくとも一つ見つけます。そしてその見つけ方は、もう一方の見つけ方に比べて、比較にならないほど安上がりです。

一枚に収まる計画

インシデントのさなかに長い文書が読まれることはありません。疲れ切った人間が深夜の三時に、いちいち考え込まずにそのまま辿れる程度のものを目指してください。

必要なのは次の要素です。まず、復旧を開始したと誰が宣言するのか。目の前の事象を災害と呼んでよいのかどうかで迷っている時間は、遅れの原因として非常に多いからです。次に、バックアップがどこにあり、どうやって到達するのか。ここには、落ちた当のシステムに依存しない資格情報が含まれていなければなりません。復元の手順は順番どおりに、その場の判断を挟まずに追えるだけの具体性で書くこと。うまくいったことをどう検証するのかも必要で、これはサイトが開いたように見えるという感触ではなく、具体的な確認項目でなければなりません。そして社内と社外のそれぞれで、誰に知らせるのか。

計画は、障害を生き延びる場所に保管してください。復旧の対象であるシステムの中だけに置かれた復旧計画は、繰り返し現れる、そして完全に避けられる種類の失敗です。

同じ理屈はアクセス権にも当てはまります。ホスティングアカウントの資格情報を一人しか持っていないのであれば、あなたの復旧時間はその人が電話に出るかどうかで決まってしまいます。当社のLinuxサーバーハードニングガイド では、これらすべての前提となるアクセス制御を扱っています。

完璧ではなく、釣り合いを

小規模なチームに、第二リージョンのホットスタンバイは必要ありません。費用は確実に発生しますし、増えた複雑さはそれ自体が新しい障害の種を持ち込みます。

ほとんどの小規模チームが本当に必要としているものは、はるかに安く済みます。本番からは使えない資格情報でアクセスする別アカウント上のバックアップ、決めた周期どおりに試験され所要時間まで計測された復元、考古学のような調査をしなくても作り直せるようコードとして定義されたインフラ、そして実際に誰かが目を通した一枚の計画です。必要なのは、この四つだけです。

この組み合わせで、ハードウェア故障、うっかりした削除、アカウントの乗っ取り、そしてランサムウェアが覆われます。現実に起きることの大半は、この四つに収まります。それを超える部分は、停止時間をさらに短くすることにいくら払う価値があるのかという判断であり、それは技術ではなく事業側が答えるべき問いです。

Mecanikはサーバーセキュリティ分析 の一環として、ここに書いた内容を点検し、実際に構築します。最初の質問はいつも同じで、技術の話ではありません。どれだけの時間止まっていられるのか、そしてそれを決めたのは誰なのか、という質問です。

関連記事: 意味のある稼働率SLAの作り方 、小規模チームのソフトウェアサプライチェーンセキュリティ 、業務向けAIエージェントの費用と失敗要因 、英国のフィンテック開発：FCA、決済基盤、費用 。

よくある質問

RPOとRTOは何を意味しますか。 目標復旧時点は失っても許容できるデータ量のことで、夜間バックアップだけであればRPOは24時間になります。目標復旧時間は止まっていても許容できる時間のことで、障害に気づくこと、判断すること、資源を用意すること、復元すること、検証すること、トラフィックを戻すことまでを含みます。どちらも事業上の判断であり、どちらも基準を厳しくするほど費用が増えます。

なぜテストしていないバックアップはバックアップではないのですか。 故障の形が復元のときにしか表に出ないからです。失敗と同じだけ成功を監視する人がいなければジョブは何週間も静かに落ち続け、ダンプはデータのないスキーマだけを取得したり除外されたテーブルを落としたりし、暗号鍵は壊れたマシンの上に残り、コピーは守るべき対象と同じアカウントに置かれます。四半期ごとに復元し、所要時間を計測してください。

バックアップはどこに置くべきですか。 本番が使えない資格情報とともに、別のアカウントか別のリージョンに置いてください。同じ環境にあるバックアップが守るのはハードウェア故障だけで、それ以外は何も守りません。アカウントの乗っ取りにも、アカウント単位の削除にも、同じ資格情報で到達できるものすべてに届くランサムウェアにも耐えられません。

災害復旧で見落とされがちなものは何ですか。 データベースとは別に保管されたアップロード済みファイル、稼働中のマシンにしか存在しない設定とシークレット、それ自体が失われうるアカウントに置かれたDNSと証明書、コードとして定義されず管理画面のクリックで作られたインフラ、そして全体の噛み合い方に関する知識を一人しか持っていないという状態です。

小規模チームにホットスタンバイは必要ですか。 たいていは不要です。費用は現実に発生し、増えた複雑さはそれ自体の障害要因を持ち込みます。別アカウント上のバックアップ、試験され計測された復元、コードとして定義されたインフラ、そして誰かが目を通した一枚の計画があれば、ハードウェア故障、うっかりした削除、アカウントの乗っ取り、ランサムウェアという、実際に起きることの大半は覆えます。