私は現在、2つのサーバーがまったく同じハードウェア、ディスクなどを持っています。
1台のサーバー(server1)が「メイン」サーバーになります。これは基本的に、raidz2を備えたサーバーであり、ユーザーが接続するSMB共有があります。
もう一方のサーバー(server2)は、server1(raidz2)と同じように構成されていますが、server1のバックアップ専用です。これは、ディスク障害、火災、水害などでserver1が失われた場合のオフサイトバックアップとなることを目的としています。
Server2へのバックアップを行うための最良の方法を見つけようとしています。
最初は、rsyncのようなものを考えていました。これはcronで設定するのは簡単で、週に1回実行することができます。
あるいは、zfs send/recvで何かを考えていました。私の理解では、ZFSは「スナップショット」を実行できるので、多くのスペースを失うことなくスナップショット/増分バックアップを作成できれば素晴らしいと思いました。これは実装が難しい/エラーが発生しやすいと思います。
前に述べたように、両方のサーバーはハードウェアとraidz2レイアウトに関して同じように構成されています。私の現在の状況に対して、皆さんは何をお勧めしますか?
ZFSは非常に回復力があります。ファイルシステムの出荷の最も基本的な例は次のとおりです。
# zfs snapshot tank/test@tuesday
# zfs send tank/test@tuesday | ssh [email protected] "zfs receive pool/test"
送信(およびスナップショットの送信)の前にスナップショットをメモします。
これをスクリプトにまとめて、リモートに送信した後でローカルスナップショットを削除するか、ディスク容量に余裕がある場合は保持することができます。以前のスナップショットをバックアップサーバーに保持します。
ソースと強く推奨される読み物: https://pthree.org/2012/12/20/zfs-administration-part-xiii-sending-and-receiveing-filesystems/
インクリメンタルZFS送信/受信を使用します。 ZFSは、ファイルシステム全体を調べる必要なしに、前回のスナップショット以降に何が変更されたかを認識しているため、rsync
よりも効率的です。
datapool/fs
という名前のファイルシステムを完全にバックアップしたいとします。
最初に、バックアップを宛先サーバーに保存するためのプールと、ソースプールに再帰的なスナップショットを作成します。
dest # zpool create datapool ...
source # zfs snapshot -r datapool/fs@snap1
次に、データ全体を初期バックアップとして送信します。
source # zfs send -R datapool/fs@snap1 | ssh dest zfs receive datapool/fs
来週(または任意の期間)、ソースプールに2番目のスナップショットを作成し、の宛先に段階的に送信します。そのとき、ZFSは、その週に変更されたもの(削除、作成、および変更されたファイル)のみを送信するのに十分スマートです。ファイルが変更されると、ファイル全体は送信されず、変更されたブロックのみが送信および更新されます。
source # zfs snapshot -r datapool/fs@snap2
source # zfs send -ri snap1 datapool/fs@snap2 |
ssh dest zfs receive -F datapool/fs
バックアップするたびにスナップショット番号を増やして、操作を繰り返します。
不要になった場合は、いずれかのサーバーで未使用の古いスナップショットを削除します。
帯域幅に制約がある場合は、パイプラインにgzip
/Zip
コマンドを挿入するか、ssh圧縮を有効にするなどして、データをオンザフライで圧縮/解凍できます。
source # zfs send -ri snap1 datapool/fs@snap2 | gzip |
ssh dest "gunzip | zfs receive -F datapool/fs"
mbuffer
を活用して、次のように安定した帯域幅を使用することもできます page :
dest # mbuffer -s 128k -m 1G -I 9090 | zfs receive datapool/fs
source # zfs send -i snap2 datapool/fs@snap3 |
mbuffer -s 128k -m 1G -O w.x.y.z:9090
注:zfs -r
フラグは、Solaris以外のZFS実装では使用できません。 http://lists.freebsd.org/pipermail/freebsd-fs/2012-September/015074.html を参照してください。このような場合、ターゲットで-F
フラグを使用せず、代わりにデータセットを明示的にロールバックします。ソースで新しいデータセットが作成されている場合は、スナップショット+増分送信/受信を行う前に、最初にそれらを個別に送信します。
もちろん、基礎となるデータセット階層なしでバックアップするファイルシステムが1つしかない場合、または独立したバックアップを実行する場合は、増分バックアップの実装が簡単で、ZFSの実装に関係なく同じように機能するはずです。
T0:
zfs snapshot datapool/fs@snap1
zfs send datapool/fs@snap1 | ssh dest zfs receive datapool/fs
T1:
zfs snapshot datapool/fs@snap2
zfs send -i snap1 datapool/fs@snap2 |
ssh dest zfs receive -F datapool/fs
Zfs send/receiveを使用して1 TBをリモートに送信する際に問題が発生しました。単一の1TBファイルシステムを分割して、複数の子を含めることにしました。ネットワーク障害が発生した後、最悪の場合、子のみが必要です。憤慨します。再帰的な送信を処理し、リモートの同期を維持するためにスクリプトを使用します: https://github.com/dareni/shellscripts/blob/master/zfsDup.sh
このスクリプトが他の人に役立つことを願っています。
出力例:
# zfsDup.sh shelltests
Test: array_add()
Test: array_clear()
Test: array_iterator()
Test: nameValidation()
Test: isValidSnapshot()
Test: getSnapshotFilesystems()
Test: getSnapshotData()
Test: getRemoteDestination()
Test: printElapsed()
Test: convertToBytes()
Shell tests completed, check the output for errors.
# zfsDup.sh zfstests
Start zfs tests.
Test: new parent file system.
Test: new child file system.
Test: simulate a failed send of the child filesystem.
Test: duplicate and check the child@2 snapshot is resent.
Test: snapshot existing files with updated child data.
Test: simulate a fail send os child@3
Test: snapshot test1.
Test: snapshot test2.
Test: snapshot test3.
Snapshot tests completed ok.
Test: remote Host free space.
Test: new remote FS with no quota.
Test: incremental remote FS update with no quota.
Cleaning up zroot/tmp/zfsDupTest/dest zroot/tmp/zfsDupTest/source
Test execution time: 89secs
ZFS tests completed, check the output for errors.
# zfs list -t all -r ztest
NAME USED AVAIL REFER MOUNTPOINT
ztest 344K 448M 19K /ztest
ztest@1 9K - 19K -
ztest@6 9K - 19K -
ztest/backup 112K 448M 19K /ztest/backup
ztest/backup@1 9K - 19K -
ztest/backup@2 0 - 19K -
ztest/backup@3 0 - 19K -
ztest/backup@4 9K - 19K -
ztest/backup@5 0 - 19K -
ztest/backup@6 0 - 19K -
ztest/backup/data 57.5K 448M 20.5K /ztest/backup/data
ztest/backup/data@1 0 - 19.5K -
ztest/backup/data@2 0 - 19.5K -
ztest/backup/data@3 9K - 19.5K -
ztest/backup/data@4 9K - 19.5K -
ztest/backup/data@5 0 - 20.5K -
ztest/backup/data@6 0 - 20.5K -
# zfs list -t all -r zroot/tmp
NAME USED AVAIL REFER MOUNTPOINT
zroot/tmp 38K 443M 19K /tmp
zroot/tmp/zfsDupTest 19K 443M 19K /tmp/zfsDupTest
# zfsDup.sh ztest zroot/tmp root@localhost
================================================================================
Starting duplication 20151001 16:10:56 ...
[email protected]
ztest/[email protected]
ztest/backup/[email protected]
Duplication complete 20151001 16:11:04.
================================================================================
# zfsDup.sh ztest zroot/tmp root@localhost
================================================================================
Starting duplication 20151001 16:11:25 ...
[email protected] to date
ztest/[email protected] to date
ztest/backup/[email protected] to date
Duplication complete 20151001 16:11:29.
================================================================================
# zfs snapshot -r ztest@7
# zfsDup.sh ztest zroot/tmp root@localhost
================================================================================
Starting duplication 20151001 16:12:25 ...
[email protected]
ztest/[email protected]
ztest/backup/[email protected]
Duplication complete 20151001 16:12:33.
================================================================================
# zfs list -t all -r zroot/tmp
NAME USED AVAIL REFER MOUNTPOINT
zroot/tmp 124K 442M 19K /tmp
zroot/tmp/zfsDupTest 19K 442M 19K /tmp/zfsDupTest
zroot/tmp/ztest 86K 442M 19K /tmp/ztest
zroot/tmp/ztest@6 9K - 19K -
zroot/tmp/ztest@7 0 - 19K -
zroot/tmp/ztest/backup 58K 442M 19K /tmp/ztest/backup
zroot/tmp/ztest/backup@6 9K - 19K -
zroot/tmp/ztest/backup@7 0 - 19K -
zroot/tmp/ztest/backup/data 30K 442M 20K /tmp/ztest/backup/data
zroot/tmp/ztest/backup/data@6 10K - 20K -
zroot/tmp/ztest/backup/data@7 0 - 20K -
Send/recvのものを管理し、プログレスバーを統合するための素晴らしいツールがあります
sysutils/zxferの下のfreebsdポートツリーまたは github にあります
Sysutils/zfstoolsやsysutils/zfsnapなどのツールを使用して、スナップショットの作成を自動化することもできます。スナップショットは、zxferを介してリモートマシンに同期されます。
公式のzfssend/recvプロセスに関するその他のドキュメントがあります FreeBSDハンドブック
また、 送信/受信をパイプで例:bzip2
and rsync it 。 このブログ投稿 メモのように、スレーブには「読み取り専用」が設定されている必要があります。