Dotaz: Jak zjistit, kolik toho rsync přenese

[ttt]

Na cílovém stroji mám databázový dump (~5GB), na zdrojovém stroji jsem udělal nový dump. Dokážu to přenést pomocí rsyncu ze zdrojového na cílový stroj, ale předtím, než to udělám, by mě zajímalo, kolik dat bude potřeba opravdu přenést a kolik ušetřím díky shodným blokům. Jak to zjistit?

V manuálových stránkách rsyncu jsem zjistil jen jak vypsat, které soubory se budou přenášet. Možná nějaký jiný nástroj, který dělá jen porovnání a ne přenos? Skript to jistí, ale než se to něj pustím, rád bych věděl, ze nevynalézám kolo.

---

---

Odpovědi

[Jindřich Makovička]

Od verze 3.1.0 má mít rsync volbu info, která s parametrem progress2 vypíše po skončení přenosu celkovou statistiku viz na stránce dole.

[OldFrog {Ondra Nemecek}]

Jenže autor to chce vědet předem:

(...) ale předtím, než to udělám, by mě zajímalo, kolik dat bude potřeba opravdu přenést (...)

Možná přidat --dry-run ?

[rastos]

Krátky experiment ukazuje, že s --dry-run dostane len počet bajtov potrebných na ten dry-run. Teda ak má 10 blokov po 1kB, a jeden blok sa líši. Tak to nepovie ~1kB, ale pár bajtov, ktoré potrebuje na to, aby zistil, že treba preniesť jeden blok.

[Aleš Kapica]

Kdybyste se na ten link podívali pořádně, tak byste viděli, že je tam malý skript, který přesně tenhle problém řeší. Rsync při --dry-run jen vrací seznam souborů, které se budou přenášet, ten se rourou předává utilitě pv, která ho přežvýkává.

[ttt]

Nevidím z toho, jak mi pv pomůže.

pv shows the progress of data through a pipeline by giving information such as time elapsed, percentage completed (with progress bar), current throughput rate, total data transferred, and ETA.

Potřebuju ho dopředu nakrmit maximem, které ale neznám - je to předmětem dotazu. Na odkazované stránce je jak zjistit počet přenesených souborů, ale to já vím - bude to 1.

Ještě se musím zamyslet, jestli je to vůbec možné. Nejsem si jistý, jestli rsync s plovoucími hashi nepotřebuje mít přenesený všechno předešlé, aby dokázal dopočítat, jestli bude přenášet další blok.

[Aleš Kapica]

Jestli je to jeden soubor, tak to bude objem jeho dát. Nevím o tom, že by rsync posílal data atomicky.

[ttt]

Objem dat by to byl, pokud bych neměl podobný soubor na cílovém stroji. Já tam mám dump, který je o 2 dny starší. A buď je to rsync friendly a bude potřeba přenést jen třeba 1 % nebo ne a musím zkopírovat 99 %. A tu informaci bych chtěl dřív než spustím přenos.

[Aleš Kapica]

Podle mě to je ta informace, kterou jsi dostal. Dva dny starý dump se obsahově lišit nemusí. Jinak podle toho co jsem se dočetl, funguje rsync tak, že nejprve vytvoří dočasný soubor do kterého stahuje po síti pouze bloky, které jsou odlišné od bloků v cílovém souboru a tím pak cílový soubor nahradí. Pokud půjde o binární blob, který nebude mít shodné datové bloky, tak defakto přetáhne celý soubor, ale u databázového dumpu může být skutečně přenos minimální. Viz Jak pracuje rsync

[Filip Jirsák]

Ale o to přece tazateli celou dobu jde. Aby zjistil, kolik bloků v cílovém souboru není a kolik toho tedy bude nutné přenést.

[Filip Jirsák]

Moc nerozumím tomu, k čemu je ta informace dobrá. I když zjistíte, že je potřeba zkopírovat celý soubor, stejně ho budete muset zkopírovat, a je prakticky jedno, zda ho zkopírujete rsyncem nebo jinak. Nebo-li rsync řeší oba dva případy – ať se projeví výhoda rsync protokolu nebo ne.

[R]

Napriklad aby som vedel, ci prenos prebehne za 2 minuty alebo 2 hodiny.

[Filip Jirsák]

Není lepší pro to použít parametr --info=progress2?

[nobody]

pokud ti jde nahodou o to aby to nezatezovalo 2h HDD, muzes pustit pustit pres ionice s volbou aby se pracovalo s hdd jen pokud nepracuje s hdd neco jineho, takze nebude nic brzdit...

ionice -c3 rsync ... ... ...

[ttt]

Tahám to po síti, přenos trvá několik hodin a vytěžuje síť. Můžu nastavit --bwlimit, ale pak se dostanu někam okolo 10 hodin. Pokud zjistím, že je potřeba přenést celý soubor (nebo třeba > 80 %), nebudu to přenášet vůbec a vyřeším to jinak. Třeba "kabelovým" přenosem. Idea byla, že to půjde zjistit efektivněji než experimentem.

[Filip Jirsák]

--dry-run by mělo zabránit přenosu dat, --itemize-changes vypíše změny, --stats vypíše statistiky. Z toho nedostanete výstup potřebný pro váš odhad?

[ttt]

rsync remote:dump.sql dump.sql --info=progress2    --human-readable --dry-run -vv --stats --itemize-changes

dá stejný výstup (až na čísla procesu, dobu běhu), ať mu podstrčím shodný soubor nebo prázdný soubor.

[nobody]

napada me uchylnost... drzet si ten dump dvojmo na lokalu, takze provedes realnej sync local->local, zjistis mnozstvi zmen a podle toho pustis/nepustis sync local->remote :)

[ttt]

Ech... to mě taky mohlo napadnout :) Jo, to vyřeší můj problém, ten původní dump tam někde je.

[Filip Jirsák]

To by ale bylo nutné rsync přesvědčit, aby se choval jako při síťovém přenosu. Protože rsync není napsán hloupě, a když jsou zdroj a cíl místní, soubor normálně zkopíruje a nezpomaluje to zbytečným načítáním z disku. Při síťovém přenosu je úzkým hrdlem síť, proto optimalizuje rsync přenos dat po síti. Při lokálním přenosu jsou ale úzkým hrdlem pevné disky, a nemá tedy smysl optimalizovat přenos přes operační paměť.

[lertimir]

tak ten lokální rsync pustí sítovým způsobem na localhost. to ba se choval rsync sítově.

[dustin]

Vylezou z toho požadovaná čísla?

Notably, a dry run does not send the actual data for file transfers, so --progress has no effect, the "bytes sent", "bytes received", "literal data", and "matched data" statistics are too small, and the "speedup" value is equivalent to a run where no file transfers were needed.

[lertimir]

5GB a 10 hodin? proboha co je to za síť? to je tak 100kB/s.

[Aleš Kapica]

Tím chtěl naznačit asi, jak by to bylo, kdyby to hodně přiškrtil,

[ttt]

Je to server, který se používá v interní síti, spojení ven tam typicky není potřeba. Plná přenosová rychlost myslím byla asi 250 kB/s. Běs :)

[Jendа]

Místa, kde jediné dostupné spojení je AžDSL a s trochou štěstí i zarušená mikrovlnka, nejsou zas tak vzácná.

[R]

U nas je dost miest, kde nie je ani ADSL.

[Filip Jirsák]

Nebylo by lepší použít inkrementální zálohy? Nebude nutné dodatečně zjišťovat, co se změnilo, a zároveň můžete držet těch záloh více pro případ, kdy se zjistí až po několika dnech, že se něco pokazilo.

[ttt]

Nejde o zálohování, ale o vytvoření kopie produkční databáze pro vývojáře - pokud je potřeba hledat chybu v datech. Zálohování je tam řešené jinak. Dělají se tam jen plné zálohy, v současné podobě to pro přenos použít nejde.

[dustin]

A nelze tu kopii vytvářet průběžnou replikací na nějaký server na síti vývojářů? Z replikační instance si mohou dělat klony pro svou potřebu, klidně lokálním rsyncem nebo jen cp -a. Navíc nemusí dump nalévat, mají rovnou data připravená. A pořád aktuální.