信頼性の低い低速のWANを介したZFS同期。ZFSレプリケーション、またはrsync？

私はWANを介してオフサイトのバックアップ作業を行う任務を負っています。どちらのストレージボックスも、ZFSを実行するFreeBSDベースのNASボックスです。

週に1〜2回、15〜60ギガの写真データがオフィスのNASにダンプされます。私の仕事は、非常に遅いDSL接続（約700Kb / sのアップロード）を使用して、このデータを可能な限り確実にオフサイトで取得する方法を理解することです。受信ボックスは、30Mb / sダウン、5Mb / sアップで、はるかに良い形になっています。

ハードドライブをオフサイトに持ち運ぶと、データの移動がはるかに速くなることはわかっていますが、この場合はオプションではありません。

私のオプションは次のいずれかです：

• ZFS経由のZFS増分送信
• Rsync

rsyncは昔からのソリューションであり、何かが中断された場合に送信を再開する非常に重要な機能を備えています。多くのファイルを反復処理し、重複除去について知らないという欠点があります。

ZFSスナップショットの送信では、転送されるデータが少し少なくなる可能性があり（ファイルシステムについて多くのことを理解し、重複排除を実行でき、メタデータの変更をrsyncよりも効率的にパッケージ化できます）、単にコピーするのではなく、ファイルシステムの状態を適切に複製できるという利点があります個々のファイル（ディスクをより集中的に使用します）。

ZFSレプリケーションのパフォーマンスが心配です[1]（その記事は1年前のものです）。何かがダウンした場合に転送を再開できるかどうかも心配です。スナップショット機能にはそれが含まれていないようです。システム全体が完全にハンドオフである必要があります。

[1] http://wikitech-static.wikimedia.org/articles/z/f/s/Zfs_replication.html

どちらのオプションを使用しても、指定したポートを介してルーティングし、ルーターでQOSを使用することにより、トラフィックの優先順位を下げることができます。転送には数日かかるので、各転送中に両方のサイトのユーザーに大きな悪影響を与えないようにする必要があります。

だから...それは問題についての私の考えです。良いオプションを見逃しましたか？他の誰かが似たようなものを設定しましたか？

1. 1日あたり最大6GBを転送でき（オーバーヘッドがゼロで競合トラフィックがゼロであると想定）、「週に1回または2回」の頻度で「15-60ギグ」を移動する必要がある場合、15-120になります。 1週間あたりのGB、または1日あたり2〜17 GB。ピーク需要を計画する必要があるため、17 GBは理論上の最大値である6 GBをはるかに超えているため、非常に深刻な帯域幅の問題が発生している可能性があります。接続をアップグレードするには何が必要ですか？接続のアップグレードが不可能な場合は、物理メディアを定期的（例、毎週）に郵送するオプションを検討してください。

2. 帯域幅の計算をもう少し理解できると仮定すると、rsyncがおそらく最良のオプションです。重複排除の認識は、非常に冗長なデータ（仮想マシンイメージなど）を複製するときに非常に価値がありますが、ユニークなデジタルコンテンツ（オーディオ、ビデオ、写真）に関しては、ほとんどまたはまったくメリットがありません...もちろん、ユーザーが同一ファイルの重複コピーをうっかり保存する。

いくつかの調査を行った後、私はあなたがスナップショットを送信することについて正しいと信じています。ZFS SENDとRECEIVEコマンドをbzip2にパイプして、そのファイルを他のマシンにrsyncすることができます。

ここに私が使用したいくつかの情報源があります：

• 『Oracle Solaris ZFS管理者ガイド』の211ページ（またはここの Webバージョン）では、これについて話し始めています。

• また、この簡単な例を紹介するブログ投稿も見つけました。 このブログでは、ビットストリームをbzip2にパイプして送信する方法も示しました。

レプリケーションスクリプトが投稿された投稿は見つかりませんでしたが、バックアップスクリプトを投稿した人は見つかりました。とはいえ、理解できなかったのでジャンクかもしれません。

ウェブサイトの多くは、これを頻繁に行うためのcronジョブの設定について話しました。これが事実である場合、オフサイトデータがより最新であるため、帯域幅とユーザーへの影響が少ない複製/バックアップを作成でき、優れた障害復旧機能になる可能性があります。（つまり、開始時のデータの最初のチャンクの後。）

繰り返しますが、スナップショットを送信するという正しい考えがあったと思いますが、SEND/ を使用することには多くの利点があるようRECEIVEです。

編集：だけを見VIDEO1 VIDEO2のかもしれないが、使用suportsは役立つことSEND/ RECEIVErsyncの程度と会談（3m49sで開始します）。ベンロックウッドが講演者であり、ここに彼のブログへのリンクがあります。

バックアップの目的は何ですか？また、バックアップにどのようにアクセスする必要がありますか？

バックアップが主に災害復旧用である場合、ファイルシステムを最後の増分時の状態に正確に戻すことができるため、ZFSスナップショットが望ましい場合があります。

ただし、バックアップがユーザーに誤って削除、破損などされた可能性のあるファイルへのアクセスを提供することになっている場合は、rsyncがより良いオプションになる可能性があります。エンドユーザーはスナップショットの概念を理解していないか、NASがエンドユーザーに以前のスナップショットへのアクセスを提供していない可能性があります。どちらの場合でも、rsyncを使用して、ファイルシステム経由でユーザーが簡単にアクセスできるバックアップを提供できます。

rsyncを使用すると、-backupフラグを使用して、変更されたファイルのバックアップを保持できます。--suffixフラグを使用すると、古いバージョンのファイルの名前を変更する方法を制御できます。これにより、次のような古いバージョンのファイルに日付を付けた可能性があるバックアップを簡単に作成できます

file_1.jpg
file_1.jpg.20101012
file_1.jpg.20101008
etc.

これをfindコマンドを含むcronjobと簡単に組み合わせて、必要に応じて古いファイルを削除できます。

どちらのソリューションでも、バックアップとして機能するのに十分なファイルに関するメタ情報を保持できる必要があります（rsyncは--perms、-ownerなどのフラグを提供します）。私はデータセンター間で大量のデータをバックアップするためにrsyncを使用しており、セットアップに非常に満足しています。

ZFSは「再開可能な送信」機能を受信する必要があります。これにより、今年の3月頃に中断されたレプリケーションを継続できるようになります。この機能はMatt Ahrensと他の何人かによって完成されており、すぐにアップストリームされるはずです。

たぶんWAN圧縮デバイスが解決策となるでしょうか...？Riverbedを使用しており、非常に満足しています（たとえば、NetApp SnapMirrorは80-90％まで非常によく圧縮されています）