雲が消えた日の衝撃──ファーストサーバのデータ消失事故

クラウドERP活用による経営情報管理の一元集約化は、システムの形態として理想的。 しかし、一箇所に集められた情報がすべて消えてしまったとしたら‥‥シャレになりません。 バックアップを取るということの大切さが身に染みた事件でした。

photo credit: hermitsmoores 278:365:2015BWH via photopin (license)

事故はこうして起きた

2012年6月20日、
大阪市のレンタルサーバ会社ファーストサーバ
大規模な「データ消失」事故を起こしました。
あたかもが消えてしまうかのように、
データが丸ごと消されたのです。
クラウド屋が決して起こしてはならない究極の信用破損であり、
業界全体にとっても影響の大きな事件です。
ファーストサーバ発表の説明によると──
(脆弱性対策のための)更新プログラム自体に不具合があったことに加えて、 検証環境下での確認による防止機能が十分に働かなかったことと、 メンテナンス時のバックアップ仕様の変更が重なり、 今回のデータの消失が発生した。

とあります。
つまり‥‥、
この説明の意味はよく理解できなくても、
いくつかの不運が重なって起こるはずのない事故が起こった
ってことです。
被害にあった顧客件数は5698件で、ほとんどが復旧不可能な状態。ウェブサイトやメールに加え、顧客情報やスケジュールなど多種多様なデータが失われ、業務が止まった企業からは悲痛な叫びが聞こえてくる。いったい何が起きているのか。
   ***
 23日、ファーストサーバは複数の顧客で共有するタイプのレンタルサーバーサービスに関し、「データ復旧を行うことは不可能と判断した」と公表。顧客には「お客様で取得されておられるバックアップデータによる再構築を行っていただきますようお願い申し上げます」と呼びかけた。
 共有型ではない専用サーバーサービスについては、当初、データ復旧ソフトにより一部、回復できたとし、顧客にデータを引き渡していた。しかし、ある顧客企業から「社内の他人のメールが読めてしまう」と報告があり、確認したところ、復旧データに欠損があることが判明。22日夜、すべての復旧データの提供をとりやめた。
   ***
 ファーストサーバは月々の利用料金だけで手軽にサイボウズを利用できる「サイボウズ Office9 for ASP」のパートナー企業。加えて、顧客企業が購入したパッケージ版のサイボウズを運用するサーバーとしても数百社に貸していた。このうち、メール、スケジュール、顧客管理、営業記録など、約400社のサイボウズのデータを丸ごと消失させてしまった。
 ネット上の掲示板には「顧客データもサイボウズに入れてたから、電話来ても誰が誰だかわかんないし何も答えられないし、サーバが落ちててって言い訳もできないし、会社自体が記憶喪失になったみたい」「たぶん明日は段ボールから顧客との契約書原本取り出して、電話取りながらあいうえお順に並べる作業から一日が始まります」といった書き込みがなされている。
   ***
 ファーストサーバによると今回、脆弱性対策のために更新プログラムを作り、いつものようにプログラムを走らせた。ところが、その更新プログラム自体に大きなバグ(不具合)があった。「ファイル削除コマンド」を停止させる記述漏れと、メンテナンスの対象となるサーバー群を指定する記述漏れがあったというのだ。
 そのバグに気づかないまま、本番環境のサーバーで更新プログラムを起動。だが更新プログラムは、対象外のサーバーでファイル削除コマンドを実行し、次々とデータを消去していった。この範囲が、顧客件数5万件のうち約5700件に及んだ。不幸はここで終わらない。
 通常なら、バックアップデータから元のデータを復元することで一両日中にウェブサイトなどは復旧する。バックアップデータは、本番環境とは違うサーバー、あるいは外部記憶装置に定期的にとっておくことが基本だ。ところがファーストサーバでは事情が違った。
 ファーストサーバにおけるセキュリティ対策では、3つのHDDに同じファイルをコピーしていた。1つは「本番系」。もう1つは本番系のHDDやシステムに不具合が生じた時、即座に切り替え、正常稼働を続けるための「待機系」。もう1つが、毎朝6時に本番系のデータを丸ごとコピーしておく「バックアップ系」だ。この3つが、すべて同じサーバー内に同居していた。
 あろうことか、ファイルを削除してしまう更新プログラムのバグは、本番系、待機系に加え、同じサーバー内にあるバックアップ系のHDDまでをも消去するという代物だった。
 なぜ、外部にバックアップをとっておかなかったのか。ネット上では技術者を中心に、この点が指弾された。これについてファーストサーバの村竹室長は、こう話す。「おっしゃっているような一般的なバックアップというのは、我々のような低価格の料金で提供するのは難しい。サーバー内の別のディスクでとることを、我々はバックアップと考えています」
   ***
 同種のトラブルとしては国内最大級に発展しそうな大規模データ消失。今となってはバックアップがない企業・団体は泣き寝入りするしかなく、損害賠償も多くを見込めそうにない。日本経済新聞(2012/06/26)より

「稼働率100%」「バックアップ不要」とまで謳っていたサービスなのに、
こともあろうにバックアップデータもろとも初期化してしまう
なんてことを起こすなんて‥‥
いや、しかし、
批判するのは簡単ですが、
これは教訓のはず。
ここから何かを学べというメッセージにちがいありません。
かなり身近なところに被害を受けた仲間が何社もあります。
わたしの所属する某団体では、
サイトが復旧不能になって担当者が大慌てしているようです。
うちやうちのクライアントさんが
ファーストサーバを選ばなかったのは単なる幸運にすぎません。

けっきょくは泣き寝入りなのか

補償だのなんだの騒いだところで、
けっきょくは自己の危機管理の甘さが露呈するだけなので、
ユーザーは比較的冷静に粛々と自力でのリカバリーに努めている模様。
障害の程度が常識の範囲から逸脱しすぎているせいか、
フェイスブック等への投稿も、
「批判」というより「あっけにとられている」といった印象です。
とにかく、
消えたデータは戻りません。
とりかえしがつかないんです。
つらいですね‥‥。
胸が痛みます。
そういえば何年かまえに、
>子どもの写真がいっぱい入ったパソコンが壊れた!
と、
お客さんから助けを求められたことがありました。
データ復旧サービスを紹介してあげたところ、
見積はかなり高額で、
足もとを見られて吹っかけられましたが、
結果としては最低限の出費でデータは無事に取り出せました。
このときはほんとうにうれしかった。
しかし、
今回の事故ではデータは戻ってこないのです。
わたしもクラウドの住人。
これは対岸の火事ではありません。
雲が消えるなんてことはあってはならないのです。
>キミのところはだいじょうぶなのか?

きかれたら
なんて答えるか考えてみました。
>うちはゼッタイだいじょうぶですよ。
なんて、
心では信じていたとしても口には出さないでしょうね。
お客さまに無用な心配をさせないほうが親切
っていう見地に立てば、
「だいじょうぶですよ」って言ってあげたほうがいいんでしょうけど。
大きく見せることもなく小さく見せることもせず、
専門的なことを言っても通じないのが辛いとこですけど、
>○○○の対策を○○○のように講じていますし、
>過去○○年間の実績として○○○ですし。

のように、
事実を事実としてありのままに伝える。
当社のクラウド
は、
Caché(キャシェー)という道具でこしらえてあります。
Cachéにはシャドウイングというしくみがあって、
本番サーバに対してバックアップサーバ(シャドウサーバ)を
ネットワーク上に準備しておけば、
地理的に遠く離れた場所に設置した別のサーバ上で、
メインサーバの動きをそっくりそのまま同時進行させることができる。
つまり、
Aというサーバが某かの原因でダウンしても、
それ以降の動作をBというサーバで引き継ぐことができる。
(ユーザは通常Aにログオンしていますが、
障害が発生したら接続先をBに変更します。)

ファーストサーバは1台のマシンの中に複数(3つ)のハードディスクを搭載し、
それぞにデータをコピーすることを「バックアップ」と称していたようなのですが、
これはいわゆるRAID(レイド)というしくみ。
マシン自体が複数存在するシャドウイングとはまったくの別物です。
シャドウイングというしくみでは、
1台のサーバがダウンしても別の場所にある別のサーバで
業務を継続することができます。
ではもし、
ユーザが誤ってデータを消去してしまったときはどうか。
「消去」という操作もまたシャドウサーバで再現されますから、
けっきょく両方のサーバからデータが消去されてしまうことになります。
しかも、
誤って消去してしまったことにユーザがすぐ気づくとはかぎりません。
3日くらいたってから、
>あ、しまった!
>あれは消しちゃいけないデータだった(T_T)


慌てることになるかもしれない。
こういう事態も想定して当社では、
前日最後のデータベースの状態を丸ごと別のマシンにコピーします。
と同時に、
同じ丸ごとデータベースを1週間に1度コピーしておくマシンもあるし、
2週間に1度コピーしておくマシンもあります。
つまり、
Aサーバのすべてのデータベースが瞬時にBサーバにシャドウイングされ、
1日1回Cサーバに丸ごとコピーされ、
1週間ごとにDサーバに丸ごとコピーされ、
2週間ごとにEサーバに‥‥、月ごとにFサーバに‥‥、年ごとにGサーバに‥‥という具合に、
念入りに何重にもバックアップされています。
かなり安全だと理解していただけるのではないでしょうか。
しかしだからといって、
阪神大震災や東北大震災クラスの震災がまた起こったらどうなるか‥‥なんて
実はわからないんです。
会社が直撃されて社員が勤務できなくなったら、
サーバが無事でもどこまでサポートできるかわからない。
ウイルスだって、
いつなんどきどんな凶悪なものが蔓延するかわりません。
残念ながら一流企業じゃないんですもん。
クラウド型のビジネスを10年以上続けていますが、
事実として、
「データが消えてしまって戻らない」という不始末はいちども起こしていない
‥‥っていう程度の「だいじょうぶ」なんです。
ファーストサーバの今回の悲劇は、
バックアップが徹底していなかったことが原因の人為ミスです。
クラウドがどうのこうのいう次元ではありません。
なので、
クラウド化への流れを止めないでください。
そのお手伝いをわたしがさせていただきますので。
今回の事故で被害に遭われた方々に、
無責任な気休めを言わせていただきますが‥‥
消えたのがデータでよかったじゃないですか。
ま、
そう考えましょうよ。
消えたのが雲でよかった
とね。