June 25, 2012
ファーストサーバの大規模障害の件は、データ復旧が不可能という発表があったそうだ。
大規模障害の概要と原因について（中間報告）(ファーストサーバサイト)
復旧レベルにもよると思うが、Linuxの場合、HDDから削除復旧をさせた時に、ファイル管理情報がすでに一致しない状態になると、仮にファイル実体が復旧しても、ファイル名、フォルダ名がわからなくなって、それがいったい何のファイルかわからない。共用サーバの場合は誰のファイルかわからないので、事業者側も、うかつに渡すことができない、など言ったケースにもなることもありうるので、基本的に復旧は無理だろうなと思っていた。
今回は、専用サーバでも、ユーザー企業側のアクセス権限がないユーザーにもファイルが見えてしまうという指摘を受けたそうだが、一度消してしまったファイルである以上、それはある意味仕方のないことで、社内セキュリティの話までしだすと、もう復旧は無理と言うしかない、というのも予測できる。
このトラブルは多数の会社さんが巻き込まれてしまったようで、あのサービスもこのサービスも止まっているという状況になってしまったようだが、しっかり元データを管理されている会社さんで、二日程度で別のサーバでサービスを復旧させた会社もあるようだ。
ITが専門の会社であればあるほど現場対応力の高いスタッフがいる可能性が高く、そうでなければ、そうでない方向に。ましてSLA100%をうたっていた同社であれば、余計に完全にお任せムードになっていて、にっちもさっちもいかない会社まである程度想像はつく。
該当サーバがレンタルサーバや一般企業のホスティングなので、ばっちり２重化しているというケースがあまり期待しにくいし、不幸なのはファーストサーバ内で２重化およびバックアップをしていて、丸ごと消えてしまった、というケースはきっとあるだろう。
不幸すぎるこの一件に関して言うと、如何に別の場所にバックアップが存在していたか？この一点の差が対応力の差になる。
１．デイリーもしくは一か月ごとにDBも含めてローカルバックアップを取っている。
２．ステージングサーバ（本番と同じ構成になっているアップ前のテストサーバ）が別の場所に存在する。
３．最初のWebサイトのデータや、外注にお願いして更新したファイルの差分ファイルが担当者のHDD内のデスクトップなどにちらばっている。
-----ここまでが割と無事に戻る復旧ライン。ここから下は相当前に先祖返りするパターン
４．ブログシステム等CMSを使っていたり、CGMのサービスを運営していて、初期時のデザインデータまではある。（CMSのコンテンツはgoogleキャッシュにしかバックアップがない）
５．最初にアップしたWebページのアップロードデータだけはある。
----復旧できないパターン
６．全てサーバ上で構築したので、ローカルには何もない。
外注お任せで構築して、先方も既にバックアップを消している。
７．管理体制、人間関係の不備で元データが全部ない。
・辞めた社員のマシンに入っていたので今はもうない
・辞めた社員が管理してたので、パスワードすらわからない
・外注お任せだったが、関係切れてしまい、今さら連絡できない。
・etc....
…などの状態レベルによって対応力が変わり、１～３ぐらいの範囲であれば、どうにか短期間で復旧できたのではないだろうか。
同社のSLAがどうであったかに関わらず、何か不幸なことが起きる時には、どうしても何かが起きてしまう、というのは、原発で我々は目の当たりにしてきた。
おそらく今後SLAをタテにした損害賠償の話で結構な時間を費やしていくことであろう。親会社がソフトバンクグループともあって、どういう対応が今後取られるのかは正直、不明であるが、基本的に利用規約にある返金規定の範囲に沿って対応がなされることになると思う。
100%はない、という大前提の中、それでも一番高い復旧可能性はどういう方法が良いか？というのを考えていくしかない。
もし、今、復旧対策をやってない会社さんは、こういうことは基本的にはどこでも起きうることであり、明日は我が身、という思いで対応をされた方が良いと思います。
もしネットに売上や集客を構成できているのであれば、避難訓練みたいに、復旧訓練ができたら理想ですね。トラブルの時には慌てますから、平時の準備がいざという時に生きます。
今、サービス復旧に取りかかっている沢山の方々、お疲れ様です。少しでも元の状態に近い状態で復旧できることを祈っています。
p.s.今回一番かわいそうだと思ったのはメールが丸ごと消えてしまったこと。popであればローカルにバックアップはあるでしょうが、imapの人は困りますよね。このニュース見て、VPSにあるメールサーバのデータをローカルのMacにコピーするスクリプトを動かし始めました。前はVPSをもう一個借りてミラーリングすればいいかと思ってたけど、場所は分けた方が良いですね。
p.s.2.バックアップには、とにかく新しいファイルや更新されたファイルをコピーしていくインクリメンタルバックアップと、削除したこともバックアップに反映するバックアップがあるが、前者の方がシンプルで安全性が高いが、消えてほしいものが残るので、その後の対応に苦慮する（商用提供はできない）。後者は内容の整合性が確実だが、うっかりした時に「消えた状態」や「フォルダやドライブが見えなかった状態」をバックアップしてバックアップも全部消えるというトラブルが稀に起きたりする。後者の方が１段階難易度レベルが高いので安易に採用する方法ではない、と思っておこう。僕は消えるよりはるかにマシと、シンプルなインクリメンタルなバックアップ方法を取ることが多い。
なお、もう一つ確実なのが、「フォルダ丸ごとトップレベルのフォルダ名に日付をつけて全部コピーしていく」という方法がある。DATのテープに保存するようなのも同じ理屈だ。当然、コスト競争力としてもホスティング等のサービスで標準で商用提供されるものではない。つまり、バックアップにかかるコストとデータの必要性とやり方は、個々に意識しなくては実現できないと言うのが、ユーザー側が自分でバックアップをしなくてはいけない理由になる。
p.s.3.ファーストサーバのコピーは、待機系サーバへデータをミラーリングするためのコピーだったらしい。つまり、何かあった時に表舞台に立って処理をさばくSLA100%を実現するためのコピーであって、表から見えないローカルネットワーク内のサーバに保存するようなバックアップのためのバックアップではなかった、というのが、結果としてセキュリティアップデート処理を焦った理由にもなったのだろう。待機系サーバは、「何かあった」時のための仕組みであるならば、セキュリティアップデートも一旦、待機してほしかったと思うのは後の祭りだが残念なところである。