Dotaz: rsync kontrolní součty

[Honza]

Dobry večer

Ted jsem dočetl článek na http://www.root.cz/clanky/sifrovane-inkrementalni-zalohy-s-duplicity/

Konkrétně mě zaujala část "jak to funguje" kde se mluví o rsync a kontrolních součtech. Jestliže to teda dobře chápu tak rsync si vypočítává kontrolní součty souborů které zálohuji a souborů které jsou v místě kam zálohuji a podle toho přenese jen části souboru které se změnili nebo přenese celé tyto soubory které se v něčem zmenili? Přičemž tyto součty si nikde neukládá a je vždy potřeba je vypočítat znova. Tudíž by mohl nastat problém jestliže zálohuji miliony drobných souborů.

tedy při rsync -avhze ssh --delete --exclude *.avi --link-dest=$VCERA

se přenesou jen ty soubory které se změnili od VCERA celé nebo pouze rozdíly v těchto souborech?

Moc děkuji za případnou odpověď

Odpovědi

[Bedňa]

Článok sa mi čítať nechce, ale default rsync používa rýchli chcecksum na zistenie zmeny, dá sa zapnúť voľba -c čo ale predĺži zistenie chceksum súboru, čo u malých a veľa súborov nemá zmysel. V korporátnej sfére kde ide o zaistenie konzistencie dát, by sa bolo dobré pozrieť po nejakom hotovom riešení, prípadne si napísať skript, čo chcecksum k súborom bude ukladať.

[d.c.]

No, ono to checksumovani bylo puvodne zejmena na to, aby se v momente, kdy se vam prerusi prenaseni velikeho souboru, neprenasel veliky soubor po pomale lince cely znova, ale navazalo se - aniz by bylo nutne spolehat se na presny offset a jeho dodrzeni obema stranami. V nasich dobach se jiz dava prednost pouziti rsyncu bez checksumu (volba -W).

[Honza]

ano ano to vím. Ale spíše mě zajímá ten princip teoretický jak to funguje ted protože tak moc do hloubky nevidím a pokud jsem zkoušel přenášet soubor a přidávat kusy textu tak se mi podle velikosti zdá že se přenesl cely. Nenapadá mě nic rozumného jak to otestovat.

Ale testoval jsme na malém souboru. Lepší by bylo asi nějak poškodit větší soubor. Nějaky nápad jak poškodit iso slaxu?

[komodo]

Myslim, ze jsem to nekdy pred lety zkousel, a prenos jenom rozdilu fungoval pri pouziti rsync protokolu, ale ne pri pouziti rsyncu pres ssh.

[Honza]

aha takto by asi odpovídalo mým poznatkům. Takže se prostě přenese cely soubor znovu.

[potato]

To je blud, který lze velmi snadno vyvrátit. Přenáší se pouze změny. Samozřejmě jen jsou-li takového druhu, že se rsync dokáže na společných datech chytit.

Nejsnažší test je asi

dd if=/dev/urandom bs=1024 count=1 >test
cat VELIKÝSOUBOR >test
dd if=/dev/urandom bs=1024 count=1 >>test

na dvou počítačích a následně rsyncnout s --progress --verbose a kldině změřit i čas, abys měl jistotu, a porovnat RX a TX ze síťoých rozhraní.

Můj provider mi určitě nenabízí rychlost připojení přes 1,5 Gbit/s, nehledě na to, že ani nemám síťovou kartu, která by takovou rychlost uměla. Ale rsyncovat touto rychlostí téměř shodné soubory mohu pohodlně.

[d.c.]

Funguje to tak, ze se soubor "rozstriha" na kousky a od tech se postupne (na obou stranach) delaji checksumy. Kdyz nejaky nevyjde, prenese se. Ted z hlavy nereknu, jestli se prenese "od te chvile vse" nebo "jen kousky, co nevysly". Muzu se zkusit podivat. Kryptograficky silne to nebude, neni to delane na to - spis se predpoklada, ze chceme odolnost proti bezne chybe pri prenosu.

To, ze se soubor prenesl cely, kdyz v nem byla zmena, je trochu nepochopenim. Kdyz soubor upravite, ma novy timestamp, takze se nepredpoklada, ze jde o stejny soubor, viz FAQ http://rsync.samba.org/FAQ.html, hned druhy odstavec.

Soubor se da zmenit kdecim, dulezite je, aby vypadal jako puvodni, mozna pomuze udrzet cas zmeny stejny.

Jinak rsync vubec neni pitomy program, pan Tridgell si na priprave udelal PhD.

[Honza]

Souhlasím že Rsync je výborný nástroj na mnoho věcí a zálohování je jedna z nich.

Takže konečná odpověd je že je jedno jestli je použito SSH nebo přenos bez SSH vždy přenáší pouze chybný usek. A kontrolní součet není nikde uložen což se teda dá dočíst ze stránek rsync. Takže jestliže zálohuju pomocí pevnych odkazů jsou vždy přepočítány. Jestliže provedu zmenu v souboru tak se přenese celý znova protože se jedna o "jiny" soubor.

Zdálo se mi to poněkud divné že by tohle rsync neměl ošetřeno

[potato]

Timestamp nebo dalíš odlišné atributy mají vliv na to, že rsync musí znovu provést synchronizaci, což je velmi rychlé, pokud je obsah souboru na obou stranách stejný, nicméně se verbose výpisu samozřejmě objeví, že soubor byl sychronizován.

Termín ‚stejný soubor‘ IMO používáš trochu zvláštně. Běžně je stejný (týž) soubor prostě ten, který se stejně jmenuje. Týž soubor nemusí mít na obou stranách stejný obsah (to by nebylo zapotřebí nic synchronizovat). Navíc s --fuzzy lze rozpoznat a zbytečně nepřenášet i přejmenované soubory (viz ale diskusi v dokumentaci o --delay-updates a --delete-delay, aby to fungovalo pořádně).

[derata]

Děkuji za vyčerpávající odpovědi. A jak to vypadá jestliže adresář do kterého zálohuji je prázdný a porovnává se s adresáře zadaného v link-dest? Take se přenesou pouze změny v souboru?

[d.c.]

Predpokladam, ze jde o situaci:

1. Na jednom pocitaci je zdroj, ze ktereho se zalohuje.

2. Na druhem pocitaci je prazdny adresar, do ktereho se ma ulozit zaloha (nebo tam ani jeste neni).

3. Na tomtoez druhem pocitaci je stara zaloha, na kterou se ukazuje pomoci link-dest. Je ve *stejnem* filesystemu jako misto pro novou zalohu a pouzity filesystem umoznuje hardlinky.

4. Chceme pouzivat hardlinky a rekneme to rsyncu (-H).

Pak se to bude chovat presne jako obvykle, jen ma-li se prenest soubor totozny (definice viz vyse v debate) se souborem, ktery je jiz ve stare zaloze, vytvori se misto nej jen hardlink na jiz existujici soubor (=nove jmeno pro jiz existujici soubor).