Ｗｅｂにおける事業継続計画（BCP）について

今回はＷｅｂにおける事業継続計画（BCP）について、弊社の見解（かなり個人的見解）を語ります。

重要なのがバックアップとリストア。
これが迅速にでき、かつ数か所にあるデータの同期がリアルタイムに近づけることが理想です。

しかし、設置してある場所が物理的に遠くなればなるほど、データを送るにしても遅延が発生します。
そのためには回線を太くするしかありません。
もしくは同時に別の場所にあるデータを書くという手もあります。

どちらにしても、優先順位を決めなければいけなくなります。
実行する優先順位もそうですが、コストと時間の関係が一番重要です。



①コスト
これが一番重要です。
ダウンした場合の損失を想定し、その損失を防ぐためのコストを算出します。
おのずとかけられる費用が決まってきます。
損害額の１％まででしょうか？運用費用は。

②ダウンタイム
リストアもしくは復旧までの時間（ダウンタイム）はどれぐらいを想定するか？
同じ場所にあれば、時間も短縮できるが、被害にあった場合、全部駄目になる可能性がありますので、必ず、別の場所にコピーする方法を考えましょう。

SOHOにお勧めなのは、バックアップを受け持つ集中サーバーを立てることです。
NASでもいいじゃんという意見があると思いますが、NASはすべてアクセス元のサーバーからしかデータを制御できません。
データを持ったサーバーが自発的に他の場所に移せるような設定が必要なのです。
なので、NASでいいという人はそのデータを物理的に持っていかれたりしないようにしたり、何かあった場合はいの一番で持っていくようにしなければなりません。
ただ、データしか入ってないので、すぐに事業を継続することは難しいでしょう。

話を集中サーバーに戻します。
この集中サーバーにシステムもバックアップするのです。
それでは、とてもバックアップに時間がかかるとお思いでしょう？
それが簡単にできるのです。

そうです。いつものESXiを使うやり方です。

①ESXiのホットバックアップで丸ごとバックアップをしておきます。
参考：http://niriakot.blogspot.com/2011/03/esxi41u1.html
タイミングは一日一回でいいと思います。

②データは1時間おきでも一分おきでもいい。
参考：http://niriakot.blogspot.com/2011/03/rdiff-backupver126-22opensuse113.html

これらを遠隔地に飛ばすのです。
その飛ばし方は
①は飛ばす前に圧縮して、rdiff-backupで差分を飛ばしたあと、解凍して保管。（ほとんど差分にはならないが、書き込みの少ないサーバーの場合はコピーする容量が少なくなる。なお、コピーするESXiのデータはスプリットで作ったほうがいい。）
②は遠隔地とVPN経由、NFSの設定をし、同じくrdiff-backupで差分の同期をとる。
できれば、①と②を飛ばす経路（回線）は別のほうがいいと思いますが、SOHOをベースに話しているので、一本でも問題ないでしょう。
事前にデータ量を考慮し、設計してみてください。

これを基本に回線を太くしたり、サーバーを増やしたりしていくわけです。
万が一、メイン拠点が落ちたとしても、バックアップ地のサーバーを立ち上げれば、すぐに事業を再開できます。
（リモートで電源onできることが前提。かつ、モバイル端末が使える前提条件があります。）
常に両方を電源入れとけばいいじゃないかという場合、同期をとるのが大変です。
ちなみに電源を入れておくダミーサーバーは必要です。
（理由は下のDNSのところで）

なので、片側拠点ずつの運用が今回の話の前提です。

ここで問題なのは、バックアップ地のシステムがコピーであるという事。
IPが一緒なのに問題ないのか？
そうです。IPを一緒にするのが味噌なのです。
ローカルIPは一緒で、グローバルIPが別。
ホスト名はまったく一緒。
というネットワークを作ってしまうのです。
DNSにもそう記述しておく。
そうすると、サブのほうにもアクセスが行ってしまうので、ダミーサーバーを建て、本番のほうへ遷移する設定が必要。
あとは本番側のサーバーがすぐに復旧しないとしたら、DNSで元のIPを削除しておきましょう。
DNSのキャッシュが消えるころにはアクセススピードも元に戻ることでしょう。

SOHOの場合、事務所と自宅が一緒の方が多いと思いますが、できれば、実家にでも一台サーバーを置いてもらいましょう。
これで物理的にバックアップを分散できるため、システムとデータの助かる確率は高くなるはずです。

これを比較的アクセスの空いているときに切り替えしてほんとに元に戻るのか試す必要はあります。
それにバックアップ側で動いたデータが今度はメインになりますので、バックアップ機のバックアップ方向を逆にする事も必要になります。

これらはぜひ、手順化することで、間違いはなくなると思います。
全自動化をすることは可能ですが、コストの問題がありますので、まずは、半自動で運用し、問題があったら、自社に合わせてカスタマイズしていくというのがよいと思います。

ここまでで、いろんなサーバーが出てくるので、相当コストがかかりそうだと思っているあなた、ESXiを使えばいいので、各地に一台ずつサーバーがあれば十分です。
それに自作機で十分です。
なお、サーバーの関係や動作などは図にしたほうがわかりやすいので、弊社サーバーが立ちあがったら、図も作成し載せておきます。

目的を絞り込むことでBCPの基本を作成し、プライオリティを付けることで、拡張していく。
これが重要です。

ご依頼は
webmaster@niriakot.jp
まで。