zfsプールの増分/連続バックアップを実行する方法は？

zfsプールをオフサイトで継続的/増分的にバックアップするにはどうすればよいですか？

send/receiveオーバーSSHは、スナップショットを手動で管理する必要がある方法の1つであると認識しています。

私が見つけたいくつかのツールがありますが、ほとんどはもはやサポートされていません。

有望に見えるツールの1つはhttps://github.com/jimsalterjrs/sanoidですが、広く知られていないツールは、データを破損/削除する可能性があるという点で、より多くの害を及ぼすことが心配です。

連続/増分zfsバックアップはどのように実行されますか？

ZFSは信じられないほどのファイルシステムであり、私のローカルおよび共有データストレージのニーズの多くを解決します。

一方で、可能な限りクラスター化されたZFSのアイデアが好きですが、時には実用的ではないか、ストレージノードを地理的に分離する必要があります。

私が持っているユースケースの1つは、Linuxアプリケーションサーバー上の高性能な複製ストレージです。たとえば、データの低遅延NVMe SSDドライブの恩恵を受けるレガシーソフトウェア製品をサポートしています。アプリケーションには、セカンダリサーバーに複製できるアプリケーションレベルのミラーリングオプションがありますが、多くの場合不正確で、10分間のRPOです。

ローカル、リモート、またはその両方のセカンダリサーバー（同様または異なるハードウェアでZFSを実行している）を使用することで、この問題を解決しました。以下に詳述する3つのユーティリティを組み合わせることで、継続的なレプリケーション、深いスナップショット保持、柔軟なフェールオーバーオプションを提供するレプリケーションソリューションを作成しました。

zfs-auto-snapshot - https://github.com/zfsonlinux/zfs-auto-snapshot

定期的なZFSファイルシステムレベルのスナップショットを有効にする便利なツール。通常、本番ボリュームでは次のスケジュールで実行します。

# /etc/cron.d/zfs-auto-snapshot

PATH="/usr/bin:/bin:/usr/sbin:/sbin"

*/5 * * * * root /sbin/zfs-auto-snapshot -q -g --label=frequent --keep=24 //
00 * * * * root /sbin/zfs-auto-snapshot -q -g --label=hourly --keep=24 //
59 23 * * * root /sbin/zfs-auto-snapshot -q -g --label=daily --keep=14 //
59 23 * * 0 root /sbin/zfs-auto-snapshot -q -g --label=weekly --keep=4 //
00 00 1 * * root /sbin/zfs-auto-snapshot -q -g --label=monthly --keep=4 //

Syncoid（Sanoid） - https://github.com/jimsalterjrs/sanoid

このプログラムは、ZFSファイルシステムのセカンダリターゲットへのアドホックスナップ/レプリケーションを実行できます。製品のシンコイド部分のみを使用しています。

仮定すると、SERVER1とSERVER2を簡単なコマンドの実行がから、SERVER2にプルからデータをサーバー1：

#!/bin/bash

/usr/local/bin/syncoid root@server1:vol1/data vol2/data

exit $?

Monit - https: //mmonit.com/monit/

Monitは、非常に柔軟なジョブスケジューラおよび実行マネージャーです。デフォルトでは、30秒間隔で動作しますが、15秒のベースタイムサイクルを使用するように構成を変更します。

上記のレプリケーションスクリプトを15秒（1サイクル）ごとに実行する構成例

check program storagesync with path /usr/local/bin/run_storagesync.sh
        every 1 cycles
        if status != 0 then alert

これは、構成管理による自動化および追加が簡単です。Monitでスナップショット/レプリケーションの実行をラップすることにより、ステータス、ジョブ制御、アラート（電子メール、SNMP、カスタムスクリプト）を一元化できます。

その結果、複数月のスナップショットと、ロールバックと保持の多くのポイントを含むサーバーが次の場所にあります：https : //pastebin.com/zuNzgi0G-さらに、連続的なローリング15秒アトミックレプリカ：

# monit status

Program 'storagesync'
  status                            Status ok
  monitoring status                 Monitored
  last started                      Wed, 05 Apr 2017 05:37:59
  last exit value                   0
  data collected                    Wed, 05 Apr 2017 05:37:59
.
.
.
Program 'storagesync'
  status                            Status ok
  monitoring status                 Monitored
  last started                      Wed, 05 Apr 2017 05:38:59
  last exit value                   0
  data collected                    Wed, 05 Apr 2017 05:38:59

これを行うには、2つの異なる方法があります。

1. rsyncまたはのようなツールを使用して、過去数十年間使用されていた/使用されてきた従来のファイルシステムに依存しない方法Bacula。そこで、大規模な展開用にカスタマイズでき、ZFSから切り替えても使用できる、テスト済みの（できれば）安定した大規模なソフトウェアを用意しました。
2. ZFSを活用するツールの1つsend/recv。これは、独自のソリューション、Githubなどのさまざまなスクリプトまたは拡張スクリプト、またはSanoidやZnapZend（mbufferサポートと保持計画を含む送信/受信）などの機能豊富なツールのいずれかです。この場合、大きな「エンタープライズ」（ネガティブな意味で）ソリューションは見つかりませんが、単一のタスクを実行し、特定のセットアップに合わせて他のツールと組み合わせることができるツールは見つかりません。

一般的に、私はソースコードが利用可能なツールのみを信頼し、できるだけシンプルに保ちます。を使用する場合send/recv、あまり管理する必要はなく、リモート側でのスナップショットnの送信と確立が成功したときに、ローカル側でスナップショットn-1を削除するだけです。

ローカルの現在/新しいスナップショットとローカルの以前のスナップショット間で差分のみを送信できるという鉄則を守れば、トランスポートを好きなように分割することができ、非同期にすることもできます（スナップショットをすぐに受信する必要はありません） 、ローカルの以前のスナップショットはリモート側の最新のスナップショットであること（バックアップが完了してすべてがリセットされるまで）。

考えてみると、おそらくそれをステートマシンでエンコードして、予期しないケースがすり抜けることがないようにすることができます。