なんか rsync 遅いって記事を見かけたので。めも
さとうふみやすさんが RT してた。 Linuxのブロックデバイスレベルで実現するrsyncより高速な差分バックアップについて 。
話はこんな感じ。
記憶容量がそこそこだったり、通信回線が遅かった時代には問題にならなかった と思われる rsync 遅い問題。問題は上記 web の中にも書いてある通り、GB 単位の データのバックアップの為には rsync の「全データを読み込んでハッシュ計算」って 動作にどうしても時間がかかるってこと。
かと言って、この辺は原理的なものなので、他の代替方法もまた無い。 その辺りが悩ましい。
で、考えてみた。
方式的にはこの「書き込み時にマークしておく」方法しか無いと思う。 つまり、バックアップ実行時の処理を最小にするために、他の時間にできる事を やっておくって事。差分として取り出すべきデータにマークを付けたりだとか。
実装についてはもう 2 つ思いついた。
FS を重ねて 1 つのディレクトリに見せる方式が実装されて久しい。 良く使われるのは CD-ROM を RW に見せて、書き込み分を別の FS に分けておくって 方式。
例えば、新規の書き込みを上に重ねた FS に書き出す様にしたらどうだろう。 バックアップ時には上の FS の分だけ送れば済む。で、送信が完了した分を 下の FS に書き込む。順次移動していって、バックアップ完了時には上の FS は 空になる。別のプロセスからの見え方はバックアップの前後を通して変わらない。
rsync の様にデーモンとして動くものが居れば、割と簡単にできそうに思うし、 カーネルに手を入れなくとも済むかもしれない。
LFS なのだから、ある意味当然。
書き込みはログとしてディスクに記録してあるのだから、バックアップ時に そのログをそのまま送れば済む。前回のバックアップ完了時以後のログ、とかの 形で取り出せれば良い。
実装上の工夫はもう少しできるかも。書き込みが重複するブロックを検出して、 最新の（情報を再現するために最低限必要な）ログだけを抽出するとか。
問題があるとしたら、ディスク容量の関係で、バックアップ前のの変更ログが 失われる場合とかが考えられる、かな。 まぁ、色々面倒で、実装できた OS が限られてきた黒歴史があるワケだしなぁ。
なんか色々考えて、面倒になってきた。いっその事リバース CDN でも 構築すれは、とか考えたりして。リバース CDN 。何それ。 今、思いついたんだけど、バズワードにしかならないか。
いや、まぁ、やる事は rsyslog 。
あるいは NFS を重ねて、そっちからバックアップする、とか。
rsync の設計時の前提が今と合わなくなったのが最大の原因。 でも、大容量データのバックアップの需要自体はあるはずだし、 ストレージの容量は今後も拡大していくはず。 大容量データのバックアップ／同期をどうするか。 考え直すべき時期に来たって事なのだろう。
大容量バックアップに王道無し、かなぁ