私はWANを介してオフサイトのバックアップ作業を行う任務を負っています。両方のストレージボックスはFreeBSDベースですNAS ZFSを実行するボックス。
週に1〜2回、15〜60 GBの写真データがオフィスのNASにダンプされます。私の仕事は、非常に低速のDSL接続(約700Kb/sのアップロード)を使用して、このデータを可能な限り確実にオフサイトで取得する方法を見つけることです。受信ボックスは、30Mb/sダウン、5Mb/sアップで、はるかに良い形になっています。
ハードドライブをオフサイトに持ち運ぶと、データの移動がはるかに速くなりますが、この場合はオプションではありません。
私のオプションは次のいずれかです:
rsyncは古くからあるソリューションであり、何かが中断された場合に送信を再開する非常に重要な機能を備えています。多くのファイルを繰り返し処理し、重複除去について知らないという欠点があります。
ZFSスナップショットの送信では、転送するデータが少し少なくなる可能性があり(ファイルシステムについて多くのことを理解し、重複排除を実行でき、メタデータの変更をrsyncよりも効率的にパッケージ化できます)、単にコピーするのではなく、ファイルシステムの状態を適切に複製できるという利点があります個別にファイル(ディスクをより集中的に使用します)。
ZFSレプリケーションのパフォーマンスが心配です[1](その記事は1年前のものです)。また、何かがダウンした場合に転送を再開できるかどうかも心配です。スナップショット機能にはそれが含まれていないようです。システム全体が完全にハンドオフである必要があります。
[1] http://wikitech-static.wikimedia.org/articles/z/f/s/Zfs_replication.html
どちらのオプションを使用しても、指定したポートを介してルーティングし、ルーターでQOSを使用することで、トラフィックの優先順位を下げることができます。転送には数日かかるため、各転送中に両方のサイトのユーザーに大きな悪影響を与えないようにする必要があります。
だから...それは問題についての私の考えです。良いオプションを見逃しましたか?他の誰かが似たようなものを設定しましたか?
1日あたり最大6GBを転送でき(オーバーヘッドがゼロで競合トラフィックがゼロであると想定)、「週に1回または2回」の頻度で「15-60ギグ」を移動する必要がある場合、15-120になります。 1週間あたりのGB、または1日あたり2〜17 GB。ピーク時の需要を計画する必要があるため、17 GBは理論的な最大6 GBをはるかに超えているため、非常に深刻な帯域幅の問題。接続をアップグレードするには何が必要ですか?接続のアップグレードが不可能な場合は、定期的に物理メディアを郵送するオプションを検討してください(例:毎週)。
帯域幅の計算でもう少し理にかなっていると仮定すると、rsyncがおそらく最良のオプションです。重複排除の認識は、冗長性の高いデータ(仮想マシンイメージなど)を複製するときに非常に価値がありますが、ユニークなデジタルコンテンツ(オーディオ、ビデオ、写真)に関しては、ほとんどまたはまったくメリットがありません...もちろん、ユーザーが同一ファイルの重複コピーをうっかり保存してしまう。
いくつかの調査を行った後、私はあなたがスナップショットを送信することについて正しいと信じています。 ZFSのSEND
およびRECEIVE
コマンドをbzip2にパイプして、そのファイルを他のマシンにrsyncすることができます。
ここに私が使用したいくつかの情報源があります:
Oracle Solaris ZFS管理者ガイド 211ページ(またはWebバージョン ここ )がこれについて話し始めます。
また、この簡単な例を示す ブログ投稿 も見つけました。 このブログ は、ビットストリームをbzip2にパイプして送信することも示しました。
レプリケーションスクリプトが投稿されている投稿は見つかりませんでしたが、 バックアップスクリプト を投稿した人を見つけました。とはいえ、理解できなかったのでジャンクかもしれません。
ウェブサイトの多くは、これを頻繁に行うためのcronジョブの設定について話しました。これが事実である場合、オフサイトデータの方が最新であるため、帯域幅とユーザーへの影響が少ない複製/バックアップを作成でき、優れた障害復旧機能になります。 (つまり、開始時のデータの最初のチャンクの後。)
繰り返しますが、スナップショットを送信するという正しい考えがあったと思いますが、SEND
/RECEIVE
を使用することには多くの利点があるようです。
EDIT:視聴しただけ video1video2SEND
/RECEIVE
およびrsyncについて話します(3分49秒から開始)。ベンロックウッドが講演者であり、ここに彼の blog へのリンクがあります。
ZFSは「再開可能な送信」機能を受信する必要があります。これにより、今年の3月頃にレプリケーションの中断を継続できるようになります。この機能はMatt Ahrensと他の何人かによって完成されており、すぐにアップストリームされるはずです。
バックアップの目的は何ですか?また、バックアップにどのようにアクセスする必要がありますか?
バックアップが主に災害復旧用である場合、ファイルシステムを最後の増分時の状態に正確に戻すことができるため、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を使用しており、セットアップに非常に満足しています。
多分WAN圧縮デバイスが解決策となるでしょうか...?私たちはRiverbedを使用しており、非常に満足しています(たとえば、NetApp SnapMirrorは80-90%まで非常によく圧縮されています)