バックアップ手順書を捨てて「復旧手順書」を書こう
みなさまこんにちは。
私はいま、体がしんどくてしょうがない状態です。
これが夏バテってやつなんでしょうかね。これまでなったこともないのですが…。
まあ、話を進めましょう。
データ保護は「出口」から逆算するのが鉄則
前回の記事で「次は復旧手順書について書きます」とお約束しました。今回はこのことについて書いていきましょう。
企業のIT現場やバックアップの相談を受けていて、ずっと感じている違和感があります。
それは、みんな「どうやってバックアップを取るか（入口）」の話ばかりで「どうやって元に戻すか（出口）」の話を誰もしていないということです。
よろしいでしょうか。
「バックアップは戻せて初めて意味があります」
「バックアップはあるのに戻せない」という悲劇
警察庁が発表した最新データでも、ランサムウェア被害に遭った企業の約91%がバックアップを取っていたのに、復元できたのはたったの20%でした（警察白書 第3章第3項「ランサムウェアの情勢」より）
なぜこんなことが起きるのか？ 理由はシンプルです。
「バックアップを取ること」自体がゴールになってしまっているから。
いざ障害や攻撃が起きたとき「手順書がどこにあるかわからない」「専門用語だらけで夜間当番が動けない」「復元の順番を間違えてバックアップデータまで上書き・破損させた」といったパニックが現場を襲います。
手順書は「復旧」から逆算して書くのが鉄則
プロのバックアップ設計は、常に「最悪の事態からどうやって復旧するか」というゴール（逆算）から始まります。
手順書を書くときは、まず以下の3つを定義しなければなりません。
RTO（目標復旧時間）： 何時間（何日）以内に業務を再開させるか？
RPO（目標復旧時点）： どの時点までのデータを死守しなければならないか？（昨日の夜？ 1時間前？）
優先順位： どのシステム・データから順番に立ち上げるべきか？（全データを一括復旧しようとすると膨大な時間がかかり、事業がストップします）
手順書を書く作業こそが「最強のインフラ診断」になる
「復旧手順書」を真剣に作ろうとすると、必ず壁にぶち当たります。
「あれ？ サーバAを復元する前に、認証サーバBが動いていないとログインできないぞ？」
「クラウドのバックアップを書き戻すのに、回線速度的に3日かかるけど大丈夫か？」
「もしネットワーク全体がランサムウェアに感染して感染経路が閉じられていたら、クラウドのバックアップにすらアクセスできないのでは？」
そうです。「復旧の手順」を具体的に紙に書き出すことで初めて、自社のシステム構造の「致命的な罠」や「単一障害点（SPOF）」が炙り出されるのです。単一障害点というのは、簡単に言いますと「ここをやられたら全部終わり」という場所のことですね。
現場が迷わない「復旧手順書」に必ず入れるべき3つの項目
では、具体的にどのような「復旧手順書」を用意すればよいのでしょうか。どれほど緻密な計画であっても、いざという時に読まれなければ意味がありません。プロの視点から、最低限盛り込むべきは次の3点です。
1「最初に連絡すべき人物」と権限の切り分け
障害発生時、最も時間を食うのが「誰の許可を得てネットワークを遮断し、いつ復旧作業を開始するか」という意思決定の迷いです。現場担当者が迷わず一次対応（LANケーブルの抜去やWi-Fiの停止）を行える『緊急初期対応の権限』を明確に記載しておきます。
2「何を諦めるか」の割り切り基準
全データを一度に元に戻すのは物理的に不可能です。「まず顧客管理データベースを最優先で復元し、過去のログデータは業務時間外に後回しにする」といった、業務停止ダメージを最小限に抑えるための「切り捨てと優先順位のロードマップ」が必要です。
3「オフラインで読める」閲覧ルート
前述の通り、サーバや社内wikiに置いてある手順書は真っ先にアクセス不能になります。紙に印刷して金庫や防災バッグに入れておくか、完全にスタンドアロンな端末にPDFで保存しておき、定期的に更新日をチェックする運用をルール化してください。
たどり着く答えは「4-2-1ルール」と「紙の一枚」
復旧手順を極限まで詰めていくと、最後に必ず一つの結論に行き着きます。
「どれだけクラウドが便利でも、ネットワークが死んだら終わりだ。完全に隔離された物理バックアップ（エアギャップ）が1つ必要だ」ということです。
弊社では、一般的な「3-2-1ルール」をさらに一歩進め「4-2-1」という考え方を提案しています。「3-2-1ルール」にもうひとつクラウドを加え、そちらはバックアップ専用クラウドにするか、限られた人間が正式な手順を踏まないとアクセスできないようにするか、書き込みのみの一方通行にするか、そういった「最初からバックアップを目的としたクラウド」を利用するということです。
そしてもう一つ。「復旧手順書」自体も、ネットワークから切り離された「物理的な紙」または「オフライン端末」に印刷して保管しておくこと。 サーバの中に置かれた手順書は、暗号化されたら読めなくなります。
「手順書があること」と「復旧できること」は全く別物です
多くの企業が「BCPマニュアルや手順書はあるから大丈夫」と安心しがちですが、実際に復旧訓練まで行っている企業はごくわずかです。
年1回でも構いません。手順書をもとに「実際にネットワークを外し、オフラインのバックアップからデータを書き戻す」という疑似訓練を行ってみてください。
そのたった一度の訓練で浮かび上がった不備こそが、将来、倒産を含む様々なリスクを回避する最大の防御壁になります。
日頃から「復旧テスト」を行うことが、いざというときに「本当に復旧できること」につながります。
それでも復旧テストをやっている暇がない、というお客様のために弊社があります。お預かりしているオフサイトバックアップから、定期的にリストアテストを行い、その結果をレポートとして提出いたしております。
ぜひご利用をご検討ください。
結論
バックアップは「保険」ではなく「避難訓練」です。
今日から、「バックアップを取る手順書」を作るのはやめましょう。
「今夜、全データが暗号化されたら、明日の朝だれが・どうやって・何分で元に戻すか」という復旧手順書を1枚書くことから始めてみてください。
「バックアップを取っています」
ではなく、
「明日の朝、会社を動かせます」
と言えるようにしておく。
それが本当の意味での「備え」なのだと思います。
弊社では、こうした復旧手順の整理やリカバリテストのお手伝いもしております。「うちの場合、どうなるんだろう？」という程度でも構いません。お気軽にご相談ください。
あとは毎度のお知らせですが
フォームのご紹介です。
5分でわかる DR/BCP体制 危険度チェック
バックアップの取得状況や復旧体制などについてご回答いただくことで、
現在のDR/BCP体制を簡単にセルフチェックできます。
「バックアップは取っているけれど、本当に十分なのだろうか。」
そう感じられた方は、ぜひ一度お試しください。
また、より詳しいご相談をご希望の方には、お困りごと相談フォームもご用意しております。
こちらは基本無料、人間による回答となります。
バックアップ運用、リカバリテスト、データ復旧、DR/BCP体制の構築など、お気軽にご相談ください。
このnoteの質問箱からのお問い合わせも歓迎いたします。
LinkedInなんかもぼちぼちやっております。
https://www.linkedin.com/in/tadaomurashima/
時々ご覧いただければ幸いです。
以前より、配信をやってみようというお話をしましたが、現状今日の20:00ごろから30分程度を予定しております（曖昧な予定ですが、こういうのはこれでいいんです）。
17LIIVEというところで、名前は「ゆひろ_0606」です。
もしよろしければご覧下さい。
目次を貼っておきますので、他の記事もご覧になってください。
では今日はこの辺で。
