2つのミラーリングされたディスクで構成されるZFSプールを使用します。オフサイトバックアップを実行するために、さらに2つのディスクを購入しました。
私の最初の計画は、3番目のディスクをミラーに接続してオフサイトバックアップを作成し、ZFSが回復するのを待ってから、ドライブを切り離してオフサイトに運ぶことでした。これは十分に機能しますが、ディスクが接続されるたびにfull resilverを実行するように見えることに驚いています(読み取り、そしておそらく誤解されていますが、接続するたびにインクリメンタルになります)またはデルタシルバー)。その結果、バックアップは許容範囲よりも長くかかります。
私の要件は、zpoolのオフサイトコピーと、毎日ローテーションできるすべてのスナップショットを用意することです。つまり、再同期には最大で24時間かかることを意味します。現在はそれに近いのですが、プールを拡張するという私たちの計画は、その時間枠を超えてプッシュします。
完全な復元操作を必要としないオフサイトのバックアップを保持するにはどうすればよいですか?バックアップドライブで別のファイルシステムを使用する必要がありますか(ZFSプールの一部にするのではなく、イメージをエクスポートするなど)?別のプールにバックアップを作成し、作成時に新しいスナップショットをそのプールに送信する必要がありますか?
多くのいじくりと実験の結果、かなり大きなトレードオフがありましたが、解決策を見つけました。
まず、私が除外しなければならなかったオプション:
ミラーリングされたプールを備えた2番目のオフサイトZFSサーバーを用意することは、コストのために選択肢になりませんでした。これがオプションであった場合、ZFS送信/受信を利用してスナップショットをリモートプールに送信することが、これまでのところ最善のアプローチでした。
2つ目のオンサイトZFSミラー化プールがあり、ディスクを削除して持ち帰ることができます。これは最初のオプションよりも実行可能ですが、2番目のプールには常に2つのディスクをオンサイトにする(または1つのオンサイトディスクで2つのデータコピーを使用する)必要があります。現在、私には4つのディスクがありますが、サーバーの5分の1のスペースはありません。これは公平なアプローチですが、それでも理想的ではありません。
ZFSのアタッチとデタッチを使用して、バックアップディスクをミラーリングされたプールの内外にローテーションします。これはうまく機能しますが、ディスクが追加されるたびに完全な復元を実行する必要があります。これには受け入れられないほど長い時間がかかるため、これに頼ることはできませんでした。
私の解決策はattach
とdetach
を使用することに似ていますが、online
とoffline
を使用します。これには、完全な再同期ではなく差分再同期を実行するという利点がありますが、プールが常にDEGRADED
状態を報告するという欠点があります(プールには常に2つのディスクがあり、回転するオフサイトディスクにはoffline
とマークされますそれらがリモートストレージにあり、回復し、オンサイトでオンラインになる場合)。
だから、簡単な要約と私のセットアップの概要:
1つのZFSサーバーと4つの同一のディスクがあります。 ZFSは、ミラーリングされたプールを使用するように設定されています。 4つのディスクのうち2つは、このプールの永続的なメンバーです。他の2つのディスクは回転します。 1つは常にオフサイトのストレージにあり、もう1つはすぐに使えるバックアップとして機能するプールの一部です。
バックアップをローテーションするときがきたとき:
zfs scrub
バックアップディスクにエラーがないことを合理的に保証するために完了する
私 zfs offline
リモートで使用されるディスク。オフラインになった後、私はhdparm -Y /dev/id
スピンダウンします。 1分後、ディスクスレッドを部分的に取り外し(電力の損失を確実にするのに十分なほど)、ドライブを完全に引き出す前にさらに1分待って、回転が停止したことを確認します。ディスクは固定バッグに入れられ、保護ケースに入ってオフサイトに送られます。
他のオフサイトディスクを持ち込みます。ホットスワップトレイにインストールされ、スピンアップします。私が使う zfs online
ディスクをプールに復元し、部分的な再同期を開始して並行処理します。
このシステムは、いつでも2つのONLINE
ミラーディスクと1つのOFFLINE
リモートディスク(スクラブ済み)があることを保証します。 4番目のディスクは、回復中またはオンラインのいずれかです。これには、実行中のドライブが故障した場合でも、プールが2つのオンラインディスクの一貫性を保つことができるという利点があります。
過去数週間はうまくいきましたが、私はこれをハックなアプローチだと考えています。大きな問題が発生した場合はフォローアップします。
pdate:これを数か月間実行した後、実際の使用では、デタッチ/アタッチとオフライン/オンラインの両方で再同期に同じ時間がかかっていることがわかりました。私のテストでは、スクラブを実行していたとは思いません。私の直感は、ドライブがスクラブのためにオフラインの場合、完全な回復が必要であることです。
ZfsがスナップショットをリモートZFSマシンに送信しないのはなぜですか?これには単純なbashスクリプトを使用します。
#!/usr/local/bin/bash
# ZFS Snapshot BASH script by Shawn Westerhoff
# Updated 1/14/2014
### DATE VARIABLES
# D = Today's date
# D1 = Yesterday's date
# D# = Today less # days date
Y=$(date -v-1d '+%m-%d-%Y')
D=$(date +%m-%d-%Y)
D1=$(date -v-1d '+%m-%d-%Y')
D10=$(date -v-10d '+%m-%d-%Y')
D20=$(date -v-20d '+%m-%d-%Y')
# Step 1: Make the snapshots
for i in $( zfs list -H -o name ); do
if [ $i == tier1 ]
then echo "$i found, skipping"
else
zfs snapshot $i@$D
fi
done
# Step 2: Send the snapshots to backup ZFS sever
for i in $( zfs list -H -o name ); do
zfs send -i $i@$D1 $i@$D | ssh -c arcfour [email protected] zfs recv $i
done
# Step 3: Destroy snapshots that are 20 days old
for i in $( zfs list -H -o name ); do
if [ $i == tier1 ]
then echo "$i found, skipping"
else
zfs destroy $i@$D20
fi
done
私は snapdump というツールを作成しました。これにより、zfsデータセットの増分ダンプを外部(非zfs)ファイルシステムに作成できます。 Snapdumpは、単一のコマンドで増分スナップショットチェーンを復元することもサポートしています。