ローテーションを伴うバックアップとしてのファイルへのZFSスナップショット

ローカルのFreeNASシステムがあり、バックアップにZFSスナップショットを使用したい。
FreeNASには、使用する組み込みのレプリケーションタスクがあります

zfs send snapshot_name

スナップショットをリモートシステムに送信します。しかし、これにはもう一方の端にZFSを備えたシステムが必要です。

スナップショットをファイルに送信し、この圧縮および暗号化されたファイルをリモートマシンに送信します。

これは可能です

zfs send snapshot_name | gzip | openssl enc -aes-256-cbc -a -salt > file.gz.ssl

毎日、ストレージプールのスナップショットを作成し、すべてのスナップショットを30日間保持します。
スナップショットを取得するたびに、このスナップショットをファイルにパイプします。
-snapshot_file 1にはすべてのファイルがあります（2GBとしましょう）
-snapshot_file 2にはsnapshot_file 1への変更のみがあります（5MBとしましょう）-snapshot_file
3はsnapshot_file 2への変更を保持しています。等々。

31日目に、snapshot_file 1が削除されます（過去30日間の変更のみが必要なため）

したがって、snapshot_file 2はすべてのファイルを保持する必要があります（2GBのsnapshot_file 1 + 5MBの変更）

しかし、このアプローチでは毎日（31日目以降）新しい2GBファイルを作成してリモートシステムに送信する必要があります。これはオーバーヘッドが大きすぎます。

X日間の履歴を持つバックアップ戦略として、ファイルにパイプされたスナップショットを使用する最良の方法は何ですか？

PS：そこには多くのバックアップソフトウェア（rdiff-backupなど）があり、それを使用できることがわかっています。しかし、私はこれがどのように行われるのか興味があります。

スナップショットをファイルシステムに保存するのではなく、ファイルに保存する場合（たとえば、zfs receive）、私は恐れていますが、これは不可能です。

受信側のZFS

送信側と受信側でZFSを使用する場合、スナップショット全体を転送することを避け、前のスナップショットと比較したスナップショットの差分のみを転送することができます。

ssh myserver 'zfs send -i pool/dataset@2014-02-04 pool/dataset@2014-02-05' | \
  zfs receive

ZFSはスナップショットを認識し、相互ブロックを一度だけ保存します。ファイルシステムにスナップショットを理解させると、古いスナップショットを問題なく削除できます。

受信側の他のファイルシステム

この場合、スナップショットを個々のファイルに保存しますが、ファイルシステムはスナップショットを認識しません。既にお気付きのように、これは回転を中断します。スナップショット全体を送信する必要があるため、帯域幅とストレージスペースが無駄になりますが、個々のスナップショットを削除できます。彼らはお互いに依存していません。次のような増分スナップショットを実行できます。

ssh myserver 'zfs send -i pool/dataset@2014-02-04 pool/dataset@2014-02-05' \
  > incremental-2014-02-04:05

増分スナップショットを復元するには、以前のスナップショットも必要です。これは、古い増分を削除できないことを意味します。

可能な解決策

私の最後の例で示したように増分を実行し、毎月新しい非増分を実行できます。新しいインクリメンタルはこの非インクリメンタルに依存しており、古いスナップショットを自由に削除できます。

または、他のバックアップソリューションを調べることもできます。ハードリンクを使用するrsnapshotがあり rsyncます。完全なバックアップが1回だけで済むため、ローテーションで非常に優れた仕事をし、帯域幅効率が非常に高くなります。

その後、bareosがあります。帯域幅とスペースを節約するインクリメンタルを実行します。非常に便利な機能があります。増分セットから完全バックアップを計算できます。これにより、古い増分を削除できます。しかし、それはかなり複雑なシステムであり、大規模なセットアップを対象としています。

ただし、最善の解決策は、受信側でZFSを使用することです。帯域幅効率、ストレージ効率、および他のソリューションよりもはるかに高速になります。私が考えることができる唯一の実際の欠点は、そのボックスに少なくとも8 GiB ECCメモリが必要であることです（サービスを実行せず、それだけを使用する場合は4 GiBで問題ないかもしれませんzfs receive）。