web-dev-qa-db-ja.com

ローテーション付きのバックアップとしてファイルする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にはすべてのファイルが含まれています(2 GBとしましょう)。
-snapshot_file 2には、snapshot_file 1への変更のみがあります(5 MBとしましょう)。
-snapshot_file 3は、snapshot_file 2への変更を保持します。等々。

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

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

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

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

P.S .:私が使用できるバックアップソフトウェア(rdiff-backupなど)がたくさんあることは知っています。しかし、私はこれがどのようにできるのか知りたいです。

14
Martin Grohmann

スナップショットをファイルシステムではなくファイルに保存する場合(例:zfs receiveを使用)、恐れ入りますが、これは不可能です。

受信側のZFS

送信側と受信側でZFSを使用すると、スナップショット全体を転送する必要がなくなり、前のスナップショットと比較したスナップショットの差分のみを転送できます。

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

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

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

あなたの場合、スナップショットを個別のファイルに保存し、ファイルシステムはスナップショットを認識しません。すでに気づいたように、これは回転を壊します。スナップショット全体を送信する必要があるため、帯域幅とストレージ容量が浪費されますが、個々のスナップショットを削除できます。彼らはお互いに依存していません。次のように増分スナップショットを作成できます。

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メモリが必要であることです(サービスを実行せず、zfs receiveにのみ使用する場合は4 GiBで問題ないかもしれません)。 。

12
Marco