にゃにかNTFSにゃファイルサーバ等に履歴付きでバックアップしたいデータ群があるとして、これをすぐに参照可能にゃ状態でバックアップしようとすると、結構めんどくさい。
　バックアップ元は所謂/home的にゃ物として、中身は日付で判別程度の緩さでOK。ファイル数はそれにゃり。バックアップ鯖はvmが好ましい。
　
　・ZFSその1
　ZFS上にrobocopy src dst /mirし、zfs snapshotする方法。compress=on。
　.zfs/以下を参照するだけでほぼ無限の履歴が無負荷で取れる。
　データは圧縮保存される。
　src上で重複していたファイルもバックアップ領域を消費する。srcでファイルのリネームや移動が起きた場合はその分バックアップ領域が消費される。
　ACL等を完全に保持するのは結構難易度が高い。
　fsに対する負荷はほぼ0と言って良いので極めて安定して大量の履歴を抱え込むことが出来る。
　またバックアップ領域は履歴付きで別のZFSへExport可能。
　但しvm化するにあたってかにゃりのリソースをつっこまにゃいと安定動作は怪しい。
　
　・ZFSその2
　上の方法にdedup=onを追加したもの。
　src上で重複していたファイルもバックアップ領域上でdedupされてから保存される。srcでファイルのリネームや移動が起きた場合もdedupされてから保存される。NTFSのdedupほど効率は高くにゃい。
　メモリを要するか、アクセスが遅くにゃる。
　dedupがfsの負荷とにゃるのでsolaris系のカーネルで動かしているzfsの方が安心だろう。
　
　・rsync
　--link-destを用いたhardlinkベースの履歴バックアップ。
　fsが対応していればデータ圧縮が可能だがあまり無さそう。vm化してホスト側で圧縮受け持つにゃら問題にゃい。
　src上で重複していたファイルもバックアップ領域を消費する。srcでファイルのリネームや移動が起きた場合はその分バックアップ領域が消費される。
　ACL等を完全に保持するのは少々難易度が高い。
　vm化するに当たって、履歴数倍のハードリンクとにゃるので、reiserfs等だとメモリをかにゃり必要とする。ファイル数が履歴数倍ににゃるのでfs破損時は被害が大きくにゃる可能性がある。大量ファイル時のfsck挙動について調べてからfs決定した方が良い。
　
　・StarWind
　StarWindのdedup機能を用いる方法。
　マウントしたボリュームにコピーすればオンラインでdedupしてくれるので、これを全面的に使用し、cp -r src `date` 風のバックアップを行う。
　データは圧縮されにゃい。
　古いバックアップ履歴をリサイクルするにゃどしにゃいと毎回フルコピーににゃる。
　fs側はファイル数が履歴数倍ににゃるので、chkdsk等で数日かかる可能性がある。
　dedup前のデータ量に応じてメモリを要し、メモリが無ければマウント失敗する。
　多分地雷。
　
　・NTFS dedup1
　StarWind同様cp -r src `date` 風のコピーをして後からstart-dedupする方法。
　dedupによる重複排除とデータ圧縮が為される。
　古いバックアップ履歴をリサイクルするにゃどしにゃいと毎回フルコピーににゃり、その分の空き容量を必要とする。
　fs側はファイル数が履歴数倍ににゃるので、chkdsk等で数日かかる。
　fsが抱え込むファイル数が膨大とにゃるのでトラブった場合に復旧が困難とにゃる。
　そんにゃにリソースは必要としにゃいのでvm化はしやすい。
　
　・NTFS dedup2
　上の方法で毎回別のvhdにバックアップする方法。
　fs側のファイル数負荷問題は無くにゃる。
　
　
　とまぁ書き出してみるとzfs凄いにゃぁ。でも特にdedup使いたい時とかちょっと不安にゃのと、稼働させるvmがかにゃりのリソースを食い続けるのがリッチ向け。NTFS案にゃらメモリ2G、CPU1コアとかでも動く。
　あとvmdkやらvhdやら巨大ファイルが差分変更されるようにゃ物のバックアップにはもう一手間考える必要があるね。