http://support.fsv.jp/info/nw20120625_01.html
誠実なまとめだと思う。以下は例によって個人的な見解ですが……。
はてブでは「それはバックアップじゃなくて待機系」と鬼の首をとったように言う人が多いみたいだけど、それはまぁその通りなんだが、こういうクラウドホスティングサービスにおけるバックアップって何か、というのは必ずしもはっきりしない面があると思う。

ファーストサーバは検討すらしたことがないのでどういうサービスだったのか知らないけど、ユーザがroot権限すら持ってシステムを好きに触れるような系の場合、バックアップといってもごくシンプルにシステムイメージも込みでVMイメージのスナップショットを取るようなものになりがちなんじゃないかなあ。どこにどういうユーザデータがあるかなんてわかりゃしないので。毎朝6時にバックアップを更新するとなっているから、待機系というよりはそういう構成だったんじゃないかなぁと想像する。
でもまあ一日一回スナップショットを取るというシステムだったら、脆弱性対策のパッチをバックアップ系にも同時に更新するというのはちょっと杜撰で、バックアップなんだから翌日まで待てばいいじゃん、と思うんだけど、復旧のタイミングというのは確率的に発生するわけで、システムの規模がでかくなればバックアップからの回復が毎日1件以上ある可能性はあり、だったら同時に適用しちゃえばいいじゃん、という考え方もわからなくはない。まぁでもバックアップからの回復時にパッチをあてるなり、数時間のバッファを取るなり、安全性を確保することはできたかもって思うけど、そういうのは後出しじゃんけんな気もする。

たとえば、amazonのEC2にはバックアップというものはないよね。データのバックアップのためのサービスはいろいろあるが、何もせずに勝手にバックアップされるようなものではなく、ユーザが自分でどうバックアップするのか考える必要がある。でももちろん、VMインスタンスは、ホスト機器の故障に影響を受けることなく動作するようにはきちんとなっている。
でもこういう環境では、サービス提供者側が脆弱性対策を施したりはしない気がするんだよね。

というわけで、バックアップ系の設計の問題というよりは、脆弱性対策パッチや検証過程のミス(リンク先の1や2)の問題が大きい気がするなあ。
それにしてもしんどそう。
Shared publiclyView activity