Zálohování po pomalé lince

[JardaP .]

Coz ovsem neznamena, ze Unison bude fungovat lepe. To se bude muset vyzkouset, takze jestli budete delat nejake testy, tak sem neco o tom hodte.

[Reklama]

[ET]

OT napad: co pouzit http://inotify.aiken.cz/?section=incron&page=about&lang=en na serverove strane a zachytavat zmeny na FS do logu - ten nasledne dle libosti zpracovat?

[h7]

Je porovnání timestamp vůbec věrohodné? Aneb:
a) nemůže dojít ke změně vícekrát během doby jedné sekundy, tedy při druhém zápisu se již timestamp nezmění? Chápu, že pravděpodobnost nebude moc velká, ale zase ne zcela zanedbatelná, pokud jde o důležitá data.
b) nedochází někdy ke změně obsah, aniž by se měnit timestamp poslední změny souboru? Chápu, že se o to stará OS, ale některé aplikace timestamp explicitně z různých důvodu mění.

Jinak s rsyncem nemám po stránce rychlosti ideální zkušenosti. A to na lokální Gbit síti, kde synchronizovaná data mají asi 150 MB v malých souborech (weby - tedy skripty, obrázky apod.) a dojde ke změně třeba jen 1 malého souboru. Jen to projití souborů - resp. adresářů (asi i lokálně) trvá celkem dlouho. Oproti něčemu, co pracuje blokově a tedy čte disk sekvenčně a porovnává hashe bloků, je to několikařádově pomalejší. Tam je to prakticky jen o rychlosti sekvenčního čtení z disku.

[dustin]

Unison je určen pro obousměrnou replikaci. Proto potřebuje lokální databázi změn, aby věděl, na které straně se co změnilo. Pro přenos změn používá algoritmy rsyncu.

Pro jednosměrný přenos bych použil rsync a neřešil to. Údržba lokální DB unisonu má taky režii.

U vysokého počtu souborů (milióny) si rsync vezme docela dost paměti. Tam se nám osvědčil tar  --newer-mtime=DATE, ale samozřejmě je nutné si pamatovat čas spuštění poslední aktualizace. Takhle tar používá backuppc pro inkrementální zálohování tarem. Sice nepozná smazané soubory, ale je pro daný účel rychlejší než rsync.

[Filip Jirsák]

zoberie subor na lokale a opyta sa na timestamp vzdialeneho naprotivku, proste to, co vysvetlil pouzivatel Někdo .

Můžete nám prozradit, co za upravenou verzi rsyncu vy a uživatel Někdo používáte? Co rsync vypisuje, když k parametrům přidáte --stats? Možná by úplně stačilo použít vanilkový rsync bez té vaší zpomalující úpravy, která metadata souborů porovnává po jednom (ta úprava mimochodem musí velmi komplikovat kód). _{Za pravděpodobnější ale považuju, že žádný upravený rsync nepoužíváte, akorát nevíte, jak rsync funguje.}

[Reklama]

[JardaP .]

Je porovnání timestamp vůbec věrohodné? Aneb:
a) nemůže dojít ke změně vícekrát během doby jedné sekundy, tedy při druhém zápisu se již timestamp nezmění?

Vterinove timestampy pouzivaji leda tak Widle:

jarda@esus:/tmp$ stat * |grep ^C
Change: 2014-11-05 10:07:30.498946102 +0100
Change: 2014-11-02 22:13:32.815967936 +0100

Krome toho, kdyz zalohujete soubor, do ktereho se pise, nikdo vam nezaruci, ze soubor bude v konzistentnim stavu krasne posledni verze, kterou jste chtel poslat babicce.

Oproti něčemu, co pracuje blokově a tedy čte disk sekvenčně a porovnává hashe bloků, je to několikařádově pomalejší. Tam je to prakticky jen o rychlosti sekvenčního čtení z disku.

Proti necemu cemu? Co dela zalohu pouze zmenenych souboru a cte disk blok po bloku? Budete kvuli tomu, ze se vam obcas zmeni tri soubory mirrorovat vzdy cely disk blok po bloku, aby vam treba rsync nezpomaloval zalohu prolezanim adresarove struktury?

OT napad: co pouzit http://inotify.aiken.cz/?section=incron&page=about&lang=en na serverove strane a zachytavat zmeny na FS do logu - ten nasledne dle libosti zpracovat?

Zajimavy napad. Tim by se vytvoril katalog souboru, ktere je potreba zalohovat, bez toho, ze by find nebo rsync cloumaly diskem a hledaly zmeny. To je pri malych zmenach a velkem poctu souboru asi to nejpomalejsi.

[ET]

OT napad: co pouzit http://inotify.aiken.cz/?section=incron&page=about&lang=en na serverove strane a zachytavat zmeny na FS do logu - ten nasledne dle libosti zpracovat?

Zajimavy napad. Tim by se vytvoril katalog souboru, ktere je potreba zalohovat, bez toho, ze by find nebo rsync cloumaly diskem a hledaly zmeny. To je pri malych zmenach a velkem poctu souboru asi to nejpomalejsi.

Mohl bys to nejak objasnit (rezie inotify, nebo neco jineho)? Server bude vedet, ze se zmenily napr. 3 soubory a klient si je stahne (zadny porovnavani src/dst, jak ostatne pises) - co se tyce vytizeni linky, pripada mi to jako nejefektivnejsi

[JardaP .]

Mohl bys to nejak objasnit (rezie inotify, nebo neco jineho)?

Objasnit co?

[Mirek Prýmek]

Potřebuješ-li obousměrnou replikaci, jdi rovnou do unisonu. Je to spoustu let otestovaný soft, ve firmě jej pro synchronizaci souborových serverů mezi pobočkami používáme min. 10 let. Jen to chce výstup grepnout na konflikty a ty si nechat cronem posílat mailem.

Taky jsem unison teďka začal používat (na vlastní úložiště dokumentů ala dropbox) a dvě věci bych potřeboval objasnit:

1. je nějaký důvod, proč unison pouštět z cronu a nenechat ho prostě běžet? Přijde mi, že při spuštění ta fáze načítání trvá celkem dlouho. Pokud běží pořád, tak změněné soubory synchronizuje okamžitě.

2. orientuje se skutečně jenom podle času? Pokud bych na straně A vytvořil nový soubor X a strana B měla čas o trochu dopředu, nemůže se stát, že soubor na A smaže? (pokud ano, pak by bylo fakt lepší ho pouštět jenom jednou za X minut, kde posun času o tolik minut by byl nepravděpodobnej)

Jde mi o to, jestli unison dokáže nějak podle katalogu zjistit, že X je opravdu nový a na straně B nikdy nebyl, nebo ne. Prostě jestli můžu nějakou nehodou o nějaký soubor přijít nebo ne... Vzhledem k tomu, že to používám na dokumenty (ručně vytvořené a důležité), byl by to pro mě docela problém...

[dustin]

je nějaký důvod, proč unison pouštět z cronu a nenechat ho prostě běžet? Přijde mi, že při spuštění ta fáze načítání trvá celkem dlouho. Pokud běží pořád, tak změněné soubory synchronizuje okamžitě.

Koukám, že do něj přidali funkci repeat. To dřív nebylo. Jo, pokud ti to s inotify funguje, proč ne. Jen bych si otestoval, co to dělá např. na sambovském serveru, když uživatelé otevírají soubory v office.

orientuje se skutečně jenom podle času? Pokud bych na straně A vytvořil nový soubor X a strana B měla čas o trochu dopředu, nemůže se stát, že soubor na A smaže? (pokud ano, pak by bylo fakt lepší ho pouštět jenom jednou za X minut, kde posun času o tolik minut by byl nepravděpodobnej)

Podle času asi ne, spíš podle stavu své interní db. Když najde soubor na jedné straně a na druhé straně není, tak jej přenese. Až když bys jej poté na A smazal, smaže i na B. Pokud nebyl mezitím na B změněn - pak zahlásí konflikt a nic nedělá. Proto si ty konflikty z výstupu grepujeme a posíláme mailem, abychom je mohli ručně vyřešit (správce má na lokálu namontované obě strany a rozhoduje se dle situace, co smaže a co nechá).

[crown]

Zdravim,
Prosim vas, viete niekto poradit?
potrebujem robit obcasny mirror (nie v realnom case, skor povedzme raz za tyzden) na vzdialeny server, na ktory mam ale velmi pomale spojenie. rad by som na to pouzil software, ktory vie vyrabat nejaky lokalny katalog s informaciami o vzdialenej kopii, ktoru potom aktualizuje na zaklade porovnania lokalnej kopie s katalogom a samozrejme katalog pri tom updatuje.
Ide mi teda o to, aby sa pri mirrorovani neporovnavali subory na lokali so subormi na vzdialenom stroji, ale aby sa porovnanie robilo lokalne a cez siet aby sa prenasali len zmeny.
Rad by som pouzil nieco standardne a pokial mozno otvorene (bnapriklad tsync toto vie, ale otvoreny nieje).
vdaka za ake kolvek napady

Vim, ze je to uz postarsi tema, ale rad bych se zeptal, jestli to Peter vyresil.

Mam podobne - chci synchonisovat velky adresar na velmi pomaly SMB disk a chci aby si to zapamatovalo stav na serveru. Ted zkousim Unison, funguje pekne, ale je velmi pomaly pri kontrole zmen na druhe strane. Zaroven take chci, aby na druhe strane byly soubory primo viditelne, tedy ne jako duplicity.

[Unknown]

Vterinove timestampy pouzivaji leda tak Widle

Nemelte nesmysly:

C:\>wmic datafile where name="c:\\test.txt" get LastModified
20150329221650.080654+060

[Peter]

Vim, ze je to uz postarsi tema, ale rad bych se zeptal, jestli to Peter vyresil.

Mam podobne - chci synchonisovat velky adresar na velmi pomaly SMB disk a chci aby si to zapamatovalo stav na serveru. Ted zkousim Unison, funguje pekne, ale je velmi pomaly pri kontrole zmen na druhe strane. Zaroven take chci, aby na druhe strane byly soubory primo viditelne, tedy ne jako duplicity.

Som síce iný peter, ale odporučil by som opísať čo znamená výraz "velmi pomaly SMB disk". Pod niečím takým si viem predstaviť akurát tak WiFi SD kartu sprístupňujúcu údaje priamo z foťáku, alebo vzdialený CIFS server pripojený cez pomalý WAN. V druhom prípade by som odporučil vzdialenú synchronizáciu cez rsync over ssh.

Vterinove timestampy pouzivaji leda tak Widle

Nemelte nesmysly:

C:\>wmic datafile where name="c:\\test.txt" get LastModified
20150329221650.080654+060

Nemám po ruke windows, ale platí to aj pre FS FAT pod daným OS?

[crown]

Pomaly disk v mem pripade = One drive for business pripojeny pres webDav jako sitovy disk (Win ho vidi namapovany jako disk). Je to opravdu pomale, ale je to schvalene na zalohovani dat. Nemuzu tam tedy pustit rsync server.

Jeste jsem zapomnel doplnit, ze disk se pripojuje jen z tohoto pocitace, takze nehrozi, ze by mezitim nekdo jiny provedl zmeny.

[JardaP .]

Nemám po ruke windows, ale platí to aj pre FS FAT pod daným OS?

NTFS rozlisuje po 100 ns, FAT (respektive funkce write) pry po 2s. Otazka pak je, jake je realne rozliseni NTFS, tedy jestli napriklad hodiny, ze kterych se bere cas pro timestamp, jsou updatovany dostatecne casto, aby to rozliseni po 100 ns bylo mozno vyuzit.