メッセージ。 - さくらインターネットの共有サーバーでHDD障害が起きたのかな？
# さくらインターネットの共有サーバーでHDD障害が起きたのかな？
今日気付いたのだけど、3日前に書いてここに置いていた文章が1つ消えた。「匿名と日本の社会」というタイトルのもの。
ポストしたときに、自分がなにかオペミスをしたのかと思ったけど、たしかちゃんと投稿したはず。サーバー側で何か問題（CGIのバグとか）が起こったのかもしれない。
ただ、momoka.cgiはさくらインターネットの共有サーバーで運用しているため、細かいログ（error.log）やサーバーの障害情報（dmesg等）は取れないのだ。どうしたものか。
まずはポストしたかどうか定かではないので、客観的事実を確認したいと思い、RSSリーダー（Fastladder）に記事が残っていないか確認してみた。すると、果たして問題の記事は残っていた。全文配信しているので、ロスレスで回復できる。やったぞ。
そして、やっぱり記事は投稿していたんだ。3日前、確かにmomoka.cgiはポストを受信し、文章を掲示していた。だけどそれが、何らかの理由でロールバックしてしまったのだ。では原因はなんだろう？
共有サーバーにログインして、データファイルの日付を確認してみる。
RSSリーダーによると、日付は本当は「2009/06/05 16:48」でなければならない。なのにデータはこれより古い。「CGIでファイルを上書きしてしまった」というような、アプリケーションレイヤでの問題ではなさそうだ。
ならば、バックアップスクリプトが動いたとき、古いファイルで上書きしてしまったのだろうか。この線を疑って、別サーバーに保存されているバックアップ済みファイルを見てみた。バックアップは2世代だけ世代バックアップを取っているので、1～2日前のデータならば確認できる。
結果として、日付は2ファイルとも同じで6月1日のもの。つまり、「バックアップスクリプトの問題であって、かつ少なくともここ1～2日で障害が起こった」という線はなさそうだ。ただし、バックアップスクリプトが問題かどうかは、これ以上追い掛けられない。（スクリプト内容をチェックすることは可能だが後回し）
そこで次に、サーバーの障害か、クオータによるディスクフル（書き込み不可）がロールバックを発生させた可能性を疑ってみた。だが、クオータによるディスクフルはなさそう。共有サーバーのコントロールパネルで確認したところ、まだ8%しかディスクを使用していない。
ということで、サーバーのHDD障害が濃厚になった。さくらの共有サーバーではaccess.logを毎日保存してくれるサービスがあって、それを確認してみると次のとおり。
…明らかにおかしい。6月4日から6月5日までのデータが欠けていて、6月6日のデータ量がやけに小さい。こりゃあ、6月6日にHDD障害が発生したんだな。それで、さくらのオペレータさんが、6月4日に取ったバックアップからデータを復旧したんだと思われる。
ただ、さくらのサイトでは、障害についてとくに報告もないんだよなぁ（→お知らせ）。さくらの共有サーバーって、こういうサポートレベルなのか。や、悪い意味じゃなく。月500円と安いからね。多くを求めるつもりはない。次に同じような問題が起こったとき、復旧の目安にしたいのでメモ。
ポストしたときに、自分がなにかオペミスをしたのかと思ったけど、たしかちゃんと投稿したはず。サーバー側で何か問題（CGIのバグとか）が起こったのかもしれない。
ただ、momoka.cgiはさくらインターネットの共有サーバーで運用しているため、細かいログ（error.log）やサーバーの障害情報（dmesg等）は取れないのだ。どうしたものか。
まずはポストしたかどうか定かではないので、客観的事実を確認したいと思い、RSSリーダー（Fastladder）に記事が残っていないか確認してみた。すると、果たして問題の記事は残っていた。全文配信しているので、ロスレスで回復できる。やったぞ。
そして、やっぱり記事は投稿していたんだ。3日前、確かにmomoka.cgiはポストを受信し、文章を掲示していた。だけどそれが、何らかの理由でロールバックしてしまったのだ。では原因はなんだろう？
共有サーバーにログインして、データファイルの日付を確認してみる。
[yfujisawa@www1429 ~/data/Momoka-0.51]$ ls -lth -rw----rw- 1 yfujisawa users 2.7M Jun 1 21:51 mdb.scm
データファイルの日付
RSSリーダーによると、日付は本当は「2009/06/05 16:48」でなければならない。なのにデータはこれより古い。「CGIでファイルを上書きしてしまった」というような、アプリケーションレイヤでの問題ではなさそうだ。
ならば、バックアップスクリプトが動いたとき、古いファイルで上書きしてしまったのだろうか。この線を疑って、別サーバーに保存されているバックアップ済みファイルを見てみた。バックアップは2世代だけ世代バックアップを取っているので、1～2日前のデータならば確認できる。
結果として、日付は2ファイルとも同じで6月1日のもの。つまり、「バックアップスクリプトの問題であって、かつ少なくともここ1～2日で障害が起こった」という線はなさそうだ。ただし、バックアップスクリプトが問題かどうかは、これ以上追い掛けられない。（スクリプト内容をチェックすることは可能だが後回し）
そこで次に、サーバーの障害か、クオータによるディスクフル（書き込み不可）がロールバックを発生させた可能性を疑ってみた。だが、クオータによるディスクフルはなさそう。共有サーバーのコントロールパネルで確認したところ、まだ8%しかディスクを使用していない。
ということで、サーバーのHDD障害が濃厚になった。さくらの共有サーバーではaccess.logを毎日保存してくれるサービスがあって、それを確認してみると次のとおり。
[yfujisawa@www1429 ~]$ ls -lt log | head total 5340 drwxr-xr-x 2 yfujisawa users 3584 Jun 9 00:06 webalizer -rw-r--r-- 1 yfujisawa users 654968 Jun 9 00:05 access_log_20090608 -rw-r--r-- 1 yfujisawa users 66538 Jun 8 00:05 access_log_20090607.gz -rw-r--r-- 1 yfujisawa users 14020 Jun 7 00:05 access_log_20090606.gz -rw-r--r-- 1 yfujisawa users 801419 Jun 4 00:05 access_log_20090603 -rw-r--r-- 1 yfujisawa users 78816 Jun 3 00:05 access_log_20090602.gz -rw-r--r-- 1 yfujisawa users 59898 Jun 2 00:05 access_log_20090601.gz -rw-r--r-- 1 yfujisawa users 40379 Jun 1 00:05 access_log_20090531.gz -rw-r--r-- 1 yfujisawa users 57229 May 31 00:05 access_log_20090530.gz
定期保存されたaccess.log
…明らかにおかしい。6月4日から6月5日までのデータが欠けていて、6月6日のデータ量がやけに小さい。こりゃあ、6月6日にHDD障害が発生したんだな。それで、さくらのオペレータさんが、6月4日に取ったバックアップからデータを復旧したんだと思われる。
ただ、さくらのサイトでは、障害についてとくに報告もないんだよなぁ（→お知らせ）。さくらの共有サーバーって、こういうサポートレベルなのか。や、悪い意味じゃなく。月500円と安いからね。多くを求めるつもりはない。次に同じような問題が起こったとき、復旧の目安にしたいのでメモ。
Comment
Trackback