今回のサーバ障害のまとめ
04 / 01 水曜日 2009
今回のサーバ障害の経緯をまとめました。
【障害原因】
3/26（木）OpenPNEプロジェクト関連サイトをホスティングしているAmazon EC2の該当サーバにディスク障害が発生し、仮想サーバがハングアップした。EC2サポート担当によるデータの復旧作業にも失敗し、サーバのデータは失われた。別サーバに保存しているサイトのバックアップデータも、設定ミスにより正しく保存できていないため、OpenPNEプロジェクトサイトの一部データが、完全に失われた。
【障害内容】
OpenPNEプロジェクトに関連するサーバの障害状況
・3/26～3/30までのOpenPNE公式サイト(http://www.openpne.jp)、OpenPNE公式SNS(http://sns.openpne.jp)の一部停止
・OpenPNE公式サイトのブログデータ2週間分消失
・OpenPNE公式SNSのユーザー情報、書き込み情報2ヶ月分消失
【今後の対策】
今回の障害の直接原因はサーバのディスク障害であるが、バックアップデータが正しく保存されていないことが、データの消失を招き、障害を拡大させた原因である。今後のサーバ運営にあたっては、下記のバックアップ対策を強化し、貴重なサーバデータの保全に努める。
・サーバWEBファイルの定期的（日次）バックアップ
・サーバDBデータの外部サーバへのリアルタイム複製
・サーバDBデータの定期的（日次）バックアップ
※OpenPNEホスティングminiプラン(http://mini.openpne.jp)、マンションプラン、占有サーバプランなどの商用サービスは別サーバ、別体系で運用しているため、障害は発生していません。
コメント:2
- fukasawa 09-04-02 (木) 14:15
-
該当サーバというのは、どういうスペックのサーバを使っていて、なぜ障害が起こって、データのバックアップはどのようにしていて、どういう設定ミスをしたのか、明らかにしていただけませんか？
- Mamoru Tejima 09-04-07 (火) 20:38
-
http://aws.amazon.com/ec2/instance-types/
Small Instance (default)*1.7 GB memory
1 EC2 Compute Unit (1 virtual core with 1 EC2 Compute Unit)
160 GB instance storage (150 GB plus 10 GB root partition)
32-bit platform
I/O Performance: Moderate
Price: $0.10 per instance hourなぜ起こったかは不明です。サポートはディスク障害だと言っていました。
バックアップの取り方
・深夜にmysqldumpコマンドによるデイリーバックアップ三世代を同一サーバに保管
・バックアップデータをrsyncでバックアップサーバに毎日転送どういう設定ミスをしたのか？
・EC2のインスタンス（VPS）のデータの保全性が低いことを詳しく調べていなかった
・データベースのパスワード変更を行っていたが、バックアップスクリプト側に設定を反映していなかった
・そのため、デイリーバックアップ、バックアップ側サーバのデータ共に、保存できない状況がおき三日分のバックアップデータすべてが利用できなくなった。というところです。