Názory k článku
Synchronizujeme se zsync aneb rsync po běžném HTTP

Kdyz uz se tu nakousl rsync, nevite nekdo, jestli nekde existuje rsync pro Widle? Na Google to vypada, ze spis asi ne. Pouzivam rsync pro zalohovani Widli z Linuxu a bez podpory na Widlich to neni to prave orechove, protoze se pri zmene prenasi soubor vzdy cely.

Ja používam na windows cwrsync – zálohujem ním lokálne dáta z jedného disku na druhý, no pokiaľ viem podporuje aj klient-server režim.

Ja pouzivam http://sourceforge.net/projects/sereds CWrsync. Je to vlastne vykousanej rsync z cygwinu. Mas tam balik client nebo server, da se nainstalovat jako sluzba. Bud pouze s rsync protokolem nebo myslim i s ssh serverem. Ted si nejsem jistej, jestli ten ssh server ma v sobe, pokud ne, tak http://sourceforge.net/projects/sshwindows SSH Windows.

No ale jak to je s Unicode znaky? Používal jsem DeltaCopy, ale tohle byla potíž, takže nakonec Widle zálohuju tak, že si připojím CIFS share a v Linuxu pustím rsync, to je pak vše v pořádku. Rsync server by samozřejmě byl jednodušší.

Tohle prave delam. Jenze protoze na Widlich nebezi rsync, tak se vzdy prenasi cely zmeneny soubor. Zalohuju jenom uzivatelska data, ktera jsou kvuli tomu nasdilena na sit.

Když už jsme u tohoto typu programů, tak doporučuju podívat se ještě na rdiff-backup a Unison. Oba mají trošku jiné použití než rsync/zsync, ale mně se tyto programy docela osvědčily, tak se snad budou hodit i někomu dalšímu.

rdiff-backup  – v Pythonu napsaný (tedy dobře multiplatformní) nástroj pro zálohování. Data přenáší stejně úsporně jako rsync (používá knihovnu librsync), také dokáže pracovat s lokálními i vzdálenými adresáři (nebo jejich kombinací). Provádí zálohu přesné kopie zdrojového adresáře do adresáře cílového. Pokud ale v cílovém adresáři již nějaká starší verze existuje, tak ji jen tak nepřeplácne, ale uloží si do podadresáře rdiff-backup-data/ diffy změn. Přímo uložená je tedy přesná kopie aktuálního stavu, pomocí diffů je ale možné zrekonstruovat z ní i verzi starší. Takto je to možné provádět pořád dokola, k dispozici jsou pak všechny starší verze. (Jedná se vlastně o extrémně primitivní nástroj pro správu verzí.) Co se mi na nástroji hrozně líbí je to, že aktuální kopie je vždy uložená přímo. Pokud tedy smažete ten speciální podadresář rdiff-backup-data/, tak máte úplně normální kopii adresáře, jako kdybyste data prostě zkopírovali pomocí cp/ scp apod. Nejste tedy závislí na programu rdiff-backup, data obnovíte i bez něj prostý kopírováním, nejsou v žádném speciálním formátu. rdiff-backup potřebujete jen pro (pohodlnou) obnovu starších verzí. Zadarmo také máte kontrolní součty všech souborů v záloze ( rdiff-backup si SHA-1 součty dat ukládá v tom pomocném adresáři rdiff-backup-data/), pro ověření konzistence zálohy tedy stačí spustit rdiff-backup -v /cesta/k/záloce/ a hned víte, jestli vám záložní médium tiše nedegraduje.

Unison  – Skvělý multiplatformní nástroj pro synchronizaci dvou adresářů (např. na notebooku a pracovní stanici; umí pracovat se vzdáleným adresářem např. přes SSH). Data opět přenáší efektivně, podobně jako rsync. Je určený opravdu k synchronizaci dvou adresářů, které se mění oba současně a nezávisle na sobě. Při synchronizaci si data na obou stranách očuchá, porovná se svým pomocným záznamem o posledním známém stavu a uživateli navrhne co dělat (např. nové soubory z notebooku nahrát na desktop, soubory smazané na desktopu smazat i na notebooku, změny v souborech na notebooku propagovat na desktop a opačně). Typicky se pracuje interaktivně (k dispozici je textový režim a GTK GUI), takže uživatel může návrh propagace změn zkontrolovat a případně směr synchronizace změnit (nebo synchronizaci některých dat úplně přeskočit). Pokud Unison neví co dělat (např. na obou stranách se objevil nový stejně pojmenovaný soubor, ale s jiným obsahem), tak je zásah uživatele nutný (pokud nebylo dopředu explicitně řečeno, že jedna kopie je velící a použijí se data z ní). Nástroj si zakládá na bezpečnosti synchronizace, takže se např. cokoliv maže vždy až na úplný konec a po důkladném ověření, že se data opravdu přenesla správně.

Taktiez mozem odporucat Unison. Velmi stary hodnotny nastroj. Ked synchronizovat adresare pre desktop tak jedine Unison. Pre synchronizaciu servrov som to nepouzival.

O rdiff-backup jsem psal už před rokem.

Diky vsem za tipy, az bude chvilka, tak se na to mrknu.

rsync je AFAIK GNU, takze ho bud zkompilujes pomoci MinGW do jednoho exace, nebo pomoci Cygwinu do jednoho exace, ktery musis distribuovat s cygwin1.dll.

Pokud chces i server, tak ssh servery pro windows existuji, nebo lze opet pouzit OpenSSH na cygwinu…

Nějak jsem nepochopil to vytvoření crc
zsyncmake -u http://mujweb.cz/soubory/obraz.iso -b 8192 obraz.iso

proč je tam jako parametr 2× obraz.iso?

V článku je to vysvětleno – to první je URL, na kterém bude soubor viditelný na webu (může to být klidně na jiném serveru než na jakém leží info soubor) a to druhé je pak lokální cesta k souboru, který je utilitou zkoumán, rozřezán a ohashován.

„…nevyžaduje speciální podporu na druhé straně.“

„K dispozici je samozřejmě i kontrolní soubor, který sice leží v jiném adresáři, ale to vůbec nevadí…Oba soubory jsou dostupné skrze HTTP,“

Takze na web server popdora MUSI byt – musi tam nekdo vytvorit ten zsync soubor. A pokud uz by tam nekdo mel vytvaret zsync soubor, tak je rovnou jednodussi nechat spusteni rsync.

„Velkou výhodou zsync je právě ta vlastnost, že celý systém nevyžaduje žádnou speciální podporu na straně serveru. Toho využívá například Ubuntu, které už nějakou dobu soubory .zsync na svých zrcadlech nabízí.“

Pokud se nepletu, tak vetsina distribuci ma podporu rsync uz hodne dlouho. A rsync nevyzaduje vubec zadnou podporu, proste se nahrajou data a tim to konci. Zsync potrebuje „podporu“ uzivatele – po nahrani dat musi uzivatel vytvorit kontrolni soucty. Pokud uz mam pristup k nejakemu serveru, kde muzu generovat zsync soubory, tak radeji nahodim rovnou rsync (at uz jako root nebo user).

Ale jinak je to zajimava myslenka. Ikdyz uz je tady bittorrent, jidgo a rsync.

Rozdíl tam je – kontrolní soubor si můžete vygenerovat lokálně a pak ho uploadnout společně s daty. Na serveru pak už víc nepotřebujete. Pokud používáte k šíření svých dat nějaký běžný webhosting, asi vám tam nikdo rsync server pouštět nebude. Zsync další software na serveru nevyžaduje.

Co jsou „navazovaná spojení“? HTTP by bez navazani spojeni asi nefungovalo, zejo…

Starší HTTP servery neuměly navázat na stahování souboru. Vždy bylo třeba stahovat soubor od prvního bajtu. Dnes můžete navázat v jakémkoliv místě.

„Navazovaná spojení“ je nesmysl. Jde o možnost vyžádat si část souboru, nikoliv soubor celý, používá se k tomu tzv. „Range“ http hlavička. (Termín „navazované spojení“ totiž předpokládá, že už předtím nějaké spojení bylo uskutečněno, což vůbec nemusí platit.)

Ano, autor to nazval trochu salamouncky : )
Logicky se jedna o implementaci http kodu odpovedi 206 Partial Content – viz http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.7

To je taky blbost. Jedná se o implementaci hlavičky „Range“. „206 Partial Content“ se pochopitelně použije až tehdy, když si to klient vyžádá pomocí „Range“…

A mozem pomocou zsync „stahovat“ cely strom suborov aj s podadresarmi ? Teda nie len jeden konkretny subor, ale vsetko ? Tak ze spustim „zsync“ a stiahne mi vsetky rozdiely v uz existujucich suboroch, ale tiez mi stiahne aj subory, ktore na serveri pribudli ?

Takze to nejde ? Neviete niekto poradit ?

Nejde. zsync je navrzen pro stahovani jednotlivych (velkych) souboru.

Ubuntu kdysi pouzivalo jigdo… dnes dava prednos ZSyncu?
Tomu se mi nechce moc verit… na .iso bude jigdo urcite mnohem rychlejsi

Myslim si, ze zsync muze byt rychlejsi nez jigdo. Pokud teda nemate uz na disku hromadu balicku, muzete dojit k cili rychleji pred jigdo; zkuste si to… ;-). Urcite je zsync jednodusi na pouzivani, pokud mate stare CD/DVD a chcete stahnout novou verzi, stoji zsync za pokus. Vlastne lze jigdo a zsync i zkombinovat, nejprve si pomoci jigdo pripravite CD/DVD z dostupnch dat ktere uz mate (stare CD/DVD. balicky v cache, atd) a v momente kdy zacne jigdo stahovat chybejici balicky z webu, tak zapojite do hry zsync a CD/DVD dokoncite; je to jen trosku pracne… ;-)

Proti rsync (i jigdo) je zsync pro koncoveho uzivatele vyrazne jednodussi na pouziti. V porovnani s rsync nezatezuje server (vypocty probihaji na strane klienta).

Na otazku zda Ubuntu dava prednost zsync pred jigdo je ma odpoved, ze mate moznost volby a je jen na Vas co pouzijete… Osobne si myslim, ze jigdo moc uzivatelu nepouzivalo, zsync ma vetsi sance na rozsireni, je jednoduchy.

Dalsi zajimavou alternativou pro download velkych souvboru (DVD/CD) je „metalink“, ktery propaguje OpenSUSE a je podporovan treba aria2 klientem. Metalink umi vhodne spojit vyhody http z rychlych serveru a bittorrent klienta. Pokud by se matelink rozsiril o podporu zsync protokolu, bylo by to take zajimave…

.. a vse se tak posune.

pak jsi v řiti

Nestane se vubec nic zvlastniho, zsync zmenu pozna a stahne jen par bajtu aby soubor opravil. Vyzkousejte!

Zsync totiz nepasuje bloky hloupe (jednoduse) proti sobe (jak to dela treba bittorent, ktery porovnava bloky na stejnem offsetu), ale pouziva „rolling checksum“, nebo jak se ten algoritmus jmenuje. V ridicim souboru (soubor s priponou zsync), je kazdy blok fixni velikosti (treba 4096b) popsan dvema kontrolnimi soucty. Jeden jednoduchy otisk (rychly na vypocet) se pouziva k vyhledavani znamych bloku dat, silnejsi kontrolni soucet se pouzije k overeni, ze nalezeny blok dat je skutecne ten ktery potrebujme. To byl pokus o jednoduche vysvetleni, presnejsi a podrobnejsi nejdete treba zde:

http://zsync.moria.org.uk/paper200501/

i když se mi to zas tak moc nelíbí, protože je IMHO nebezpečí, že při update souboru se zapomene updatovat i .zsync soubor a bude to všechno v pr…

možná by nebylo od věci např. na straně serveru naimplementovat generování zsync pomocí php (nebo jiného skriptovacího jazyka dle gusta…), ten soubor nevypadá tak strašně složitě, nemáte někdo odkaz na jeho specifikaci?

prostudujte si zdrojovy kod zsyncmake… ;-)

Pripadne hledejte zde:
http://zsync.moria.org.uk/index

Ale delat to v PHP, nevim, asi to neni dobry napad, zvlast, pokud existuje zsyncmake…

cron hourly (nebo mene) + kontrola timestampu posledni zmeny

pripadne file alternation monitor (FAM daemon)

Pokud zsync soubor neodpovida souboru ktery popisuje, zsync to pozna a vyhlasi error. Kazdy blok ktery se stahne s http serveru je porovnan s ocekavanym blokem (otisk bloku je ulozen v ridicim „zsync“ souboru), takze pokud zsync stahne blok dat a vyjde mu jiny kontrolni soucet nez ocekaval, ohlasi error a konci. Toto se obcas stane, pokud si stahujete CD, ktere se prubezne aktualizuje, trebe „Ubuntu daily build“. Muze se stat, ze zacnete stahovat CD, ktere se na serveru zmeni drive nez dokoncite stahovani; zsync tuto situaci detekuje v okamziku, kdy mu poprve vyjde kontroni soucet odlisne. Vetsinou staci spustit proces znovu, pokud kontrolni soubor odpovida souboru ktery popisuje, pouziji se jiz stazena data k vytvoreni aktualni verze.

Kazdy vikend si spuste tento prikaz:

zsync http://cdimage.ubuntu.com/daily/current/lucid-alternate-i386.iso.zsync

A uvidite, jak probiha vyvoj Ubuntu 10.04 a muzete testovat… ;-) Prvni download bude trvat dele (pokud mate rychly internet, pak muze byt rychlejsi WGET nez ZSYNC), dalsi vikendy budete stahovat jiz jen zmeny. A az na konci dubna oficialne vyjde Ubuntu 9.10, provedete update z beta CD na final CD nejak takto:

zsync -i lucid-alternate-i386.iso http://releases.ubuntu.com/10.04/ubuntu-10.04-alternate-i386.iso.zsync

Update proti vcerejsku vypada nejak takto:

$ zsync http://cdimage.ubuntu.com/daily/current/lucid-alternate-i386.iso.zsync
#############­####### 100.0% 460.4 kBps DONE

reading seed file lucid-alternate-i386.iso: *************­************************­*****Read lucid-alternate-i386.iso. Target 98.4% complete. *************­************************­************************­****************
downloading from http://cdimage.ubuntu.com/daily/current/lucid-alternate-i386.iso:
#############­####### 100.0% 585.2 kBps DONE

verifying download…checksum matches OK
used 662204416 local, fetched 10851471

$ ls -ltr lucid-alternate-i386.iso*
-rw------- 1 user user 672378880 2010–03–13 20:40 lucid-alternate-i386.iso.zs-old
-rw------- 1 user user 673048576 2010–03–14 13:33 lucid-alternate-i386.iso

Distribuce SLAX (www.slax.org) zsync soubory nepodporuje. Ale prave na SLAX lze hezky ukazat, jak zsync muze zrychlit download velkeho souboru pokud jiz mate podobny. SLAX vydava vzdy dva soubory, jednak ISO pro vypaleni na CD, pak TAR pro rozbaleni na USB disk; soubory se lisi jen velmi malo, ale kazdy ma cca 200MB. Prestoze autor SLAX zsync soubory nevytvari, nasel jsem pouzitelne soubory na jinem webu; ukazka, ze zsync nemusi nutne delat autor…

1) slax-6.1.1.iso → slax-6.1.2.iso (cca 80% uspora):

$ zsync -i slax-6.1.1.iso http://psl.ic.cz/zsync/slax-6.1.2.iso.zsync

2) slax-6.1.2.iso → slax-6.1.2.tar (velmi rychle, stahuje se jen 189kB dat):

$ zsync -i slax-6.1.2.iso http://psl.ic.cz/zsync/slax-6.1.2.tar.zsync

3) slax-6.1.1.iso → slax-6.1.2.tar (cca 80% uspora; pokud jsme provedli krok 2, pak uspora 100%):

$ # rm slax-6.1.2.tar # nepracujeme prilis efektivne… :-)
$ zsync -i slax-6.1.1.iso http://psl.ic.cz/zsync/slax-6.1.2.tar.zsync

uz vime, ze poradny a chytry HTTP server by mel umet dodat nam pouze vyzadanou cast souboru, pokud soubor nechceme cely (pocatecni offset je soucasti requestu a pri dosazeni offsetu konce pozadovanehou useku souboru proste closneme spojeni)

a ze HTTP i nejakym zpusobem zvlada posilat kontrolni soucty souboru (i kdyz ve svete dynamickych webovych stranek na posilani takovych hlavicek vetsina PHP newbies zvysoka kasle).

teoreticky by nemel byt problem upravit server tak, aby tyto dve vlastnosti zkombinoval a posilal nam hash vyzadane casti souboru (hashe muze cachovat na zaklade timestampu modifikace souboru).

kdyz by toto http protokol specifikoval, mohl by zsync jednoduse nahradit nas oblibeny prikaz
wget -c URL

zsync ale nepracuje tak, ze by pozadoval od serveru hash nejake casti souboru. Takto pracuje rsync, cimz vznika na strane serveru vypocetni zatez (coz je duvoud, proc je tak tezke najit verejne servery s podporou rsync). zsync potrebuje ridici soubor, kde je kazdy blok souboru (typicka veliost bloku je 4kB) otisknut v podobe kontrolniho souctu (zjednoduseno). Tato informace (nenazyval by jsem to hash) se spocita jen jednou a jiz se nemeni. zsync si stahne tento popis souboru a pokusi se v dostupnych lokalnich datech (stare CD, atd) najit shodne bloky (ktere mohou byt klidne na jinych pozicich). Pokud se mu to podari, pouzije je. Pokud ne, chybejici useky souboru stahne z http serveru, pouziva se hlavicka range, velikost stahovanych bloku nemuseji byt nutne nasobkem 4kB (pokud se v lokalnich datech najdou dva 4kB bloky oddelene 543 chybejicimi daty, stahuje se jen chybejicich 453B…)

Zajimave je, ze pokud mate velmi rychle pripojeni a vykonny http server, dokaze WGET ziskat velky soubor rychleji, nez ZSYNC. Zrejme to souvisi s rizenim toku dat a buferovanim, mozna take ze „range“ neni implementovana na strane serveru optimalne, protoze vetsina klientu nepouziva „range“ tak intenzivne, jako zsync. WGET casto dokaze stahnout vice dat rychleji, nez ZSYNC mene dat. Pokud se soubory hodne lisi, WGET stahne data rychleji.

Pokud se podovate na hlavicku genrovanou zsync, tak to muze byt hodne divoke, treba tady:

Host: cdimage.ubuntu.com
Referer: http://cdimage.ubuntu.com/daily-live/current/karmic-desktop-i386.iso.zsync
Range: bytes=12910592–12955647,12976128–13139967,13152256–13877247,13922304–14270463,14307328–14311423,14348288–14352383,14430208–14434303,14585856–20189183,20205568–22876159,23699456–24178687,24219648–24338431,24363008–24367103,24387584–28774399,28790784–28794879,28803072–28852223,28868608–28872703,28884992–29073407,29093888–29102079,29122560–29290495,29319168–29323263