Rsync - hogyan is?

UNIX haladó

Sziasztok!

Első körben elvi szinten kérdeznélek titeket, mire is jó az rsync?
Meg nem mondom, hogy hol, de szerintem több helyen is hallottam/olvastam azt, hogy csak a "változást viszi át".
Rosszul értelmezem ezt, amikor arra gondolok, ha van egy 100MB-os fájlom, melyben megváltozik 4 byte, akkor csak a 4 byte változás megy át? Feltételezve persze, hogy már "odaát" van az egyel régebbi változata az adott fájlnak.

Egyszer próbálkoztam ezzel, Windows alatt, de már nincs meg a gép, pontos emlékek sincsenek. Ott egyik partícióról a másikra játszottam egy CD ISO fájllal, rsync-kel áttoltam a "túloldalra", belenyúltam notepad-dal, átírtam benne egy-két bájtot, majd újra ráengedtem az rsyncet. Néhány mp. alatt végzett, nem vitte át újra a CD-nyi méretet.
Most viszont sehogy sem tudom ezt reprodukálni.
Tény, hogy nem ISO fájlba nyúltam msot bele. Van két rar fájlom, ugyanaz a nevük, egyikben egyel több állomány van. Ezeket másolgattam felváltva egy forrás könyvtárba, majd engedtem rá az rsync-et, ami szinkronizálta a cél partíción levő könyvtárba. Mindig átmásolta a teljes fájlt, ha cseréltem.

Amúgy tgz fájlok szinkronizálásához kellene a dolog. Egy-egy ilyen állomány lehet 2...10GB, a benne levő változás pedig általában néhány kb-nyi. Így gondolom értitek, miért szeretném, ha csak a változás menne át, nem pedig minden alkalommal 10GB.

Szóval mit tudtok erről a dologról, tudna ilyet az rsync?

  • 7241 megtekintés

( mauzi v | 2011. 01. 29., szo – 18:18 )

az rsync (rdiff) delta algoritmusa nagy valószínűséggel észreveszi, ha egy fájlban módosítasz pár bájtot/kilobájtot, és akkor elég csak a differenciát átmásolni.

egy tar/gzip/rar fájlnak azonban kb. semmi köze sem lesz az eredetihez, ha módosítasz a tartalmán...

( log69 | 2011. 01. 29., szo – 22:10 )

.tgz-khez pont jó, először tar-t kell csinálnod, utána gzip-et ráereszteni, de --rsyncable kapcsolóval.

ezen kívül ahogy előttem is írták, más tömörített anyagot már hiába hasonlítja, ott mindig át fogja tolni az egészet.

báze, van ilyen opciója a gzipnek? hogy miket nem tud a tudomány manapság :)
(kb. akkor néztem meg először és utoljára a gzip manualját, amikor elkezdtem rá átszokni UNIX compress-ről, kb. 15 évvel ezelőtt :P )

akkor most már csak a pigz-nek kéne implementálni ezt az opciót...

( Mono v | 2011. 01. 31., h – 16:07 )

Nagyon köszönöm mindenkinek, megoldottam. Log69 írta le a lényeget, --rsyncable kapcsolóval érdekes, működik a dolog.
Eddig egy parancs által készült a tgz, most további kettőre van szükség, viszont szépen megeszi az rsync, azt csinálja amit kell, csak ajánlani tudom minden erre tévedőnek!

Érdekes amúgy, Debian Lenny az op.rendszer, manjában egy szó nem esik erről a kapcsolóról. Sőt, ha elgépelem, nem is szól érte, azaz simán legyártja a tgz fájlt mindkét esetben:
gzip -c --rsyncable valami.tar > valami.tgz
gzip -c --rsyncabl valami.tar > valami.tgz

Azt hittem, nem is megy, viszont a helyes kapcsolóval, illetve a nélkül készült gz fájlok méretében van különbség (nekem 0,6%-al nagyobb az rsync-es móddal készült) és persze élesben tesztelve az rsync-kel szépen látszik, hogy a forgalmazott byte-ok mérete a változás körüli mérettel egyenlő.

igen, az rsync kapcsolóval mindenképpen nagyobb lehet hangyányit, mert ugye itt külön blokkokat tömörít össze, nem egyben az egészet, ahol az algoritmusnak nagyobb esélye lenne a jobb tömörítésre.

azért pigz-et és lbzip2-t is meg akarom nézni ilyen szempontból, ha jó rsync-hez, megírom.

leteszteltem, íme az eredmény: 


dd if=/dev/urandom of=out bs=1M count=100

cp out in

hexedit in
# valahol 1 byte megvaltoztatas es mentes

rsync -v --progress out masik:
rsync -v --progress in  masik:out

rsync -v --progress out.gz masik:
rsync -v --progress in.gz  masik:out.gz

stb.

kétszer csináltam meg minden esetben a tesztet, két külön adattal.

speedup is 473.47 / 852.68 (tömörítetlen)
speedup is 28.62 / 102.69 (lbzip2)
speedup is 367.02 / 747.07 (gzip --rsyncable)
speedup is 413.69 / 757.04 (pigz)

wifiről csináltam, azért lehet ekkora a szórás.

a konklúzióm: gzip --rsyncable és pigz is megfelelő az rsync-es tömörítéshez. lbzip2-nél úgy néz ki a blokkok mérete nagy, -1 -es kapcsoló kisebb blokk méretet ad, ott valszeg jobb az arány.

kieg.: 


cp out in
pigz in
bsdiff out in.gz diff
ls -ltrh

-rw-r--r-- 1 andras andras 100M Jan 31 17:10 out
-rw-r--r-- 1 andras andras 101M Jan 31 17:10 in.gz
-rw-r--r-- 1 andras andras 9.0K Jan 31 17:14 diff

ebből viszont sajna az jön le, hogy pigz nem nagyon nyúl a bit-ekhez, ha nem tud érdemben összenyomni rajtuk. viszont akkor nem áll egyértelműen a fenti kijelentésem, miszerint pigz jó rsync-hez.

nagyobb jól tömöríthető anyagon kellene letesztelni pigz-et, akár a -i kapcsolóval: 

-i, --independent    Compress blocks independently for damage recovery

kicsit tovább mentem. írtam egy script-et, ami az angol szótárból dob össze véletlen adatot. 


#!/bin/bash

OUT="out"
DICT="/usr/share/dict/american-english"
COUNT=$(grep -c "" "$DICT")

> "$OUT"

for i in {1..300}
do
    shuf -n "$COUNT" /usr/share/dict/american-english >> "$OUT"
done

cat "$OUT" | tr "\n" " " | fold | iconv -f latin2 -t utf8 > "$OUT"2
mv "$OUT"2 "$OUT"

echo >> "$OUT"

ezt lefuttatva: 


pigz -k out

ls -ltrh
total 403M
-rw-r--r-- 1 andras andras 133M Jan 31 17:33 out.gz
-rw-r--r-- 1 andras andras 271M Jan 31 17:33 out

cp out in
hexedit in > 1 byte atirasa valahol

pigz -k in

rsync -v --progress out masik:
rsync -v --progress in  masik:out

speedup is 1401.33

pigz-nél -i kapcsolóval és az nélkül is = speedup is 655
gzip --rsyncable -nél pedig = speedup is 695.21

tehát azt mondom mégis jó pigz az rsync-hez!

( Mono v | 2011. 02. 01., k – 21:35 )

Mégsem kellett különvennem két sorba a tar-t és a gzip-et, találtam rá egy számomra eddig idegen megoldást. Így visszatértem a "tar -czf"-es megoldáshoz, ami fele annyi időt vett igénybe, mint a tarolás, majd gzipelés.

Ezt találtam a neten, még sosem láttam ilyet, konzol simán "megeszi" :)
GZIP="--rsyncable" tar -czf valami.tgz /valami

Aztán gondolkodtam kicsit, javítsatok ki, ha tévednék, de úgy értelmeztem, hogy ez így, ebben az esetben egy parancs erejéig a gzipnek ad értéket.
Így gyakorlatilag a már említett tar-os sorokat tartalmazó mentő szkriptem elejére beírtam az
export GZIP="--rsyncable"

sort, majd mindent hagytam a régiben. Tökéletes lett, jó sok próbálkozással, teszttel, eljutottam oda, hogy ezt az egy sort ha beírom, minden úgy megy, ahogy szeretném.
Gondolkodtam még a tömörítési szint emelésén, de időben annyira nyújtotta volna a mentést, hogy nem láttam értelmét.

Gondoltam beszámolok én is, mire jutottam a dologgal.

PS: Az azonban látszik, hogy valamelyest így is tovább tart a mentés ideje, vélhetően időt vesz igénybe az "rsync ready" tömörítés a hagyományoshoz képest.

( Mono v | 2011. 02. 01., k – 22:07 )

Lenne még valami, segítsetek értelmezni nekem ezt a dolgot.

sent 2648593 bytes received 347854648 bytes 286475.88 bytes/sec
total size is 6818095852 speedup is 19.45

A sent része most nem számít, az oké.
A received, byte-ban van megadva, ha jól számolom át, akkor az ~30MBájt, ennyit fogadott.
A bytes/sec is oké.
A total size viszont 6,4GB körül kellene hogy legyen, ekkora a foglalt mérete annak a könyvtárnak, amit szinkelek.
Rosszul számol/jelez ki, vagy ez már nem byte-ban értendő, hisz' itt nem írja, hogy bytes, mint fentebb mindenhol igen. Ez hiba, vagy benéztem valamit?

Ja, jogos, tényleg :)
Lusta voltam, betoltam a bitmatek.hu-ra a két számot, átváoltottam, nem volt nagyságrendbeli különbség. Most átszámoltam, tényleg minden rendben van. A bitmatek input mezeje nem bír ennyi digitet fogadni, levágta a végét. Köszi!

Még egy kérdés: pontosan mit jelent itt a speedup?

a speedup az adatátvitel sebességétől függetlenül azt mutatja, hogy arányaiban a szinkronizáció miatt mennyit spóroltál a teljes másoláshoz képest.

tehát a 19.45 azt mutatja, hogy kb. 20x gyorsabb volt így a másolás rsync-kel hogy csak a különbséget vitted át, mintha egy teljes másolást indítottál volna rá.

gyakorlatilag a total / recieved érték ez.