Dotaz: Použití rsync tak, aby se po sítí skutečně přenášely jen rozdíly dat.

[lertimir]

Chci se jen ujistit, že tomu co jsem si načet rozumím správně. Situace je taková. Mám desktop a server, část datového prostoru server je exportováno jako NFS share a mounuto k desktopu řekněme adresář /mnt/server. V části tohoto připojeného prostoru je datová kopie (záloha) důležitého stromu (fotky dokumenty). Zkopírovat to samozřejmě mohu různými způsoby, od cp přes synchronizaci adresáře v krusaderu, rsync lokálně mezi ~/data /mnt/server/data pak rsync --rsh="ssh -l uzivatel" . 10.0.0.1:/mnt/export1/data. Ale obávám se, že všechno tohle přes síť fakticky přetlačí všechnno z data a jediná možnost je na serveru mít rsyncd a kopírovat to s ním. Dat už je celkem dost tak. Je to mu tak nebo to jde i jinak?

---

---

Odpovědi

[petr_p]

Mezi rsyncd a rsync pres SSH by neměl být rozdíl.

rsync normálně používá metadata (čas změny a velikost), aby považoval soubory za stejné a nezkoumal jejich obsah. Ve zbývajících případech samozřejmě musí přečíst obsah. Takže pokud nechceš tahat data po síti tam a zpět, tak místo kopírování na rsyncu do přípojeného NFS použij rsync proti serveru.

Na konec v upovídaném režimu klient hlásí, kolik dat přenesl po síti. Tak si můžeš změřit.

[Jendа]

Ale obávám se, že všechno tohle přes síť fakticky přetlačí všechnno z data a jediná možnost je na serveru mít rsyncd a kopírovat to s ním.

Ne, rsync přes ssh je ekvivaletní rsyncd a přenáší taky jen změny (ze zvyku teda dávám --partial). Ostatně můžeš si to zkusit…

rsync lokálně bude kopírovat jen změněné soubory, ale celé, protože by stejně musel ten druhý soubor přečíst.

[lertimir]

takže ten rsync přes ssh spustí na druhé straně také rsync, protože když mám 100M soubor se změněným 1M musí to oba lokálně na svém systému přečíst, nějak nasekat a vyměnit si hashe těch částí a na základě zjištění rozdílných částí, jen ty přenést, jinak si to představit nedokážu.

[dustin]

Přesně tak to funguje

[lertimir]

A je rsync schopen i najit když do souboru je něco vloženo (vystříhnuto)? Protože to by nebylo jen porovnání bloků, ale nalezení (libovolného) bitového posunu něco jako diff pro binárku a ne text.

[Filip Jirsák]

Ano, je toho schopen. Tedy pokud to vložené je zarovnané na bajty, bitové posuny rsync nehledá (protože i ostatní software pracuje s bajty a ne s bity).

Rsync používá pro nalezení shodných bloků kontrolní součet, který se snadno aktualizuje, když ten blok postupně posouváte po souboru. Tj. spočítá se kontrolní součet bloku, pak se blok o bajt posune, a se znalostí toho předchozího součtu, bajtu, který vypadl, a nového bajtu rychle spočítáte kontrolní součet nového bloku. Takhle si rsync rychle spočívá kontrolní součty všech bloků souboru na cílové straně. Odesílající strana pak jen odešle „1. blok má součet XY, 2. blok ZZ“ atd. Příjemce se pak podívá, jestli blok s takovým kontrolním součtem zná, pokud ano, tak ho použije, pokud ne, řekne si odesílající straně o celý blok. Celé je to samozřejmě trošku složitější, např. ten rychlý kontrolní součet bloku není kryptograficky bezpečný (může se stát, že dva různé bloky mají stejný součet), takže se pak shoda ověřuje ještě nějakou kryptograficky bezpečnou hashovací funkcí.

[alles32]

zdar, a nebo muzes pouzit nejakej verzovaci system, treba svn. pri commitu ~/data do /mnt/server/data se dostanou jen novy a nebo zmeneny fajly.

[lertimir]

Verzovací systém na fotky a videa není asi vhodné. Prostě když sáhnu na 50 GB fotek tím že upravuji metadata, a jen 2-5G je fakticky upravených, ale fakticky všechny mají nové časy, tak přenášet jen to, co se změnilo. navíc verzování je hlavně když potřebuji držet historii. To když bych použil tak mám desítky TB fotek.

[Josef Kufner]

Mohl bys zkusit použít Git Annex. Ten je dělaný na verzování velkých souborů a s tímto by se měl vyrovnat. Na pozadí pro samotný přenos také používá rsync.

[alles32]

zdar verzovaci systemy jsou stejne pouzitylny aj pro verzovani binarnich fajlu, akorat neukazuje diff. zmena timestampu neznamena pro svn zmenu v souboru, nybrz pouziva binary-differencing algorithm. rtfm ;]

[lertimir]

Ale otázka je, jak pozná rozdíl, aniž by přenášel data po síti. ten rsync problém řeší. Ale u verzování to stejně musím přečíst. takže musím to NFS přenést po síti. Jedna RAW fotka má 30-50MB, pokud do jednoho focení s akce, což je třeba 500 fotek dodám později pár metatagů, tak ten verzovací systém musí přečít data originálu a data kopie a zjistit že v originálu mám o metatagy navíc a co bude dělat? Pošle celé nové soubory do cílového adresáře. Takže data pojedou přes NFS dvakrát. jednou aby se zjistilo, co je obsahem kopie. a po druhé, když se zjistí, že originál je novější tak se pošle originál a zase poteče přes síť. Kdežto ten rsync jak tomu rozumím a už jsem si i zkusil pošle jen CRCčka a hashe jednotlivých částí a pak pošle jen skutečné rozdíly a čtení probíhá lokální rychlostí disků, vzhledem k tomu že na obou stranách jsou raidy tak je to přes 200MB/s, i na gigabitu jsem někde u 90 MB/s.

[smartass]

delta-xfer algoritmus jde vynutit i pro lokální cesty pomocí --no-whole-file, což se může právě v případě NFS hodit. Je ale dost pravděpodobné, že bude účinnější použít přímo kód rsyncu pro přenos dat po síti (pomocí rsyncd nebo ssh) místo NFS. Narozdíl od NFS přístupu totiž může rsync proces na serveru číst data na serveru rychleji, než lokální proces přes NFS a čas nutný k výpočtu rozdílu se tak přibližně z poloviny přesune na server. Samozřejmě toto jsou jen teoretické úvahy, asi mohou existovat případy, kdy to bude naopak.

[Filip Jirsák]

Pokud máte připojené NFS, musí se pro porovnání toho souboru nejprve celý soubor přes síť přenést (NFS protokolem). Právě proto je výhodnější rsync, protože ten čte data (rychle) z lokálního disku (na obou stranách), a po síti se přenese jen rozdíl.