Řešení 1:
rsync --ignore-existing --sparse ...
Vytvoření nových souborů v řídkém režimu
Následuje
rsync --inplace ...
Aktualizace všech existujících souborů (včetně dříve vytvořených řídkých) na místě.
Řešení 2:
Rsync pouze přenese změny do každého souboru a s --inplace by měl přepsat pouze bloky, které se změnily, aniž by byl soubor znovu vytvořen. Na stránce funkcí.
rsync je program pro přenos souborů pro systémy Unix. rsync používá „algoritmus rsync“, který poskytuje velmi rychlou metodu pro synchronizaci vzdálených souborů. Dělá to tak, že přes odkaz posílá pouze rozdíly v souborech, aniž by bylo nutné, aby byly na jednom z konců odkazu předem přítomny obě sady souborů.
Použití --inplace by vám mělo fungovat. Zobrazí se vám průběh, komprimace přenosu (na výchozí úrovni komprese), rekurzivní přenos obsahu adresáře místního úložiště (záleží na prvním koncovém lomítku), provedení změn v souborech a použití ssh pro přenos.
rsync -v -z -r --inplace --progress -e ssh /path/to/local/storage/ \
[email protected]:/path/to/remote/storage/
Často také používám příznak -a, který dělá několik dalších věcí. Je to ekvivalent -rlptgoD. Přesné chování nechám na vás, abyste se podívali na manuálovou stránku.
Řešení 3:
Podívejte se na Zumastor Linux Storage Project, který implementuje zálohování „snímek“ pomocí binárního „rsync“ přes ddsnap nástroj.
Z manuálové stránky:
ddsnap poskytuje replikaci blokového zařízení díky možnosti vytváření snímků na úrovni bloku, která je schopna efektivně uchovávat více současných snímků. ddsnap dokáže vygenerovat seznam bloků snímků, které se mezi dvěma snímky liší, a poté tento rozdíl odeslat po drátě. Na následném serveru zapište aktualizovaná data do blokového zařízení se snímkem.
Řešení 4:
Nakonec jsem napsal software, který to udělá:
http://www.virtsync.com
Jedná se o komerční software, který stojí 49 USD za fyzický server.
Nyní mohu replikovat 50GB řídký soubor (který má 3 GB obsahu) za méně než 3 minuty přes domácí širokopásmové připojení.
[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
Řešení 5:
Chcete-li synchronizovat velké soubory nebo bloková zařízení s malými až středními rozdíly, můžete buď vytvořit obyčejnou kopii, nebo použít bdsync, rsync se pro tento konkrétní případ absolutně nehodí*.
bdsync fungoval pro mě, zdá se dostatečně vyspělý, historie chyb je povzbudivá (malé problémy, rychlé řešení). V mých testech se jeho rychlost blížila teoretickému maximu, které jste mohli získat** (to znamená, že se můžete synchronizovat přibližně za čas, který potřebujete ke čtení souboru). Konečně je to open source a nic nestojí.
bdsync čte soubory z obou hostitelů a vyměňuje kontrolní součty, aby je porovnal a zjistil rozdíly. To vše současně . Nakonec vytvoří komprimovaný soubor opravy na zdrojovém hostiteli. Potom tento soubor přesunete do cílového hostitele a spustíte bdsync podruhé, abyste opravili cílový soubor.
Při použití přes poměrně rychlou linku (např. 100Mbit Ethernet) a pro soubory s malými rozdíly (jak je tomu nejčastěji na discích VM) zkracuje čas synchronizace na čas, který potřebujete k načtení souboru. Přes pomalý odkaz potřebujete trochu více času, protože musíte kopírovat komprimované změny z jednoho hostitele na druhého (zdá se, že můžete ušetřit čas pomocí pěkného triku, ale nezkoušeli jsme). U souborů s mnoha změnami by se měl vzít v úvahu také čas potřebný k zápisu záplatového souboru na disk (a pro jeho uložení potřebujete dostatek volného místa na obou hostitelích).
Zde je návod, jak obvykle používám bdsync. Tyto příkazy se spouštějí na $LOCAL_HOST "zkopírovat" $LOCAL_FILE až $REMOTE_FILE na $REMOTE_HOST . Používám pigz (rychlejší gzip ) pro komprimaci změn ssh ke spuštění bdsync na vzdáleném hostiteli a rsync /ssh zkopírovat změny. Všimněte si, že kontroluji, zda byla oprava úspěšně aplikována, ale vytisknu pouze „Aktualizace úspěšná“, když se tak stane. Možná budete chtít udělat něco více clevel v případě selhání.
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 je velmi neefektivní s velkými soubory. I s --inplace nejprve přečte celý soubor na cílovém hostiteli, POTOM začne číst soubor na zdrojovém hostiteli a nakonec přenese rozdíly (stačí spustit dstat nebo podobný při spuštění rsync a pozorovat). Výsledkem je, že i u souborů s malými rozdíly to trvá přibližně dvojnásobek času, který potřebujete k načtení souboru, aby se mohl synchronizovat.
**:Za předpokladu, že nemáte žádný jiný způsob, jak zjistit, které části souborů se změnily. Snímky LVM používají bitmapy k zaznamenání změněných bloků, takže mohou být extrémně rychlejší (více informací obsahuje readme lvmsync).