blogを見ようと思ったら無反応に。何だこれやばくね。
　とりあえずsshで接続して中を見てみる。んー。プロセスはみんな生きてるなあ。lighttpdのエラーログには、php-fpmが空っぽの応答をした時にありがちないつものエラーが大量に発生してる。でもphp-fpmはプロセスも生きてるし、エラーログも無し。何だろうマジで。
　分からんなあ、と思いながら/var/logの一覧を見ていたら、ふと異様な物が目に入った。maillogが14GBある。えーと、これってストレージ上限に達してるよな。やっべ。
　まずmaillogのtailを見る。dkim-milterに繋がらない、というエラーが延々と出ているようだ。ああ、洒落で入れた奴だな。CentOS5.6にしてから何かうまく行ってないなあ。つっても、ちゃんと原因調べるほど頑張る気も無いんだよな。送信ドメイン認証の有用性そのものに疑問も持っていたし（SPFの設計が嫌いなのは別の問題として）、当面は停止しておくか。こんな理由で停めるのもアレなんだが。
　で、仕方無いんでmaillogを空にして、一応blogが応答するのは確認したが、色々おかしくなってるかもしれないのでreboot。異様にシャットダウン処理が重いが、ブート処理に入ったら元通りっぽかった。やれやれだぜ。
　つーか14GBってどんだけリトライしてたんだろう、と思いつつ、再起動後にmaillogが増えてないか一応確認する。何か168MBあるんですが。ひー。慌てて中身を確認すると、空にしてからシャットダウンフェーズでkillされるまでの9分40秒の間に一気に膨れ上がっていて、リブートが済んでからは正常化していた。リブート前は40〜50回/秒くらいのリトライ。こえー。一回につき四行の結構長いログが延々と。何でこんな超高速リトライが起きたんだろう。謎だ。

　鯖監視のシステムが無いのは問題あるかなあ、やっぱり。うーん。監視の設計がいまいちすっきり思い付かないのだ。
　このblogを置いてるさくらのVPSは基本的にはメインサーバの体裁なんだけど、落ちて困るような仕事関係の物は全部Osukini LTの方にあるんだよな。そっちはかなり保守的な運用だから、結構平気なんじゃね、とか思わなくもない。そもそも外向けはsshdとNSDとNginxしかlistenしてないし。というか、Osukini LT上でのWebサービスは立てないことにほぼ決まりだから、Nginxも止めた方がいいか。

　うーん。まあ、そもそも止まらないようにしないとだな…。でも、/var/logが溢れるという問題は事前に防げるんだろうか。空き容量が一定値まで減ったら携帯メールにでも通知するとか。携帯メールも結構気付かないんだよな俺（笑）。
　まー、一日以内に復旧出来れば十分、みたいな仕事ではあるし、そもそも仕事関係への影響も無かったし、再発しなければ様子見でもいいか。でも一応はサーバ監視関係の情報も気に掛けていく感じで。

　CentOSの5.6リリースからそろそろ一週間くらい経っただろうか。またyum-cronから数十個の更新報告が来た。カーネルアップデートもあり。この調子だと、時計の長期観察は当分無理かなあ。
　今回は油断してyum update一発で済ませた。と言っても、リブート前にrpmnewのチェックとマージはしたが。この程度の作業で綺麗さっぱり更新されるんだから楽な時代だ。更新前にスナップショットを取ればもっと気楽だろうけどなあ。その辺は業者が対応する気配も無くもないし、自力で頑張らなくても何とかなるといいが。

　そういえば、三陸沖の巨大地震の後は、数年内に首都圏の直下型が来るケースも複数回あったとか何とかで、例の重要データは東京のデータセンターへのバックアップだと微妙かもしれないなあ…。Googleドキュメント辺りはどうだろうか。20GBで年間5ドルだしな。80GBでも20ドルだ。でも自動化出来るんだろうか、あれのアップロードって。
　と思って調べたら、GoogleCLという公式のCUIツール集があるようだ。んー。でもこれyumで入らないよなあ（笑）。いや別にそこまでyumにこだわりませんが。
　と思いつつさらに調べたら、GDataというAPIモジュールがベースになっているようで、これはyumで管理出来そうな感じ。PythonのAPIが使えるし、これで自前のバックアップスクリプトを試しに書いてみるか。近いうちに。今はちょっと浪漫農場とかFNO開始とかで忙しいしな（笑）。

　つーか、データのバックアップも重要だけど、俺の部屋の重量バランスも微妙に危険なんだよな。全く読まなくなった漫画は処分して軽量化するかなあ…。
　待てよ。捨ててもいいと思ってるくらいの漫画なら、電子化して保管しておくのも手だな。絵は出来れば印刷物のままで見たいけど、こういう電子化はありかも。これも近いうちに調べてみるか。

　さくらのVPS、Osukini LT、NP12の三台ともCentOS5.5(x64)で運用中だが、数日前に5.6がリリースされて、yum-cronが「いっぱい更新あるぜー」とメールを毎日送ってくる。カーネルの更新を含むので少し様子を見ていたが、そろそろ潮時だと思うので作業開始。
　リモートで色々やるのは怖いが、仮に大失敗したとしても、さくらのVPSはシリアルコンソールで最低GRUBシェルまで行ければどうにかなるかも。Osukini LTはsshdの起動まで到達しないとめんどくさそうだが、まあ、サポートで何とかしてくれそうな感じもするし、最悪コンパネの再インストールからやり直してもいい。NP12は実機を触れば何とかなるだろう。

　作業開始前に、一応は下調べから。ふむ。既知の問題点に記述されてる手順がいいらしいので、そうしてみよう。httpdがSSL絡みの問題を起こすことがあるらしい（？）けど、うちでApache使ってるのはNP12の社内Webだけだし、まあ何かの更新でApacheが起動しなくなるのも良くあることだから何とかなるだろ。社内Webは勤務時間内しか使われないから気楽だ。
　つーことで、さくらのVPSから作業開始。リモート管理の方が気楽というのも面白いな。上記の手順をほぼなぞり、iscsi系の起動をoffにして、grub.confのカーネルオプションも一応確認したけどちゃんと転記されているようなので、リブート。問題無し。
　続いてOsukini LTでも同じ作業。問題無し。
　最後にNP12。同じ作業でも格段に重いな…。リブート前の確認で、何故かgrub.confのdefaultが古いカーネルを指していたので、書き換えてからリブート。Apacheを使っているので気になったが、何事も無く起動。

　以上、特に何ということも無く終了。めでたし。
　と思ったら、さくらのVPSの連続稼動時の時計状態をチェックしてたの忘れてた。がーん。とりあえず起動直後の今はこんな感じで。

$ uptime
 20:16:42 up  1:48,  1 user,  load average: 0.02, 0.01, 0.00
$ ntpdate -q ntp.nict.jp
server 133.243.238.164, stratum 1, offset -0.101697, delay 0.03883
server 133.243.238.243, stratum 1, offset -0.101792, delay 0.03728
server 133.243.238.244, stratum 1, offset -0.101693, delay 0.03726
server 133.243.238.163, stratum 1, offset -0.101784, delay 0.03889
server 2001:2f8:29:100::fff4, stratum 1, offset -0.103455, delay 0.03622
server 2001:2f8:29:100::fff3, stratum 1, offset -0.103117, delay 0.03554
12 Apr 20:16:47 ntpdate[2372]: adjust time server 2001:2f8:29:100::fff3 offset -0.103117 sec

　結局、お隣のPC関連の保守を仕事として請け負うことになって、お金を貰うとなるとやる気も倍くらいは出てくるのであった。
　んで、ちゃんと色々聞いて状況を整理したのだが、バックアップがちょっと弱いかも、と判明。
　耐障害性を検討するに当たって、多重化した部分がまとめて死ぬケースとか、本質的に多重化してない部分とかを見落とさないようにするのは重要だ。RAIDで言うと、コントローラーが発狂するとか、電源がはっちゃけるとか、筐体ごと焼失するとか。実際、俺PCはそれで失敗したからな…。他にも、想定外の津波で発電機も燃料もまとめて喪失しましたー、なんてのは典型的だよな。システムを構成してる時は、備えたとこだけ見て「こんだけ備えてれば平気だろー」みたいな気分になるんだけどさ。もっと言うなら、「これだけ備えて破綻したなら許されるんじゃないか」という考えが生じたりもするし。でもそれじゃ意味無いよな。
　現状では、敷地の端と端で定時バックアップしていて、まあこれでも簡単に全滅はしないと思うし、別にこれでいいだろーと思っていた。が、割と適当に設置したこれらのファイルサーバには、いつの間にか重要なデータが積み上がっていたらしい。ファイルサイズもファイル数もえらいことになってるし、飛んだ時の損失予想とか聞いたらちょっと何というか。うへー、と。
　ハード的には安ーいNAS二台だから、片方壊れることはごく当たり前に想定される。それだけでバックアップの無い時間がしばらく発生するし、リストアの手順間違えただけでアウトじゃん。マイグレーション前に死亡というケースもあるよな。さっさと着手しないと怖すぎるな。
　物理的にもある程度離したいし、いっそ海外に置きたいくらいだが、とりあえずはOsukini LTが50GB以上余ってるからそこで試運転してみよう。

　で、コピー元のNASであるが、最初に導入したメインの奴がTeraStationなので、バックアップもLinkStationにしていた。今となっては不自由な気もするが、まーSambaがあれば何とでもなるだろう。
　と思ったが、SMBマウントはもうサポートされないようで、CIFSマウントだとファイル名の文字コード指定が出来ないらしい。むーん。TeraStationはCP932っぽいし、いつの間にか日本語ファイル名だらけで運用されてるしなー。CP932のまま処理するのも手かなあ、などとだらだらやっていたが、LinkStationの方は何故かUTF-8になっていた。どこで変換されてるんだろう。多分メルコNASのバックアップ機能に組み込まれてるんだろうけど。まあ動けば何でもいいか。
　という訳で、あとはシェルスクリプトでGPGでも掛けてscpすれば良かろう。この手順さえ固めれば、海外に置くのだって簡単だろうし。Googleドキュメントとかに置きたいなら別だけど。まー置きたいけどさー。

　NASをハックしてあればスクリプトも置けるのだろうけど、していないのでNP12に処理させることにする。
　まず、以前に作った簡単なバックアップスクリプトをベースに試作。tarファイル作ってgpgファイル作ってscp。うむ。scpはパスフレーズ無しの認証鍵セットを専用に作ってしまえば楽だな。一応動くのは分かったけど、バックアップのサイズがでかいから、一時ファイルを二個も作ると作業用ドライブの半分以上とか占有するんですが。
　ちょっとアレなので、tarとgpgをパイプで繋いでみる。成功。scpもパイプで繋がらないんかな、と思って調べると、標準入力からのコピーは出来ません、とのこと。cp系の決まり事なのかなあ。
　だがしかし、CUIのsshコマンドに妙な機能があった。例えば、

$ tar cpz test-dir | ssh test-host tar xpz

こうすると、接続元で実行しているtarの出力を接続先のtarにパイプした状態で実行される。ははは。こんな使い方あったんか。これは素晴らしいのではあるまいか。
　という訳で、

for dir in foo bar
do
  tar cp $dir | gpg $GPG_FLAGS | ssh -i 秘密鍵ファイル名 -l ユーザ名 ホスト名 cat \> コピー先ディレクトリ/$dir.tar.gpg
done

って感じで書いてみた。現物はもう少しごちゃっとしているが、考え方としてはこれでテンポラリ無しにtar+gpg+scp的なことが可能なようだ。恐らくは。ファイルがでかいせいで、これ書いてる間も遅々として進まないのである。何時間掛かるんだこれ。バックアップの衝突も怖いし、毎日掛けるのは厳しいかもなあ。

追記:
　と思ったら二時間で終わっていた。毎日でも行けるな。