大規模災害やサーバーの障害時にもあわてず迅速復旧するために必要なこと、機能とはなにか? 事業継続プロセスを考慮したレンタルサーバー選びのポイントと共に解説します。

急な災害、突然のサーバー停止！ その時あなたのサイトは…

　2012年6月に起こったレンタルサーバーの大手、ファーストサーバ社が5,698件ものクライアントのホームページやメール等のデータを消失させてしまった「ファーストサーバ事件」はまだ記憶に新しいでしょう。

　私は日頃、複数のクライアントから依頼されて、ホームページの制作やさまざまなウェブサービスの運営をしています。あの日、クライアントのひとつがこの事件に巻き込まれました。当初、当該ドメインのメールの受信が滞ったことで、実質的な運営を任されていた私がクライアントより先にサーバーの異常に気付きました。稼働状況を確認すると、メールの送受信ができない、ホームページも表示されず、問い合わせや注文もできないなど、契約しているサービスのすべてがダウンしていました。
　同社のホームページにも一部に不具合が発生してサーバーがダウンしている旨のお知らせが掲示されていましたし、一時的なアクセス障害は廉価型のレンタルサーバー・サービスでは稀にあることです。そう考え直して、復旧をしばらく待っていましたが、実際はずっと深刻なものでした。
　翌日になって物理的にサーバーは回線に接続されました。しかし、元のように復旧はしていません。問い合わせてみると事態は大変深刻なものでした。通常、レンタルサーバー会社はメンテナンスやこのような不測の障害・事故等に備えて内部的にデータのバックアップを行なっています。しかし、このとき、ウェブページやメール等のデータなど、内部的に持っているはずのバックアップ・データも消失してしまっていて同社には復旧することができなかったのです。更にサーバーは”契約時の初期状態”に戻っていて、アカウントやCGI（Common Gateway Interface／サーバーが、ブラウザからの要求に応じて、外部プログラムを起動するための仕組み）、フォームなどの各種設定、メールアドレスやFTP （File Transfer Protocol／ファイル転送プロトコル）のログインID等も初期化され、契約時に送られてきた書類がなければ管理者用のログイン・パスワードも解らない状況でした。

　同社によって物理的にサーバーを復旧させるところまでは行なわれましたが、メールやホームページ、CGI、データベースなど、日常業務を稼働させるための復旧作業はすべて契約者自身に委ねられました。私はクライアントから一切を任されていたので、その日と翌日の予定をすべてキャンセルし、復旧のための作業にかかりました。

復旧が迅速に進んだ理由（著者の場合）

　このとき、クライアント自身が最新のバックアップ・データを持っていたかどうかによって復旧にかかった作業時間は大きく異なったことでしょう。… 続きを読む… 続きを読む