ディザスタリカバリ手順をあらかじめ決めておくべき理由
これまで、遠隔地のバックアップとクラウド利用についてお話ししてきました。
ディザスタリカバリという言葉について少し詳しめにお話ししようと思います。
おわかりいただけると思うのですが、ディズアスター・リカバリーという言い方も致します。この辺は表記の揺れということでご理解下さい。
ディザスタリカバリとは何か
まずはディザスタリカバリは何かという話になるかと思いますが、語彙自体は難しくはないと思います。災害によってシステム障害が発生した際に元に戻すということですね。
このこと自体は結構長いこと言われていることであって、対応済と仰っている会社様等は珍しくはないと思うんです。ただ、どんなディザスタ＝災害を想定するかという点において、日本人というのは災害列島に住んでいる割にはあまりにも楽観的すぎたのではないかと。
東日本大震災という日本人の意識をいろんな意味で変えた大災害がありましたが、私が考える「情報セキュリティの面から考える災害」が喫緊の課題として認識されたのはこの災害だったと思います。
その前後にも同レベルの災害はいくつも起こっていますよね。阪神淡路大震災、新潟県中越地震、そして元日の受かれ気分に冷や水を浴びせた令和6年能登半島地震…。
ディザスタリカバリの射程としてとらえられていたものは、東日本大震災が起こる前まではせいぜい火災ぐらいだったと思います。なぜ阪神淡路大震災や新潟県中越地震では情報セキュリティという角度からの検討がなかったのか。これはやはり、東日本大震災がデジタルデータの重要性や使用頻度が格段に上がってきたところに起きた災害だからであろうと考えています。
災害というのを台風とかそういうことまで広げることになりますとさらにたくさんの災害が日本列島を襲い、そしてそのたびに復旧してきました。
東日本大震災においてとりわけ多く見られたのが大津波によってIT機器ごとごっそりと海に流されてしまった例が多発したということだと思います。こんな災害があったのでここには住んでいられない、遠方に引っ越したいという考えを持たれた方はたくさんいらっしゃると思うんですが、そういう方々に転出届を交付することすらできなかったわけです。これでは、さすがに問題意識を持たざるを得ないでしょう。
こういうわけで、ディザスタリカバリに改めて注目が集まるのも当然と言うべきですね。
ディザスタリカバリの射程
さて、ではどの程度の災害を計画に織り込んでおくべきでしょうか。それを決めるのがディザスタリカバリにおける「リスク評価」という手順になります。
弊社では、ドライブ1台レベルから対応しておくことをお勧め致しております。現在ドライブはSSDが主流になりつつありますが、記憶容量当たりの単価が安いということでまだまだHDDも使われているのが現状だと思います。そしてHDDというのはいきなり寿命を迎えるものです。ですので、まあ災害と言っては大げさな感じも致しますが、ドライブ1台ダメになった、というのが最小のディザスタだと考えています。
さらにPC1台、あるいはNASが電力サージや停電によってダメになった場合、オフィス1カ所が火災や豪雨によってダメになった場合、複数拠点が地震などによってダメになった場合…と大規模なダメージが考えられます。そういった災害を、あらかじめ予測して、できればその被害を金額で評価しておくといざ災害の時に復旧がスムースに進むのではないかと思います。
話がやや前後しますが、ディザスタリカバリの基本要素は以下のようになります。
バックアップ
RPO（目標復旧地点）
RTO（目標復旧時間）
やはり、まずバックアップありきなのです。正直、面倒くさい作業ではありますが、いざというときに慌てなくてすむという意味では行っておく価値がある作業だと言えるでしょう。
バックアップソフトというものも今はいろいろ市販されておりますが、その中にはNASから1台の端末に至るまでまるごと一気にバックアップするといういかにもオフィス向けな仕様を持ったものがあります。しかし、これはできれば避けた方がよいのではないかと弊社では考えております。
と申しますのも、リカバリすべき対象がHDDやSSD1台といった小規模にとどまる場合、全部をまとめてバックアップという形ですとデータを1回展開しないと必要なデータを取り出せないということになるためです。RTOが長くなることになります。
バックアップの理想は、1デバイスに対して1デバイスだと考えております。そうしておけば、極論を言えば作成したバックアップを物理的に災害の被害に遭ったデバイスとリプレースしてしまえば極めて簡単にリカバリできるためです（ただ、この点に対してはMicrosoftの方針によりWindows11においてちょっと難しい問題も出てきておりますがその件に関しては稿を改めていずれお話しすることに致します）。
NASに関しましてはデバイス間で1対1対応というのは場合によっては難しいかも知れません。NASは多くの場合RAID機能を備えておりますので、RAID1を設定しておき、定期的にRAIDの一方をバックアップ扱いにして保管しておき新しいものとリプレースするという方法もありかも知れません。NASはLinuxで動いているケースも多いですが、Linuxであればマシン環境のすべてをイメージで書き出すコマンドが標準で存在することも多いのでNASに限ってはこれを利用するというのもひとつの有効な手段ではあると思います。RAID5やRAID6であった場合はそれに対応した方法が必要になります。NASというのはOSもハードウェアも様々な仕様がありますので、これはケース・バイ・ケースで計画を立てておくことになるかと思います。Linuxに関しましてはバックアップするべきデータを使っているPCのOS問題と絡めて、いずれそれだけのために稿をひとつ設けようと思っております。
RPOに関してですが、この点にぜひ弊社のサービスをお使いいただきたいと強く申し上げたいところです。弊社のバックアップをご利用いただいておりますと「とりあえずここまで戻せば正常に動作しているしデータの整合性も間違いなく取れている」という状態のデバイスをお返しすることができます。同時にクラウドストレージなどで常に最新の状態が保存されているのであれば、弊社のバックアップに加えてクラウドから差分をリストアすることで最新の状態を比較的短時間で再構築することができるでしょう。RTOを短く設定することが可能です。差分と増分という言葉はバックアップ関係の話をするにあたり避けて通れないものですが、これは正直1稿設けるほどの話でもないので、またいずれ関係した話の時についでにお話し致します。
このように、バックアップとリストアと簡単にまとめましてもパターンはそれぞれ違ってきます。基本は1のバックアップをどこからどこまで行うのかの決定を漏れがないように行っておき、3のRTOがなるべく短くなるように、2のRPOへの戻り方を明確かつわかりやすく行っておくということになります。
これが、ディザスタリカバリ手順を決めておくべき理由、手順の存在意義です。
小括
このようにバックアップに関してはどんな環境にも絶対に対応できるひとつの方法というのがありませんので、環境すべてをバックアップするという定期的な対策を行った上で細かいところを適宜アジャストしていくということになります。
事業継続計画（BCP）という言葉がありますが、バックアップとリストアもその重要な要素です。
ぜひ、弊社にお手伝いをさせていただければと思います。
よろしくご検討ください。
目次
この記事が気に入ったらサポートをしてみませんか？