マシン間で巨大なスパースファイル（VMディスクイメージ）をどのように同期しますか？
あるLinuxサーバーから別のLinuxサーバーに巨大なまばらなファイルを同期できるrsyncなどのコマンドはありますか？
宛先ファイルがまばらであることが非常に重要です。それが含まれているドライブよりも長い場合があります（ただし大きくはありません）。変更されたブロックのみをネットワーク経由で送信する必要があります。
私はrsyncを試しましたが、喜びがありませんでした。 https://groups.google.com/forum/#!topic/mailing.unix.rsync/lPOScZgFE9M
これを行うプログラムを作成した場合、ホイールを再発明するだけですか？ http://www.finalcog.com/synchronise-block-devices
おかげで、
クリス。
これを行うためのソフトウェアを作成することになりました。
これは、物理サーバー1台あたり49ドルの商用ソフトウェアです。
これで、住宅用ブロードバンド全体で3分未満で50 GBのスパースファイル（コンテンツは3 GB）を複製できます。
chris@server:~$ time virtsync -v /var/lib/libvirt/images/vsws.img backup.barricane.com:/home/chris/
syncing /var/lib/libvirt/images/vsws.img to backup.barricane.com:/home/chris/vsws.img (dot = 1 GiB)
[........>.........................................]
done - 53687091200 bytes compared, 4096 bytes transferred.
real 2m47.201s
user 0m48.821s
sys 0m43.915s
rsync --ignore-existing --sparse ...
疎モードで新しいファイルを作成するには
に続く
rsync --inplace ...
すべての既存のファイル（以前に作成されたスパースファイルを含む）をインプレースで更新します。
Rsyncは各ファイルへの変更のみを転送し、-inplaceを使用すると、ファイルを再作成せずに変更されたブロックのみを書き換えます。 機能ページ から。
rsyncは、Unixシステム用のファイル転送プログラムです。 rsyncは、リモートファイルを同期させるための非常に高速な方法を提供する「rsyncアルゴリズム」を使用します。これは、両方のファイルセットがリンクの一方の端に事前に存在していることを必要とせずに、リンクを介してファイルの違いのみを送信することによって行われます。
--inplaceを使用するとうまくいくはずです。これは、進行状況を示し、転送を圧縮し（デフォルトの圧縮レベルで）、ローカルストレージディレクトリの内容を再帰的に転送し（最初のスラッシュが重要です）、所定の場所にあるファイルに変更を加え、トランスポートにsshを使用します。
rsync -v -z -r --inplace --progress -e ssh /path/to/local/storage/ \
[email protected]:/path/to/remote/storage/
私はしばしば-aフラグも使用します。これはさらにいくつかのことを行います。 -rlptgoDと同じです。正確な動作は、マニュアルページで確認できるようにしておきます。
Zumastor Linux Storage Project を見てください。これは、ddsnapツールを介してバイナリ「rsync」を使用した「スナップショット」バックアップを実装しています。
マンページから：
ddsnapは、複数の同時スナップショットを効率的に保持できるブロックレベルのスナップショット機能を備えたブロックデバイスレプリケーションを提供します。 ddsnapは、2つのスナップショット間で異なるスナップショットチャンクのリストを生成し、その違いをネットワーク経由で送信できます。ダウンストリームサーバーで、更新されたデータをスナップショットブロックデバイスに書き込みます。
大きなファイルまたはブロックデバイスを低から中程度の差で同期するには、プレーンコピーを実行するか、 bdsync を使用します。rsyncはこの特定のケースに完全に適合しません*。
bdsyncはうまくいきました。十分に成熟しているようです。バグの履歴は有望です（小さな問題、迅速な解決）。私のテストでは、その速度は理論的に得られる最大値に近かった**（つまり、ファイルの読み取りに必要な時間に同期することができます）。最後に、それはオープンソースであり、費用はかかりません。
bdsyncは両方のホストからファイルを読み取り、チェックサムを交換してそれらを比較し、違いを検出します。これらすべて同時に。最後に、ソースホスト上に圧縮パッチファイルを作成します。次に、そのファイルを宛先ホストに移動し、bdsyncをもう一度実行して宛先ファイルにパッチを適用します。
かなり高速のリンク（100Mbitイーサネットなど）で使用し、差異が小さいファイル（ほとんどの場合VMディスク）の場合）を使用すると、同期に必要な時間に同期する時間が短縮されますファイルを読み取るには、低速リンクを使用します。圧縮された変更を1つのホストから別のホストにコピーする必要があるため、もう少し時間が必要です（ 素敵なトリック を使用して時間を節約できるようですが、多くの変更が加えられたファイルの場合、パッチファイルをディスクに書き込む時間も考慮する必要があります（両方のホストにそれを保持するのに十分な空き領域が必要です）。
これが私が通常bdsyncを使用する方法です。これらのコマンドは、$LOCAL_Hostで$LOCAL_FILEを$REMOTE_FILEから$REMOTE_Hostに「コピー」して実行します。 pigz（より高速なgzip）を使用して変更を圧縮し、sshを使用してリモートホストでbdsyncを実行し、rsync/ssh変更をコピーします。パッチが正常に適用されているかどうかを確認していますが、「正常に更新されました」と表示されるのは、その場合のみです。失敗した場合に備えて、さらにレベルを上げることができます。
REMOTE_Host=1.2.3.4
LOCAL_FILE=/path/to/source/file
REMOTE_FILE=/path/to/destination/file
PATCH=a_file_name
LOC_TMPDIR=/tmp/
REM_TMPDIR=/tmp/
# if you do use /tmp/ make sure it fits large patch files
# find changes and create a compressed patch file
bdsync "ssh $REMOTE_Host bdsync --server" "$LOCAL_FILE" "$REMOTE_FILE" --diffsize=resize | pigz > "$LOC_TMPDIR/$PATCH"
# move patch file to remote Host
rsync "$LOC_TMPDIR/$PATCH" $REMOTE_Host:$REM_TMPDIR/$PATCH
# apply patch to remote file
(
ssh -T $REMOTE_Host <<ENDSSH
pigz -d < $REM_TMPDIR/$PATCH | bdsync --patch="$REMOTE_FILE" --diffsize=resize && echo "ALL-DONE"
rm $REM_TMPDIR/$PATCH
ENDSSH
) | grep -q "ALL-DONE" && echo "Update succesful" && rm "$LOC_TMPDIR/$PATCH"
# (optional) update remote file timestamp to match local file
MTIME=`stat "$LOCAL_$FILE" -c %Y`
ssh $REMOTE_Host touch -c -d @"$MTIME_0" "$REMOTE_FILE" </dev/null
*：rsyncは巨大なファイルでは非常に非効率的です。 --inplaceを使用した場合でも、最初に宛先ホストのファイル全体を読み取ります。その後、ソースホストのファイルの読み取りを開始し、最後に差分を転送します（rsyncの実行中にdstatなどを実行して監視します）。その結果、わずかな違いのあるファイルでも、同期するためにファイルを読み取るのに必要な時間の約2倍の時間がかかります。
**：ファイルのどの部分が変更されたかを知る方法が他にないという前提の下で。 LVMスナップショットは、ビットマップを使用して変更されたブロックを記録するため、非常に高速になります（ lvmsync のreadmeに詳細が記載されています）。
lvmsync はこれを行います。
これは使用法のトランスクリプトです 。ソース上にLVMスナップショットを作成し、論理パーティションを転送します。スナップショットの作成以降、変更の増分更新を何度でも転送できます。
ファイルシステム全体を複製することは解決策になるでしょうか？ DRBD？ http://www.drbd.org/
ここで少し奇妙かもしれませんが、最近、NFSがこれをうまく処理できることを知りました。
したがって、1つのマシンでディレクトリをエクスポートしてから、それを別のマシンにマウントし、cpのような基本的なユーティリティでファイルをコピーするだけです。 （古い/古代のユーティリティの中には、スパースファイルで問題が発生するものがあります。）
スパースファイルの転送では、rsyncが特に非効率的であることがわかりました。
私はそのようなユーティリティを認識しておらず、それを処理できるシステムコールについてのみ認識しています。そのため、このようなユーティリティを作成する場合は、かなり役立つかもしれません。
あなたが実際にできることはqemu-img変換を使用してファイルをコピーすることですが、それは宛先FSがスパースファイルをサポートしている場合にのみ機能します