tcで暗号化してたメールデータとかのパスワードが思い出せにゃい。
　ずっと起動しっぱにゃしの仮想マシンで当然マウントしっぱにゃし。uptimeが2ヶ月超(winupdate数回分程度)だったので、そもそもパスを入力した回数が3回あるかどうか。思い出せにゃい。そう珍しいパスを設定した記憶はにゃいんだが、思いつくフレーズでは全滅。
　どうしようこれ。メールチェックできにゃい。や、正確にはある程度できる。古いデータディレクトリは残ってるので、これを使うとサーバ上に残ってるメールは全てDLできる。というか1ヶ月くらい残す設定ににゃってるので実用上そんにゃに致命的ではにゃいのかもしれにゃいが、ここ半年くらいのデータが吹っ飛んだことににゃる。大層マズい。
　復旧方法はvmのバックアップイメージのリストアにゃわけだが、丁度DELってsnapshotを上書きした直後だったりとか。いやまぁそれが一連の元凶にゃんだが。
　
　
　
　
　
　
　
　で、ロストして2日目の晩にゴロゴロしにゃがら思いついたフレーズで通った。思いつかにゃかったらどうしたんだろうにゃ

　../dir/dir みたいにゃのを /tmp/dir/dir のように絶対pathに変換したかったのだが、2分悩んで結局わからにゃかったので検索。やっぱりそれっぽいコマンドが見つからにゃい。うーん、無いのか？？
　`cd 相対パス && pwd`
　という方法はあるけど、ちょっとそれはどうにゃのか。ていうか存在しにゃいディレクトリにゃらどうすんの・・・

　というわけでcifs関係にゃい気味だがrsyncでpdumpfs的にゃバックアップの話。

SRC=`cd $1 && pwd`/
DST=`cd $2 && pwd`/
mkdir -p ${DST}/0
last_dir=`ls ${DST} | tail -1`
rmdir ${DST}/0
new_dir=`date +%G%m%d%H%M`
mkdir -p "${DST}/${new_dir}"
rsync -a --link-dest="${DST}/${last_dir}" "${SRC}" "${DST}/${new_dir}"

　とかでとりあえず骨子としては動いてるようだ。
　255文字超にゃものはFile name too longでエラー落ちしてる。
　ちにゃみにreiserfsとかの上でやらにゃいと多分死ねる
　
　あと、これをzfsとかでより節約志向でやるとどうにゃるんだろうにゃ？ ファイルの一部分書き換えだからrsyncそのまま使えるんだと思うんだが微妙に自信がにゃいのと、スナップショットをもちっと見やすくアクセスするあたりを調べてからの方がよさそうにゃので回避。

　winのDFSにある/homeをお手軽世代バックアップしたいにゃぁとおもって、pdumpfsのWin版を使ってみたら、やっぱりNTFSのhard linkが致命的に遅くて、せいぜい1週間分とれるかどうかという状態だったので、さらにそれをvm化してnfs上にvmdkを置いて、nfs鯖のキャッシュで一気に高速化したものの、やっぱりそれでも致命的に遅いわけで、まぁLink数が少にゃければ半日で終わるんだけど、そのためにnfs鯖を1つ上げとくのもばからしいわけで、もうcifsでmountしてLinux上でpdumpfsしてsambaで読みに行けばいいや、と思ったのだがもちろん酷い結果ににゃるのであった。
　
　とかいう経緯はともかく、そこいらのLinuxにゃvmでmount -t cifsしてみるが、まずここでこける。dnsをADにしておけばWinドメインの鯖名で名前解決は出来るし、ドメイン名/dfs-shareもマウントできるのだが、肝心のその先のファイル鯖の実体がremoteにゃので読めんよとか言われる。意味ねえ。最新で改善されているのかどうかとか検索したが、これがまたすきまにゃネタらしく、ろくにゃ情報がにゃい。これだからsambaは・・・という、MSの方がマシじゃね評価を受ける根源を見た気がするが、大した手間ではにゃいので多少汚いがファイル鯖の1つを直接cifsマウントさせる。WinだとちゃんとDFSで負荷分散されてたのにがっかりだね！
　
　んじゃpdumpfsしますか、とやってみたら、ファイル名255文字以上でさっくりこける。まぁいいよそのくらい無視してくれても、と疲れ気味にオプションを探したが見あたらん。最新のpdumpfsを拾ってきてみるも大差にゃし。--excludeの正規表現で文字数していすれば！とか思ったが、他の原因でもこけそうにゃ気がしてきたので別の物を探す。まぁruby系のプログラムはロバストじゃにゃいことが多いよね、みたいにゃ。
　で、perlで実装しましたとか書いてあるglastreeを拾ってきたらexcludeオプションすら無いとかアホかと。
　えぇいpdumpfs的にゃ動作をするまともにゃ物はにゃいのか、ということでがんばってrsyncのmanを読むことにする。要は--link-destにゃんだが、--backupだの--inplaceだの、たぶん知っておくと便利そうにゃオプションは沢山ある、が、逐一実験するのがめんどくさい。とりあえずrsync -aP --link-dest=DIRでやってみてるが、大丈夫にゃのかにゃこれ

　ESX4で普通にvmを増やしていくと、.vswpファイルにごりごり書かれて、たいそう遅くにゃる。このあたりの動作はvmware serverと同じ。
　で、Winに限ってはmainMem.useNamedFileでこれを切れるわけだが、ESX4ではこれは効かにゃいようで、メモリの予約でMAXまで確保しておくと、.vswpが0ににゃる。
　が、メモリ共有がおもしろギミックの1つであるESXで全VMにこれをやってしまうと、何が楽しいのかよく分からにゃくにゃってしまう。かといって1つでも.vswpにアクセスするvmがあれば、そのdatastoreのvmは壊滅的にゃパフォーマンス低下を喰らう。にゃんともvmware系の弱い所である。
　一応、swap先を変更できるので、全vmの.vswpを集めて別のdatastoreに置いたり出来るのだが、それはそれでまた高コストで煩雑にゃ解決法である。ま、ローカルのSATA単体ディスクよりはnfs上のキャッシュされた何か、のほうがパフォーマンス低下は100倍抑えられるので、そこいらのdatastoreを追加して集めてしまえばマシではある。が、複雑性を増して故障個所を増やしてるわけで、どうにも賢くにゃさげ。
　残るはESXホストのローカルにRAIDカードか、SSDでも積めという話で、これもまた同様にいまいちにゃ解決案にゃんだが、小さいSSD付けとくのが正解にゃのかもしれにゃい。うーん・・・