「バックアップが無駄だった……」とならないための“鉄則”はこれだ：バックアップとデータ復旧の手引き【中編】
バックアップは、必要になるときに正しく復旧できてこそ意味がある。バックアップとリカバリーを正しく実践するために、常日頃から意識しておくべき基本とは。
バックアップとリカバリー（復旧）のシステムや手順を整えるだけでは、十分ではない。バックアップとリカバリーは、いざというときにデータやシステムを正しく戻せてこそ意味がある。ランサムウェア（身代金要求型マルウェア）被害のような非常事態においては、必ずしもスムーズに対処できるとは限らない。そうした場合に備えて、本稿で紹介するバックアップとリカバリーの「基本」を常日頃から忘れないようにしておくことが欠かせない。
「バックアップを無駄にしない」ための鉄則とは
併せて読みたいお薦め記事
連載：バックアップとデータ復旧の手引き
バックアップ運用のポイント
3-2-1バックアップルール
「3-2-1バックアップルール」は、データが適切に保護されていることを確認するための基本的なルールだ。3-2-1の意味はそれぞれ以下の通り。
- 3：合わせて3つのデータ（本番データ以外に、バックアップとして2つのコピー）を持つ
- 2：データの保管に2種類以上のストレージを使う
- 1：コピーのうち1つをオフサイト（本番拠点とは異なる拠点）で保管する
3-2-1バックアップルールを順守することは、クラウドストレージが普及する中ではより容易になったが、クラウドストレージがなければ「1」のオフサイトでの保管は簡単な対策ではない。オフサイトでの保管は、ランサムウェア（身代金要求型マルウェア）に対する保護策として欠かせない。
バックアップの監査
バックアップ監査は、バックアップとリカバリーが意図した通りに機能することを確認するための正式なプロセスだ。監査の内容には、
- データの保存場所
- そのデータを使うアプリケーション
- データの保護方法
- バックアップのポリシーと手順
- リカバリーの手順
- リカバリーの担当者
- RTO（目標復旧時間）とRPO（目標復旧時点）への準拠
などを含める必要がある。クラウドストレージに保存するデータも対象になる。
リカバリーのテスト
システムの中には、事業継続に欠かせない“ミッションクリティカル”なシステムもあれば、使えなくても事業に致命的な影響はないシステムもある。そのシステム自体は重要ではなくても、他のシステムとの依存関係から迅速に復旧しなければならないものもある。リカバリーのテストを実施する際は、そうしたシステムごとの重要度に応じてシステムを正しい順序でオンラインに戻せるかどうかを確認しよう。
テストを実施する際は、計画通りにフェールオーバー（予備システムへの切り替え）ができることを確認する必要もある。これには、クラウドサービスのDR機能も含まれる。
データを復旧するために必要なサポート体制が整っているかどうかも重要だ。そのサポート体制には、
- 電力設備
- 冷却設備
- 通信機能
- スタッフ
が含まれる。バックアップソフトウェアが意図した通りに機能したかどうかを単にチェックするだけでは不十分だ。
リカバリーをどのように実施するかは、バックアップを保存しているストレージへのアクセス方法に依存する。例えば以下のような具合だ。
- クラウドストレージを使っているのであれば、リカバリーを進めるのに十分なだけのネットワークの帯域幅（回線路容量）が必要になる。
- 本番システムが稼働する拠点のストレージであれば、バックアップシステムが正常に稼働している必要がある。
- 遠隔拠点にあるストレージであれば、ストレージを対象の拠点に持ち込むか、予備システムやクラウドストレージにデータを転送する必要がある。
次回は、確実にリカバリーを成功させるために、どのようにテストを実施すべきなのかを解説する。
Computer Weekly発 世界に学ぶIT導入・活用術
米国TechTargetが運営する英国Computer Weeklyの豊富な記事の中から、海外企業のIT製品導入事例や業種別のIT活用トレンドを厳選してお届けします。
Copyright © ITmedia, Inc. All Rights Reserved.