ファーストサーバーのデータ消失事故の教訓

今、ネット上を騒がせているファーストサーバの大規模サーバ障害＆全データ消失事故！被害を受けた企業は、なんと5000社以上なんだとか！

今回、運営するサイトの一つ、うぇぶかにほんが、その事故に巻き込まれてしまった。なんとサーバーの中のウェブサイトもプログラムもデータベースも各種設定までもが、跡形もなく消えてしまったのだ。

不幸中の幸いだったのは、他のサイトは、それぞれいろんな会社のサーバーに分散してリスク管理していたということだろいうか？もし、ここに全部のサイトがあったら・・・たぶん死亡してたかも。やっぱリスク分散は、大切だったということか。

しかし今回ばかりは、さすがに、本当に

(((((( ;゜Д゜)))))ガクガクブルブル を体験させてもらった！

その事故は、今週の水曜日(6/20)に突然起こった。

その日は私は、昼頃から夕方にかけて、うぇぶかにほんのデータを作っている最中だった。もちろん途中で何度も保存しながら。そして夕方6時過ぎ頃、保存ボタンを押すと、突然Internet Explorer の『503 Service Temporarily Unavailable』か『404 Not Found』かなんかの怖いエラーメッセージ画面が！

「あれ、なんか、やっちゃったかな？？？」

急いで[戻る]ボタンで元に戻るも、やはりエラーに。これは、おかしいと思い、サイトのホームを見てみると、やはりエラーになった。

「なんだ、サーバーがダウンしてるのか・・・」

その時は、よくあるサーバー障害かと思ったので、しばらく待つことに。しかし、７時になっても8時になっても一向にサイトが表示されない。これは変だと思ったので、ファーストサーバのサイトに行ってみたら「サーバー障害で復旧中」のアナウンスが。しかし、9時、10時・・・と時間は経過するも一向にサイトは復活しない。

これはマズいと思ったので、とりあえずこのブログと日本Web化計画の方にサーバー障害についての記事をアップ。

その後、深夜3時頃まで、ファーストサーバのサイトと２ちゃんねるとかツイッターを徘徊しながら情報を収集しつつ復旧や新たな情報の公開を待ったが、ファーストサーバ側から原因や経過の発表はなかった。

すでにサイトが表示されなくなって8時間が過ぎていたので、あきらめて、朝には復旧していることを祈って寝ることにした。朝7時半頃起床し、早速サイトを開く。しかしまだサイトは表示されていなかった。

「マジかよ・・・やばいじゃんかよ・・・嫌な予感がしてきた」

恐る恐るファーストサーバのサイトを開くと・・・。そこには、管理プログラムのバグによりWEB・メールなどデータが消失の可能性がある。復旧作業は継続しているが、同時にサーバーを初期化するので完了したらメールをすると書いてあった。

「データ消失ってウソだろ！？データベースもか？？？初期化したら空になっちゃうじゃんかよ」

それは、いまだかつて見たことがないとても恐ろしい内容であった。というのも昨日作っていたデータはもちろんだが、直近のデータのバックアップを今月はまだ取ってないことを思い出したからである。

すぐに思いついたのは、つい最近アップしたばかりの「東京スカイツリー特集」の記事である。バックアップは取ってないし、もしまだGoogleにキャッシュされてなかったら終わりである。すぐにGoogle検索のキャッシュを使って探してみる。

「うおぉーもうキャッシュされてた（歓）！」

すぐに東京スカイツリー特集のページをソースごとローカルに保存した。他のヤバそうなページも、バックアップを取ってあるページも、かたっぱしからどんどんGoogoleキャッシュを使って保存しまくった。

というのも、取ってあるデータベースのデータファイルが本当にちゃんと元とおりに再現されるかどうか、実際にやってみなるまでは不安でしかたなかったからだ。

万が一の時は、Googleキャッシュが書き換えられるまでが勝負である。ちなみにGoogleに保存されているキャッシュは、「cache:http://webka.jp/special/rep/no_201206101p1.html」のようにURLの前に「cache:」を付けると検索できる。

サイトはすでに19時間ほどエラー表示になったままだったが、とにかくどうにもならないので報告のメールが来るまでの間、ドキドキしながらGoogleキャッシュを保存する作業を続けた。ファーストサーバ側のデータの復活はすでにほとんどあきらめていたからだ。従業員100人以上の企業がこれだけ時間がかかっても一つも復旧できないってことは、つまりほぼ完璧にアウトってことだからである。

「ん、よく考えたらメールも死亡しているんだよな」

うぇぶかにほん用のメールアドレスがいまさらながら機能していないことに気がついて、ファーストサーバからの報告メールがちゃんと届くかを確認した。同時に、うぇぶかにほん宛てのメールが受信できないことをアナウンスする。

寝不足と単純作業の疲労感、悲しみ、怒り、諦め、時間、いらだち、不安が、潜在意識の不安を呼び起こして、頭が軽いパニック状態になっていた。もし、万が一、バックアップを使ってもデータベースが正常に再現できなかったら・・・うぇぶかにほんの1000ページほどのコンテンツが無に消えたら・・・ああ・・・考えただけでも死にたい気分になる。そんな時は、２ちゃんねるやツイッターで同じ被害者で、もっと悲惨な人をみつけて、自分をはげました。

そして午後３時半頃、ついに運命の「【重要】6月20日に発生のサーバー障害についてのご報告」メールが届く。その内容は・・・

「本障害では弊社メンテナンス作業において用いる特定の管理プログラムにバグがあり、お客様データが消失したことが判明いたしました。～中略～早期にサービスを復旧させるため、サーバーを初期状態に戻し、現時点で可能な範囲での復旧作業を実施しサービスを再開することといたしました。～中略～お客様にて以下に記載のサーバー初期設定方法をご確認いただき、メール送受信ならびに WEBコンテンツの公開作業をお願いいたします。」

少しは期待していたんだけれど、結局、朝から状況はまった変わってなかった。

最悪のシナリオである。

しかし、こんなひどい話はおそらく前代未聞ではないだろうか？一体、何がどうなったら5000社以上のデータを一瞬で吹っ飛ばすことができるのだろうか？本当にプログラムのバグなのだろうか？本当は、退職者が仕掛けた時限爆弾による報復テロとかキレた社員による社内テロとかじゃないのか？と思ってしまう。

すでにサイト停止から22時間ほど経過していた。とにかく嘆いていてもしかたがないので、初期化されたサーバの管理システムに入り、メールとＦＴＰの設定を行い、まずはメール、そしてサイトと復旧作業を進めていった。

そして、データベースを再構築し、いよいよバックアップデータをインポートしてみる。緊張の一瞬である。というのもこれまで、データベースが飛ぶという経験がなかったので、テストでインポートを試したことはあったが、本物のデータでやったことは、これが初めてだからだ。インポートのボタンを押すとほぼ一瞬で完了した。サイトを見るとデータが復活していた。

「おおおー復活できるぞ！」

とりあえずサイトを「メンテナンス中」表示にし、復旧作業を続けた。翌日の午前中頃に、やっとひととおり終わったところで、重大なことに気がついた。サイトにデータが足りないページが予想よりも多くあるのだ。原因をよくよく調べると一つのバックアップファイルが前回より前のものだった。しかも一番、情報量の多いやつが。

あっちとこっちのミスが重なり、まさに踏んだり蹴ったりとはこのことである。

不幸中の幸いなのは、ウェブサイトのデータは、Googleがキャッシュに保存してくれているということである。これが今流行のクラウドの社内データとかECサイトの会員データとかだったらそうはいかない。まあECサイトであれば、かなり小まめにバックアップしているとは思うけど、クラウドの場合、そもそも情報漏洩（ろうえい）対策の為にローカル保存を禁止している会社も多い。しかも今回の事故では、そのクラウド向けのサーバーも逝っちゃったんだとか。

「クラウドの意味ねぇーじゃん・・・」

まあ、そんなこんなで、ひたすら復旧を続けていたんだけど、復旧の作業効率を上げる為に途中でプログラムを改善しはじめたりしてたら止まらなくなっちゃって、結局、プログラム作るのにけっこう時間とられた関係もあって、サイトが完全復旧を果たしたのが6/24(日)夕方であった。

サイトが消えてから仮再開まで約４２時間、そこから完全復旧まで約５４時間、合計約９６時間（４日）もの時間と労力をロスしてしまった。

今回の事件の教訓、それは・・・

バックアップは忘れずに～！　

ＰＣの基本だけど、これが一番重要なんだと改めて強く再確認したのであった。

≫≫バックアップと言えばこれ

では、また