解決策 1:
rsync --ignore-existing --sparse ...
スパース モードで新しいファイルを作成するには
続いて
rsync --inplace ...
既存のすべてのファイル (以前に作成されたスパース ファイルを含む) をその場で更新します。
解決策 2:
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 と同等です。正確な動作については、マニュアル ページを参照してください。
解決策 3:
ddsnap 経由でバイナリ「rsync」を使用して「スナップショット」バックアップを実装する Zumastor Linux Storage Project を見てください。
マンページから:
ddsnap は、複数の同時スナップショットを効率的に保持できるブロック レベルのスナップショット機能を使用して、ブロック デバイスのレプリケーションを提供します。 ddsnap は、2 つのスナップショット間で異なるスナップショット チャンクのリストを生成し、その違いをネットワーク経由で送信できます。ダウンストリーム サーバーで、更新されたデータをスナップショット ブロック デバイスに書き込みます。
解決策 4:
これを行うためのソフトウェアを書くことになりました:
http://www.virtsync.com
これは、物理サーバーあたり 49 ドルの商用ソフトウェアです。
家庭用ブロードバンドで 3 分以内に 50 GB のスパース ファイル (3 GB のコンテンツを含む) を複製できるようになりました。
[email protected]:~$ 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
解決策 5:
巨大なファイルまたはブロックデバイスを低から中程度の違いで同期するには、プレーンコピーを実行するか、bdsync を使用できます。rsync はこの特定のケースには絶対に適していません*。
bdsync 私のために働いた、十分に成熟しているように見える、それはバグの歴史が励みになります（小さな問題、迅速な解決）。私のテストでは、速度は理論上の最大値に近くなりました** (つまり、ファイルを読み取るのに必要な時間で同期できます)。最後に、これはオープン ソースであり、費用はかかりません。
bdsync 両方のホストからファイルを読み取り、チェックサムを交換してそれらを比較し、違いを検出します。これらすべてを同時に .最後に、ソース ホストに圧縮されたパッチ ファイルが作成されます。次に、そのファイルを宛先ホストに移動し、bdsync をもう一度実行して、宛先ファイルにパッチを適用します。
かなり高速なリンク (例:100Mbit イーサネット) を介して使用し、ファイルの違いが小さい場合 (VM ディスクで最もよくあるケース)、同期にかかる時間をファイルの読み取りに必要な時間に短縮します。低速のリンクでは、圧縮された変更をあるホストから別のホストにコピーする必要があるため、もう少し時間が必要です (いいトリックを使って時間を節約できるようですが、まだテストしていません)。多くの変更を含むファイルの場合、パッチ ファイルをディスクに書き込む時間も考慮する必要があります (また、両方のホストにそれを保持するのに十分な空き容量が必要です)。
私が通常bdsyncを使用する方法は次のとおりです。これらのコマンドは $LOCAL_HOST で実行されます $LOCAL_FILEを「コピー」する $REMOTE_FILE まで $REMOTE_HOST で . pigz を使用しています (より高速な gzip ) 変更を圧縮するには ssh リモートホストと rsync で bdsync を実行する /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 に詳細が記載されています)。