VMの効率的なオフサイトリモートバックアップソリューションの推奨事項
現在の6つのVMをバックアップするための推奨事項を探しています（間もなく最大20に増加します）。現在、私は2ノードのproxmoxクラスターを実行しています（これは、管理用のカスタムWebフロントエンドを使用した仮想化にkvmを使用するdebianベースです）。 AMD phenom IIx4とasusマザーボードを備えたほぼ同じボックスが2つあります。それぞれに4つの500 GB sata2 hddがあり、1つはosおよびproxmoxインストール用の他のデータ用で、3つはmdadm + drbd + lvmを使用して2つのマシン間で1.5 TBのストレージを共有します。すべての仮想マシンのlvmイメージをkvmにマウントします。私は現在、あるマシンから別のマシンへ、通常は数秒以内にライブ転送を行うことができます（m $ sqlサーバーでwin2008を実行している最大のVMでは約2分かかります）。私はproxmoxの組み込みvzdumpユーティリティを使用して、VMのスナップショットを作成し、それらをネットワーク上の外部ハードドライブに保存しています。次に、リモートオフサイトバックアップ用にvzdumpフォルダーを同期するjunglediskサービス（rackspaceを使用）があります。
これはすべて問題なく、順調ですが、それほどスケーラブルではありません。まず、バックアップ自体は毎晩数時間かかることがあります。 junglediskのブロックレベルの増分転送では、同期はデータのごく一部をオフサイトに転送するだけですが、それでも少なくとも30分かかります。
もちろん、はるかに優れたソリューションは、2つの時点（午前6時から午前7時までに書き込まれたものなど）の差を即座に取得し、それを圧縮して、その差ファイルをバックアップサーバーに送信し、バックアップサーバーに即座に転送できるようにすることです。ラックスペース上のリモートストレージ。私はzfsを少し調べましたが、送信/受信を行う機能です。それをbzipなどのデータのパイプと組み合わせると完璧に思えます。ただし、zfsを使用してnexentaサーバーを実装するには、iSCSIブロックボリュームを（zvolを介して????）proxmoxサーバーに提供するために、少なくとも1つまたは2つ以上の専用ストレージサーバーが必要になるようです。可能な限り、最小限の設定（つまり、個別のストレージサーバーを持たない）を維持したいと思います。
Zumastorについても簡単に読みました。私のやりたいこともできるようですが、2008年に開発が止まったようです。
それで、zfs、zumastorまたは他？
私の質問に対する究極の答えを見つけたかもしれません：
BUP https://github.com/bup/bup
特徴：
（rsyncに類似した）ローリングチェックサムアルゴリズムを使用して、大きなファイルをチャンクに分割します。この最も便利な結果は、巨大な仮想マシン（VM）のディスクイメージ、データベース、およびXMLファイルを段階的にバックアップできることです。
Git（オープンソースバージョン管理システム）のpackfile形式を使用しているため、bupのユーザーインターフェイスが気に入らなくても、保存されているデータにアクセスできます。
Gitとは異なり、（個別のガベージコレクション/再パック段階を持たずに）パックファイルを直接書き込むため、不必要に大量のデータがあっても高速です。 bupの改善されたインデックス形式では、git（百万）よりもはるかに多くのファイル名を追跡し、はるかに多くのオブジェクト（数百または数千ギガバイト）を追跡することもできます。
お互いを知らない2つの異なるコンピューターからバックアップが作成された場合でも、どのバックアップが他のバックアップに基づいているかを知る必要なく、データは増分バックアップ間で「自動的に」共有されます。 bupにデータをバックアップするように指示するだけで、必要なデータの最小量のみが保存されます。
バックアップするコンピューターに大量の一時ディスク領域を必要とせずに、リモートbupサーバーに直接バックアップできます。また、バックアップが途中で中断された場合、次の実行は中断したところから再開されます。また、bupサーバーのセットアップは簡単です。sshにアクセスできる任意のマシンにbupをインストールするだけです。
Bupは、「par2」冗長性を使用して、ディスクに不良セクターが検出されていない場合でも、破損したバックアップを復元できます。
バックアップが増分の場合でも、完全バックアップの復元について心配する必要はありません。その後、各増分を順番に復元します。増分バックアップは、完全バックアップのように機能し、必要なディスク容量が少なくなります。
BupリポジトリをFuseファイルシステムとしてマウントし、その方法でコンテンツにアクセスし、Samba経由でエクスポートすることもできます。
編集：（2015年8月19日）そして、さらに優れたさらに別の優れたソリューションが出てきました： https://github.com/datto/dattobd
ライブスナップショットを可能にし、Linuxの通常の古いファイルシステムにCOWのような機能を提供します。
編集：（2016年7月15日）そして、水からバップを吹き飛ばすさらに別の素晴らしいソリューション： https://github.com/borgbackup/borg
剪定でのバップよりも特に優れています。圧縮、暗号化、および効率的な重複排除を強力にサポートしているようです。 dattobd + borg ftw !!!
これはあなたの状況では不可能かもしれないので、その場合は反対票を投じないことを望みますが、バックアップ戦略を変更する方が効率的かもしれません。 VMスナップショットの代わりに特定のデータをバックアップすると、バックアップの実行速度が大幅に向上し、変更のキャプチャが容易になります。
VMとその使用目的に応じて、スナップショットを毎日保存する場所（または適切なスケジュール）にデータをバックアップするだけで、JungleDiskはデータのみをバックアップできます。これにより、変更されたファイルがより効率的に転送され、バックアップに必要なスペースと必要な時間が削減されます。さらに、スナップショットを取得して保持することもできますが、その頻度ははるかに少なくなります（たとえば、毎週）。
この場合、常に新しいVM=を起動してデータを復元するか、古いスナップショットを使用してVMを復元してから、データバックアップを使用して最新のポイントに復元することができます。
スケーラビリティを向上させるために計画していたアーキテクチャの変更がどれほどかはわかりません。ただし、VMプラットフォームの切り替えを受け入れる場合は、VMWareを使用できます。
良いVMWareバックアップソリューションはたくさんありますが、私は個人的にVzionCoreを使用しました。その後、スナップショットとポイントインタイムリカバリを使用して、滑らかな処理を実行できます。リモートサイトにフェイルオーバーする機能もあります。
backuppcを確認することをお勧めします。
backuppcは、増分コピーを行うrsyncの上で動作できます。
さらに、バックアップする必要のないフォルダのブラックリストを簡単に作成できます。例：temp// tmp .garbages /.。
http://backuppc.sourceforge.net/
backuppcにはクリーンなWebインターフェイスがあり、バックアップの一部をZipファイルとして直接ダウンロードできます。 check_backuppcを使用してnagiosで監視できます。
オフサイトバックアップを行っている場合、次のオプションを選択します。
（a）リモートサーバーにSCPコピーを実行するシェルスクリプト。このようにして、バックアップを作成するスクリプトを自動的に実行するcronジョブを追加できます。さらに、実際にファイルを転送する前に一時的なアーカイブファイルを作成し、敷居のgzip中に転送しないことで帯域幅を節約できるようにすることもできます。
または
（b）Webminなどのサーバー管理ツールをインストールし、自動バックアップを実行できるようにします。私は現在、これを私の運用サーバーで問題なく歌っています。問題なく動作します。また、オールインワンソリューションを提供するため、多くのVMの管理にはcloudmin（有料）をお勧めします。
いくつかの追加リンク：
http://www.debianhelp.co.uk/backup.htm
http://ubuntuforums.org/showthread.php?t=35087
お役に立てば幸いです、RayQuang
私は大規模なproxmoxクラスターを実行しており、組み込みのvzdumpスナップショットスタイルのバックアップからバックアップ戦略を変更することを提案する必要があります。
多くの「ゲスト内」ファイルバックアップソリューションを検討してください。 Backuppc、Urbackup、bacula、amandaなど...
それははるかに速くなり、はるかに少ないスペースを消費し、特定のファイルを復元するのがはるかに簡単になります。
zfsはそれをうまく行いますが、2サーバースケールではうまく機能しないことのマイナス面はすでに知っています。また、DRDBフェイルオーバーを提供することもありません。つまり、Nexentaが単一障害点になります。
OpenSolarisまたはNexentaCoreでVirtualBoxを入手することを検討できますが、ProxMox + DRDBほど単純ではないため、既存のマシンを再利用できます。
変更を測定して十分に低いことがわかった場合は、オフサイトの3番目のミラーでDRDBを試すことができます-VMでの書き込み数が極端に少ない場合にのみ機能します。
Steve Radich-1995年以降のWindowsホスティングとSQLパフォーマンス- http://www.BitShop.com/Blogs.aspx