同業界なので、反面教師ということで言及してみる。

ファーストサーバの障害、原因はプログラム記述ミスとプロセスの複合
（atmarkit.co.jp）

多分、この業界で一番やっちゃいけないことをやらかした一件という気がします。

まず、この会社はレンタルサーバやホスティングという、端的にいえば顧客に対してサーバの領域とネットワークを間貸しして収益を得ている会社で、いわばサーバ管理専門の業者ということ。そんな会社が、お客さんから預かってるデータをバックアップごと消失させてしまうという大失態をやっちゃったわけですね。

本来、こうしたサーバのデータというのは、こんなことにならないように2重3重のバックアップ管理がされているもので、まずPVが多く日常的に負荷が高い場合は2系用意してロードバランスされているという運用が一般的。お金があればそれに加えてバックアップにも同様の構成でコールドスタンバイ（あるいはホットスタンバイ）されている。つまり、メインに障害が生じた場合はネットワークを切り替えてバックアップが稼働するという仕組み。

で、これらはテータ的なバックアップではなくシステムとしてのバックアップなので、データ自体のバックアップは日回しバッチなどで別領域へ退避して保存されていたりするもの。加えて、データセンターなどが物理的に障害に陥った場合（火事とか洪水とか）に備えて、磁気メディアやテープなどにバックアップして週1か月1くらいで遠隔地（サーバが東京であれば北海道とか九州とか別の地方）に移送、保管するという対策をとることもありますね。

今回の件は、どうやらメンテプログラムに不具合があって、バックアップを含めて全部消去してしまうというド派手なことをやっているようだけど、その理由が、今回のメンテというのが脆弱性対策のバッチだったようで、それはバックアップも含めてやらないと意味が無いものだから、とのこと。

まず疑問なのは、脆弱性対策のバッチがなんでファイルを削除してるの？ってこと。

しかも、データ復旧できないということは、完全フォーマットしちゃったってことですよね。ただのファイル削除なら、実はそのディスクからファイルを復元できる可能性はあるんですが、そんな不完全な状態で復元するより、最初から復元できないと諦めた方が良いと踏んだのか。まぁ、件数が膨大なので、復元する手間やそれが完全である保証がないことを考えると、諦めた方が無難ってことですかね。

次に、主系とバックアップに対して同時にバッチ実行しちゃったのはなぜ？ってこと。

バックアップにも脆弱性対策しなきゃいけないんだという話はわかります。でも、それが同時でなければ、主系で失敗したことがわかったら、バックアップにはやらない選択もあり得たんじゃないかと思うんですよ。これは、同社の発表にある「対象外のサーバ」まで間違って当てちゃったってやつにバックアップも含まれちゃってたってことですか。そりゃないすよね。

あと、主系とバックアップは物理的に同じサーバ（ハード）だったんじゃないかという疑い。

少なくとも、データバックアップ目的のサーバは物理的に主系とは別ハードであるべきです。バックアップまで逝っちゃうというようなことは同じサーバで管理してるときによくやらかすわけで、それが商用サービスだったとなれば目も当てられないってことに。で、そんな事態が今回起こったってことですよね。物理的に別系統だったにも関わらずファイルを消し尽くすバッチってどんだけですかって話。

以上のことから、しごく月並みな教訓ですが、

• メンテはメインとバックアップに同時に行わないこと
• バックアップば物理的に別ハードに切り分けること

の2点は遵守しましょうと。

あと、これをやらかした人たちはおそらくゴールの見えないデスマ中でしょうけど、人間だれでもミスはするもので、今回は重大な事故ではあったけども、人の命に関わる事故ではなかったというあたりは救われてます。ので、しばらくは大変だと思うけど、必要以上に凹まず頑張って欲しいですね。正直、会社は大分厳しくなると思うけど、再就職の際は、大失敗の経験というのはわりと大きい（ミスする怖さを知るという経験値は大きい）もので、これをバネに新天地でスーパーサイヤ人みたいになれば良いんじゃないかと思います。もちろん、会社の立て直しに励むも良し。