現在，netatalkでつくったファイルサーバにsparse bundle fileとしてTime Machineによるバックアップを入れている．（404 Not Found参照）
で，ネットワーク経由だと途中で回線が切断した時にどうなるのかがだれしも不安なんじゃないかと思う．ということで，諸般の事情で2週間ほどとったTime Machineのバックアップが使えなくなったので，新しくバックアップをとるこのタイミングでいろいろ実験してみようと思った．
回線を途中で抜いてみる(1)
バックアップの準備中と表示されている時にネットワークケーブルを抜いてみた．
結果，50MBをバックアップしようとしたら50GBしか空き容量がありませんでした的なメッセージが出て，最近のバックアップの欄にはエラー発生と赤く表示される．
が，もう一度繋いでバックアップすると問題なくできる．
回線を途中で抜いてみる(2)
さっきのはいじめ方が足りないなと思ったので，今度は，実際に書き込んでいる途中でケーブルを抜いてみる．
結果，バックアップイメージをマウントできませんでしたとエラーが出て，同様に，最近のバックアップの欄にはエラー発生と赤く表示される．
で，もう一度繋いでバックアップしてみると…今度はマウントできず（泣）．sparse bundle fileを直接ダブルクリックしてもマウントできず．ディスクユーティリティで修復しようとしても何も出来ず．結構途方に暮れる状態になる．
と思いきや，20分ほど待ってたらなぜかマウントできるようになってた…．当然，バックアップも正常に動作．そんなアホな．まあ，冷静に考えればサーバのDebianもその上につくったsparse bundle fileもジャーナリングされてるわけで，この程度でファイルシステムに齟齬が生じるわけはないのだけど．
ちなみに，途中で抜いた時にバックアップするはずだったファイルも（次のバックアップの時までに変更されなければという条件付きだろうけど），きちんと失敗したバックアップの段階でバックアップされてたようになってた．最初の準備の段階でどのファイルをどうバックアップすべきかは処理されてるから，直後のバックアップ操作でバックアップされなくても，以後のバックアップでそのファイルがバックアップされれば自動的に前倒しでバックアップされていたことになるのだろう．
最初，マウントできなかった時は言葉の限りアップルを罵りたくなったけど，最終的に何もせずにマウントされたので及第点かな．もうちょっとアラートを工夫していただきたい．あと，心配性な人はsparse bundle fileを1世代分だけバックアップしとけば十分だと思った．ほんとにやばければ以後のバックアップでトラブるのですぐにわかるし．
しかし，ファイルの移動が削除+新規ファイル作製で実装されるのは何とかならないんだろうか．そりゃ，ファイルツリーのみから移動を検出するのは厳しいけど，Time Machineの場合OSのレベルでファイルの操作をモニタしてるわけだから，移動を移動として実装するのはそんなに難しくないと思うので．
