Fórum Root.cz
Hlavní témata => Server => Téma založeno: Peter 06. 11. 2014, 14:51:00
-
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
-
Hledáš Duplicity (článek na Rootovi (http://www.root.cz/clanky/sifrovane-inkrementalni-zalohy-s-duplicity/)). Ukládá si informace o zálohách u sebe a vyrobí archiv se změnami, který pošle na hloupé úložiště (nemusí tam být nic nainstalováno). Všechno se děje u tebe a až výsledek se posílá ven. Znamená to minimum komunikace s tím úložištěm.
-
No mozna hleda spis Duply ;)
http://duply.net/wiki/index.php/Duply-documentation (http://duply.net/wiki/index.php/Duply-documentation)
-
Dobry den,
Vdaka za tipy,
ja by som ale potreboval robit mirror, duplicity vytvara nejake archivy.
-
proc ten lokalni katalog? proc ne rovnou rsync?
-
Pretoze to velmi dlho trva. Ocakavam, ze ak budem mat lokalny katalog, tak usetrim velke mnozstvo zbytocnej komunikacie. rsync bi bol idealny, keby vedel robit lokalny katalo.
-
Co kdybyste si pri kazdem rsyncu ulozil timestamp, kdy jste to delal a nasledne pomoci find nasel soubory, ktere se zmenily (modify cas mladsi, nez timestamp) a ty predhodil rsyncu, aby se nevytvarely sahodlouhe katalogy souboru na kazde strane, ktere je pak potreba porovnat?
Nejake takove reseni mate treba tady: http://serverfault.com/questions/115945/synchronizing-very-large-folder-structures , ale asi to bude chtit priohnout.
-
rsync vedle změn posílá navíc jen kontrolní součty bloků, to by oproti posílání změn neměl být velký nárůst. Takže pokud to velmi dlouho trvá s rsyncem, bude to při posílání pouze změn jen o málo rychlejší. Pokud tedy rsync používáte správně.
-
no predstavte si takuto situaciu:
- mam priecinok ktory obsahuje v podpriecinkoch 10000 suborov
- od posledneho mirrorovania sa zmenili 3 subory
- ak mi bude rsync porovnavat lokalnu kopiu so vzdialenou, tak to bude trvat strasne dlho a uplne zbytocne.
suhlasite? Alebo pri pouziti rsyncu prehliadam nieco, cim by som mohol rozumne riesit taketo situacie?
vdaka za navrh s pamatanim timestampu, uvazoval som o tom, ze si nieco naprogramujem, povedal som si ale, ze sa najprv opytam, aby som nekodil zbytocne.
-
- ak mi bude rsync porovnavat lokalnu kopiu so vzdialenou, tak to bude trvat strasne dlho a uplne zbytocne.
suhlasite? Alebo pri pouziti rsyncu prehliadam nieco, cim by som mohol rozumne riesit taketo situacie?
Ano, když to budeš používat jako debil, tak ti to bude bitově porovnávat lokální a vzdálenou kopii úplně zbytečně. Zkus RTFM.
-
16:09:17. Nechce se mi opakovat. Podle me schudna cesta, jen to dopilovat.
-
Myslim, ze si trochu nerozumieme. Skusim vysvetlit este raz a vy zase mozete skusit jednat trochu normalnejsie. Ak sa neda, tak nevadi, pochopim, kazdy ma nieco, co je nad jeho schopnosti. Ak v dalsej odpovedi dokazete zformulovat aj nieco konstruktivne, tak pokojne aj v takomto jazyku. ;)
Samozrejme mi ani nenapadlo porovnavat obsahy suborov. Ak ale porovnavam len datumy zmien, tak sa takisto musi rsync opytat na kazdy jeden subor druhej strany a musi to urobit cez siet. Teda urobi velmi vela dotazov, ktore su uplne zbytocne, pretoze v konecnom dosledku zisti, ze na lokalnej strane (na strane odkial uploadujem) sa zmenili len 3 subory. Ak by som mal nejaky lokalny katalog, tak by som vykonal vsetky testy na zmeny bez jedineho requestu po sieti a posieti by som riesil len upload zmenenych suborov alebo nebodaj len casti suborov.
-
Chjo ... na prasaka, udelas si pro data fs, kterej umi snap. Vyrobis uvodni repliku (tu na remote stroj proste nejak dostat musis) a nasledne uz prenasis jen ten snap = zmeny.
Samo existujou nastroje, ktery umej deduplikovat data na ruznych urovnich, ale nevim o nicem zadarmo ani free.
-
@peter: Reseni, ktere jsem vam podstrcil, cpe do rsyncu jen ty soubory, ktere se zmenily, rsync pak prenese jen zmeny (pokud mate rsync na obou koncich, jinak na to zapomente a pouzijte cp). Porovnavani kontrolnich bloku souctu snad jeste unesete, pokud ne, bude to problem. Snad leda, ze byste to delal pomoci duplicity, jak rikal pan Krcmar a na druhe strane to rourou cpal zase do duplicity, ktere to bude rozbalovat, kam to patri. Jestli to nejak jde, ja duplicity neznam.
Jinak me napada leda zsync, coz vzdalene zni jako to, co asi hledate. Ale je otazka, jestli to pujde priohnout tak, aby to nebyl prilis velky porod. Je potreba web server, ktery by se musel spustit asi na strane zdroje, napriklad na lokalu, na ktery si pak udelate tunel pres ssh a do nej poslete zsync. Ale neberte me moc vazne, fantaziruji, zsync znam jen podle nazvu. Vice v manualu.
-
@JardaP dakujem, pustim sa do vlastneho riesenia, tu som sa opytal len pre pripad, ze existuje nejake riesenie ktore nepoznam.
-
@JardaP moja rozvlacna reakcia s komentarom na temu normalne jednanie bola urcena cloveku pod menom Lol Phirae, priamo pod vasou reakciou sa ocitla omylom.
-
@JardaP moja rozvlacna reakcia s komentarom na temu normalne jednanie bola urcena cloveku pod menom Lol Phirae, priamo pod vasou reakciou sa ocitla omylom.
Lol má nějaký blbý období, mám pocit, že dřív byl normálnější. Ono teda to období má souběžně víc lidí na tomhle foru...
To Jardovo řešení vypadá schůdně, ale vyžaduje napsání nějaký skriptíku... Nicméně funkční to určitě bude a jednoduchý taky.
-
@peter: Koukal jste na unison? Podotykam, ze manual jsem zase necetl, ale zanesla se ke mne ozvena....
-
@JardaP ano, robi to co potrebujem, dik za tip.
-
Tak. A teď přicházím já.
O unison jsem slyšel kdysi dříve (dva roky zpět). Trochu jsem si zjišťoval, ale nějak jsem nepochopil, jestli to umí to, co potřebuju. Jde mi o obousměrný zálohování (data se mohou změnit na obou stranách) a dělat dva rsync za sebou mi přijde nešikovný.
Nevíš o tom Jardo něco víc než jen jméno?
-
Je uz toto stabilne? http://docs.oracle.com/cd/E37670_01/E37355/html/ol_sendrecv_btrfs.html
-
@Pavouk106 unison vie aj synchronizaciu, co je asi to co potrebujete. mozete urcit ako ma riesit konflikty... teraz ale pozeram, ze sa to uz nevyvija.
-
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.
Skript, který spouštíme každých 20 minut v cronu:
#! /bin/bash
if ! pkill -0 -x unison; then
# unison nebezi
# odstranime pripadne zamky
rm -f /root/.unison/lk*
/usr/bin/unison -ignore "Name Thumbs.db" -group -contactquietly -xferbycopying -rsync -batch /var/data/DIR/ ssh://HOST//srv/samba/DIR/ 2>&1 | tee -a /root/sync.log | egrep -i '<-\?->|failed:|has been modified' | grep -vi '^props'
fi
-
- ak mi bude rsync porovnavat lokalnu kopiu so vzdialenou, tak to bude trvat strasne dlho a uplne zbytocne.
suhlasite?
Nesouhlasím. Proč by to mělo trvat strašně dlouho?
Alebo pri pouziti rsyncu prehliadam nieco, cim by som mohol rozumne riesit taketo situacie?
Možná přehlížíte to, jak funguje rsync? Porovnají se seznamy souborů na obou koncích a data poslední změny, u souborů, kde se liší, se přenesou změněné bloky. Pokud byste nepotřeboval na vzdálené straně soubory mazat, můžete rsyncu dát jako parametr datum a čas, kdy jste synchronizaci prováděl, a on přenese jenom změněné soubory - ušetříte tedy přenos seznamu souborů. Pokud chcete zkombinovat obojí, stačí si lokálně pamatovat, které soubory jste smazal - nejjednodušší je pamatovat si komplet seznam souborů a při zrcadlení zjistit, které už lokálně neexistují, a ty smazat i na vzdáleném počítači.
Takže s rsyncem se budou přenášet jen změněné části souborů, případně seznam souborů, pokud mazání souborů necháte na rsyncu. Jak na tom chcete ještě něco ušetřit?
-
Nevíš o tom Jardo něco víc než jen jméno?
Radsi se rovnou priznam bez enhanced interrogation technique, ze ne. Jen jsem hrabl do Google, protoze jsem si rikal, ze neco nekde musi byt a vypadlo na me tohle: http://moo.nac.uci.edu/~hjm/HOWTO_move_data.html a vzpomnel jsem si, ze jsem o tom uz nekdy pred sto lety slysel. Asi udelas lip, kdyz mrknes na zakladni popis zde: http://en.wikipedia.org/wiki/Unison_%28file_synchronizer%29 . Jinak uz ti odpovedeli jini a spis to vychvaluji.
-
- ak mi bude rsync porovnavat lokalnu kopiu so vzdialenou, tak to bude trvat strasne dlho a uplne zbytocne.
suhlasite?
Nesouhlasím. Proč by to mělo trvat strašně dlouho?
Alebo pri pouziti rsyncu prehliadam nieco, cim by som mohol rozumne riesit taketo situacie?
Možná přehlížíte to, jak funguje rsync? Porovnají se seznamy souborů na obou koncích a data poslední změny, u souborů, kde se liší, se přenesou změněné bloky.
Bohužel jste zamlčel nejpodstatnější věc: to porovnávání rsync dělá po jednotlivých souborech, což je na pomalých linkách (s vysokou latencí) pro spoustu malých souborů velmi pomalé.
Takže s rsyncem se budou přenášet jen změněné části souborů, případně seznam souborů, pokud mazání souborů necháte na rsyncu. Jak na tom chcete ještě něco ušetřit?
Informace o více souborech přenášet a zpracovávat dávkově - třeba 1000 souborů najednou, tím eliminovat zpoždění způsobené vysokou latencí.
Pokud budete někdy příště znovu zkoušet psát o věcech které znáte pouze teoreticky a nemáte je prakticky vyzkoušené tak na to prosím upozorněte, aby čtenáři věděli že možná zase píšete úplné nesmysly!
-
Takže s rsyncem se budou přenášet jen změněné části souborů, případně seznam souborů, pokud mazání souborů necháte na rsyncu. Jak na tom chcete ještě něco ušetřit?
Zdaleka nejpomalejsi casti prenosu pres rsync bude prave porovnavani/seznam souboru. To trva vyrazne dlouho i lokalne, pri velmi rychle komunikaci. Specielne kdyz je tech souboru hodne.
Tohle vypada jako to, co hleda.
https://btrfs.wiki.kernel.org/index.php/Incremental_Backup
http://docs.opensvc.com/storage.btrfs.html
-
Bohužel jste zamlčel nejpodstatnější věc: to porovnávání rsync dělá po jednotlivých souborech, což je na pomalých linkách (s vysokou latencí) pro spoustu malých souborů velmi pomalé.
Předpokládal jsem, že změněná bude ve skutečnosti jenom malá část souborů. Plyne to z původního dotazu, kde se Peter ptá na přenos změn. Což je přesně to, co rsync dělá. Je zbytečné vymýšlet bůhvíjaké složitosti, když ještě nevyzkoušel rsync, který je přesně na tohle určen a používán.
-
Myslim, ze si trochu nerozumieme. Skusim vysvetlit este raz a vy zase mozete skusit jednat trochu normalnejsie. Ak sa neda, tak nevadi, pochopim, kazdy ma nieco, co je nad jeho schopnosti. Ak v dalsej odpovedi dokazete zformulovat aj nieco konstruktivne, tak pokojne aj v takomto jazyku. ;)
Samozrejme mi ani nenapadlo porovnavat obsahy suborov. Ak ale porovnavam len datumy zmien, tak sa takisto musi rsync opytat na kazdy jeden subor druhej strany a musi to urobit cez siet. Teda urobi velmi vela dotazov, ktore su uplne zbytocne, pretoze v konecnom dosledku zisti, ze na lokalnej strane (na strane odkial uploadujem) sa zmenili len 3 subory. Ak by som mal nejaky lokalny katalog, tak by som vykonal vsetky testy na zmeny bez jedineho requestu po sieti a posieti by som riesil len upload zmenenych suborov alebo nebodaj len casti suborov.
Nerozumím, čemu říkáte "rsync udělá mnoho dotazů". Rsync žádné dotazy nedělá. Při spuštěný rsync udělá na obou stranách seznam souborů, vzdálená strana pošle svůj seznam souborů na iniciační stranu a tam se porovaní. Pro 1000 souborů se třemi změnami tohle nemůže být překážkou. Potom se přes síť pošle jen ona malá změněná část těch vašich 3 souborů.
Rsync žádné binární porovnávání obsahu všech souborů nedělá. (Neurčíte-li jinak. Porovnávání dělá pouze u zdroje a cíle na lokálním stroji (Opět, pokud neurčíte jinak.).)
-
dotaz = zoberie subor na lokale a opyta sa na timestamp vzdialeneho naprotivku, proste to, co vysvetlil pouzivatel Někdo .
Ok, uz nemarnime cas, povodne som sa pytal, ci niekto nepozna nieco, co by si robilo lokalny katalog a nasiel sa tu clovek, co navrhol unison -> moj problem je vyrieseny.
-
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.
-
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?
-
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.
-
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.
-
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.
-
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.
-
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 ;)
-
Mohl bys to nejak objasnit (rezie inotify, nebo neco jineho)?
Objasnit co?
-
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...
-
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á).
-
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.
-
Vterinove timestampy pouzivaji leda tak Widle
Nemelte nesmysly:
C:\>wmic datafile where name="c:\\test.txt" get LastModified
20150329221650.080654+060
-
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?
-
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.
-
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.
-
Přes WebDAV je možné přenášet různé atributy souborů. Nejspíš mezi nimi bude datum a čas poslední modifikace souboru, může tam být také hash. Můžete pak porovnat datum a čas poslední modifikace, případně také hash souboru, a soubor zálohovat jenom tehdy, pokud se změnil. Přenášení pouze změněných částí by musel WebDAV server podporovat pomocí nějakého rozšíření protokolu.
-
Tak to by na Linuixu musela byt nejaka rozumna implementace WebDAVu. Jak jsem si vsiml, neni to zadna slava. Krome to s tim rozsirenim protokolu to asi bude problem, takze WebDAV tedy asi bude pro dane zadani tim nejmene vhodnym.
Osobne bych sahl po rsyncu, i kdyz se tazateli nelibi. Ta linka snad nemuze byt az tak pomala, aby preneseni par kontrolnich souctu bylo katastrofou. A pokud tak pomala je, tak nevim, jestli ma vubec cenu uvazovat o zalohovani po takove lince. To uz je snad lepsi pouzit kabelovy prenos, jak se kdysi praktikoval mezi vypocetnimi stredisky v Paze a Brne, kdyz blblo spojeni modemem po komunistickych dratech s namoklou papirovou izolaci. Tedy data nahrat na medium, strcit do kabely, sednout na autobus a odvezt do Brna.
-
"Nemám po ruke windows, ale platí to aj pre FS FAT pod daným OS?"
Nevim, proc vas zajima zhruba 15 let obsolete FS?
-
Nemám po ruke windows, ale platí to aj pre FS FAT pod daným OS?
NTFS rozlisuje po 100 ns
Proc plkate jednou to a poruhe ono? Pre par posty jste psal ze Win rozlisuji cas po sekundach... Chcete se samoucelne vozit po 15let starem FS? To je dost ubohe...
-
Pardon: 40 let starem, 15 let obsolete.......
-
Nemám po ruke windows, ale platí to aj pre FS FAT pod daným OS?
NTFS rozlisuje po 100 ns
Proc plkate jednou to a poruhe ono? Pre par posty jste psal ze Win rozlisuji cas po sekundach... Chcete se samoucelne vozit po 15let starem FS? To je dost ubohe...
Ja? To snáď nie. Zaujímal som sa len kôli tomu, že sa ten súborový syttém stále používa na kadejakých kartách do fotoaparátov, kamier a občas aj v prehrávačoch. Takže obsolete nie je. A zaokrúhlovanie času dosť spomaľuje zálohu z fat pomocou napríklad rsync.
Takže ako to je na 15 rokov obsolete FS ktorý stále žije, platí to aj na ňom?
-
zaokrúhlovanie času dosť spomaľuje zálohu z fat
Chlapi už to nepijte, nedělá vám to dobře.
-
zaokrúhlovanie času dosť spomaľuje zálohu z fat
Chlapi už to nepijte, nedělá vám to dobře.
On ma a nema pravdu. Vede to k tomu, ze rsync si mysli, ze se jedna o jiny soubor, protoze nesedi timestamp a tak rsync pokazde soubor rovnou kopiruje, i kdyz nebyl zmenen (odtud zpomaleni). Ostatne se ak blbe chova i pri zalohovani ze sdileneho NTFS disku - nejspis timestamp po siti je vracen nejak zaokrouhlen nebo co. Proto se pouziva parametr: --modify-window=1 (vice v man rsync).
-
Tak takhle samozřejmě ano, zaokrouhlování může zmást rsync.
modify-window by pak ale mělo být 2 sekundy, protože FAT zaokrouhluje na 2 sekundy.
-
On ma a nema pravdu. Vede to k tomu, ze rsync si mysli, ze se jedna o jiny soubor, protoze nesedi timestamp a tak rsync pokazde soubor rovnou kopiruje, i kdyz nebyl zmenen (odtud zpomaleni).
Při použití přes síť rsync ve výchozí konfiguraci nekopíruje celý soubor, ale pomocí kontrolních součtů bloků zjistí, které části se změnily, a přenese pouze ty. To je ta nejdůležitější vlastnost rsyncu, proto vznikl. Změnou zaokrouhlování rsyncu se tedy ušetří jenom ten výpočet a přenos kontrolních součtů. Také je to úspora, ale mnohem menší než úspora kopírování celého souboru.
-
Tak takhle samozřejmě ano, zaokrouhlování může zmást rsync.
modify-window by pak ale mělo být 2 sekundy, protože FAT zaokrouhluje na 2 sekundy.
Manual doporucuje 1 a mam to vyzkousene pro sdilene NTFS - chodi to. Ono neni moc jasne, jak ten parametr funguje, ale domnivam se, ze tim mysli plus minus 1, tedy celkem dva. Jinak by to nechodilo.
ři použití přes síť rsync ve výchozí konfiguraci nekopíruje celý soubor, ale pomocí kontrolních součtů bloků zjistí, které části se změnily, a přenese pouze ty. To je ta nejdůležitější vlastnost rsyncu, proto vznikl. Změnou zaokrouhlování rsyncu se tedy ušetří jenom ten výpočet a přenos kontrolních součtů. Také je to úspora, ale mnohem menší než úspora kopírování celého souboru.
Jiste. Jenze na to potrebuje rsync nebo rsyncd i na druhe strane a to na Widlich pri zalohovani pres sdileni neni splneno. Pokud se tedy nedomnivate, ze mluvim o zalohovani NTFS disku pripojeneho k Linuxovemu sroji. To nevim, proc bych delal, krome toho by se muselo jednat o zalohovani pres ssh+rsync nebo pres rsyncd. Vzhledem k tomu, ze jsem napsal "zalohovani ze sdileneho NTFS disku", je snad jasne, ze to jsem nemel na mysli. Rovnez to nepokryva pripad Widli s Cygwin, protoze ani tam by se nejednalo o zalohovani pres sdileni.
-
na Widlich pri zalohovani pres sdileni
V takovém případě se ale nepoužívá ta hlavní přednost rsyncu a rsync bych do toho tím pádem vůbec nemotal, je to akorát matoucí. Pište o tom raději jako o cp -ru, bude to mnohem přehlednější.
-
One Drive neposkytuje rsync nebo rsyncd. Kdyz probiha synchronizace, tak se nejdriv Unison (rsync asi stejne) nejdriv podiva na datum vzdaleneho souboru (+muze dalsi atributy). No a to prave trva dlouho, kdyz takhle kontroluje mraky souboru.
Kdyz vim, ze jsem jediny, kdo soubory na vzdalenem disku modifikuje, tak nepotrebuju, aby pokazde probihala kontrola znovu. Stejne vrati ten samy vysledek jako minule. Stacilo by mi si zapamatovat vysledek kontroly jednou a pouze upravovat dilci data, kdyz se tam ode mne synchronizaci priadji nove nebo zmenene soubory.
-
V takovém případě se ale nepoužívá ta hlavní přednost rsyncu a rsync bych do toho tím pádem vůbec nemotal, je to akorát matoucí. Pište o tom raději jako o cp -ru, bude to mnohem přehlednější.
Kristova noho, Jirsak! Ja sem rsync taham jako priklad situace, kdy vznika problem s timestampy. Vysvetlovat, jak funguje rsync a jak dela kontrolni soucty a prenasi jen zmenene bloky, jste zacal vy. Cili jste zase neco nepochopil, tak nedelejte chytreho.
-
Kdyz vim, ze jsem jediny, kdo soubory na vzdalenem disku modifikuje, tak nepotrebuju, aby pokazde probihala kontrola znovu. Stejne vrati ten samy vysledek jako minule. Stacilo by mi si zapamatovat vysledek kontroly jednou a pouze upravovat dilci data, kdyz se tam ode mne synchronizaci priadji nove nebo zmenene soubory.
Když víte, že jste jediný, kdo soubory modifikuje, nemusíte si u souborů pamatovat vůbec nic, protože datum modifikace souboru si pamatuje souborový systém. Takže si zapamatujete jenom datum a čas, kdy jste naposledy prováděl zálohu, a pak zkopírujete jenom novější soubory. Jediná nevýhoda je, že se takhle nebudou v záloze mazat lokálně smazané soubory. Pro nalezení změněných souborů použijte find -newer případně find -mmin.
-
Ja sem rsync taham jako priklad situace, kdy vznika problem s timestampy. Vysvetlovat, jak funguje rsync a jak dela kontrolni soucty a prenasi jen zmenene bloky, jste zacal vy. Cili jste zase neco nepochopil, tak nedelejte chytreho.
Tazatel se ptal na WebDAV od Microsoftu. Řešit u toho,jak se chová rsync mezi lokálními disky je dost mimo, nemyslíte? A když už to chcete řešit, tak to musíte explicitně napsat, jinak budou ostatní očekávat, že řešíte pořád alespoň něco příbuzného, tedy rsync přes síť.
-
Kdyz vim, ze jsem jediny, kdo soubory na vzdalenem disku modifikuje, tak nepotrebuju, aby pokazde probihala kontrola znovu. Stejne vrati ten samy vysledek jako minule. Stacilo by mi si zapamatovat vysledek kontroly jednou a pouze upravovat dilci data, kdyz se tam ode mne synchronizaci priadji nove nebo zmenene soubory.
Když víte, že jste jediný, kdo soubory modifikuje, nemusíte si u souborů pamatovat vůbec nic, protože datum modifikace souboru si pamatuje souborový systém. Takže si zapamatujete jenom datum a čas, kdy jste naposledy prováděl zálohu, a pak zkopírujete jenom novější soubory. Jediná nevýhoda je, že se takhle nebudou v záloze mazat lokálně smazané soubory. Pro nalezení změněných souborů použijte find -newer případně find -mmin.
Jde nejak presvedcit Unison/Rsync aby zkopiroval pouze tyto soubory?
Jestli nic takoveho neni, tak to beru a muzu si to napsat sam.
-----
pro vsechny lokalni soubory udelat
-- vzit soubor, spocitat CRC a zapsat do databaze spolu s atributy souboru, nazvem a cestou
pro vsechny zaznamy v databazi
-- pokud je neexistuje soubor drive nebo se zmenil CRC, zkopirovat do vzdaleneho disku
-- pokud soubor drive existoval a ted uz ne, smazat z vzdaleneho disku
-----
-
Nemám po ruke windows, ale platí to aj pre FS FAT pod daným OS?
NTFS rozlisuje po 100 ns
Proc plkate jednou to a poruhe ono? Pre par posty jste psal ze Win rozlisuji cas po sekundach... Chcete se samoucelne vozit po 15let starem FS? To je dost ubohe...
Ja? To snáď nie. Zaujímal som sa len kôli tomu, že sa ten súborový syttém stále používa na kadejakých kartách do fotoaparátov, kamier a občas aj v prehrávačoch. Takže obsolete nie je. A zaokrúhlovanie času dosť spomaľuje zálohu z fat pomocou napríklad rsync.
Takže ako to je na 15 rokov obsolete FS ktorý stále žije, platí to aj na ňom?
Pardon, chybne jsem v noci quotoval....
Obsolete to samozrejme je. Ze nekdo stavi storage na 40 let starym FS vypovida spis o nem nez o tom FS ci o jeho tvurci.
-
Jde nejak presvedcit Unison/Rsync aby zkopiroval pouze tyto soubory?
Jestli nic takoveho neni, tak to beru a muzu si to napsat sam.
-----
pro vsechny lokalni soubory udelat
-- vzit soubor, spocitat CRC a zapsat do databaze spolu s atributy souboru, nazvem a cestou
pro vsechny zaznamy v databazi
-- pokud je neexistuje soubor drive nebo se zmenil CRC, zkopirovat do vzdaleneho disku
-- pokud soubor drive existoval a ted uz ne, smazat z vzdaleneho disku
-----
Pokud je to vzdálené úložiště WebDAV, nepoužívejte nad tím žádný Unison nebo Rsync, tím to akorát komplikujete a zpomalujete. Použil bych následující postup:
- vytvořit časovou značku pro příště
- vytvořit seznam souborů pro příště
- přes find -newer najít soubory, které se od minulé časové značky změnily
- nalezené soubory přímo přes WebDAV zkopírovat na vzdálené úložiště
- vytvořit aktuální seznam souborů a porovnat jej s tím dříve uloženým – soubory, které na novějším seznamu oproti minulému chybí přes WebDAV ze vzdáleného úložiště smazat
Jediné zbytečné kopírování, které v tomhle režimu může nastat, je v případě, kdy se soubor změní mezi vytvořením časové značky a vlastním kopírováním – v takovém případě se příště bude kopírovat zbytečně znovu. Předpokládám, že zálohu budete stejně dělat v době, kdy je pravděpodobnost změny souboru nízká, takže bych to neřešil. (Z tohohle důvodu je potřeba dělat časovou značku před začátkem kopírování – kdybyste ji dělal až na konci, nebudete mít v žádné záloze změny, ke kterým došlo během zálohování).
-
ad rychlost linky, prenos atributu atd.: Mam vyzkouseno, ze jen seznam souboru muze mit treba 50MB (a to je bez timestampu). A kdyz se zmeni jen par set kB, tak napr. po 1MBit UPC upload lince to je dost podstatny rozdil.
-
ad rychlost linky, prenos atributu atd.: Mam vyzkouseno, ze jen seznam souboru muze mit treba 50MB (a to je bez timestampu). A kdyz se zmeni jen par set kB, tak napr. po 1MBit UPC upload lince to je dost podstatny rozdil.
Přičemž v tom postupu, který jsem popsal, se žádný seznam souborů nepřenáší.
-
Unison si udržuje lokální DB s hashy souborů, ví, co se na obou stranách změnilo bez nutnosti porovnávání seznamů.
-
Ještě nikdo nenavrhl použít nějaký verzovací systém Teprve pak bude tento thread kompletní :-)
-
Ja sem rsync taham jako priklad situace, kdy vznika problem s timestampy. Vysvetlovat, jak funguje rsync a jak dela kontrolni soucty a prenasi jen zmenene bloky, jste zacal vy. Cili jste zase neco nepochopil, tak nedelejte chytreho.
Tazatel se ptal na WebDAV od Microsoftu. Řešit u toho,jak se chová rsync mezi lokálními disky je dost mimo, nemyslíte? A když už to chcete řešit, tak to musíte explicitně napsat, jinak budou ostatní očekávat, že řešíte pořád alespoň něco příbuzného, tedy rsync přes síť.
Ono je to trochu zložitejšie. Po roku tu niekto vytiahol mrtvolku a opýtal sa na komerčný produkt firmy microsoft. Prečo nevyužil ich podporu, alebo aspoň dokumentáciu je vedľajšie.
-
Ja sem rsync taham jako priklad situace, kdy vznika problem s timestampy. Vysvetlovat, jak funguje rsync a jak dela kontrolni soucty a prenasi jen zmenene bloky, jste zacal vy. Cili jste zase neco nepochopil, tak nedelejte chytreho.
Tazatel se ptal na WebDAV od Microsoftu. Řešit u toho,jak se chová rsync mezi lokálními disky je dost mimo, nemyslíte? A když už to chcete řešit, tak to musíte explicitně napsat, jinak budou ostatní očekávat, že řešíte pořád alespoň něco příbuzného, tedy rsync přes síť.
Ono je to trochu zložitejšie. Po roku tu niekto vytiahol mrtvolku a opýtal sa na komerčný produkt firmy microsoft. Prečo nevyužil ich podporu, alebo aspoň dokumentáciu je vedľajšie.
Mrtvolku jsem vytahl, ale na komercni produkt MS jsem se neptal. To byl priklad pouziti (i kdyz zrovna ted pro me aktualni).
Zkusim si udelat vlastni a kdyz bude k necemu, tak nabidnu ostatnim.
.
-
ad rychlost linky, prenos atributu atd.: Mam vyzkouseno, ze jen seznam souboru muze mit treba 50MB (a to je bez timestampu). A kdyz se zmeni jen par set kB, tak napr. po 1MBit UPC upload lince to je dost podstatny rozdil.
Přičemž v tom postupu, který jsem popsal, se žádný seznam souborů nepřenáší.
To nerozporuju, jen jsem chtel ilustrovat problem.
-
Ja sem rsync taham jako priklad situace, kdy vznika problem s timestampy. Vysvetlovat, jak funguje rsync a jak dela kontrolni soucty a prenasi jen zmenene bloky, jste zacal vy. Cili jste zase neco nepochopil, tak nedelejte chytreho.
Tazatel se ptal na WebDAV od Microsoftu. Řešit u toho,jak se chová rsync mezi lokálními disky je dost mimo, nemyslíte? A když už to chcete řešit, tak to musíte explicitně napsat, jinak budou ostatní očekávat, že řešíte pořád alespoň něco příbuzného, tedy rsync přes síť.
Ono je to trochu zložitejšie. Po roku tu niekto vytiahol mrtvolku a opýtal sa na komerčný produkt firmy microsoft. Prečo nevyužil ich podporu, alebo aspoň dokumentáciu je vedľajšie.
Mrtvolku jsem vytahl, ale na komercni produkt MS jsem se neptal. To byl priklad pouziti (i kdyz zrovna ted pro me aktualni).
Zkusim si udelat vlastni a kdyz bude k necemu, tak nabidnu ostatnim.
.
Pokiaľ si pletieš webDav a SMB disk, tak nechcem vidieť riešenie ktoré vyprodukuješ.
To však nič nemení na tom, že implementácia WebDAV je oveľa pomalšia ako je pri použití rôznych iných sieťových súborových systémov. Preto podobné cloud storrage poskytujú vlastného klienta čo si sám rieši sledovanie zmien súborov a upload ich verzií do cloudu. Vybral si si zle, a pýtaš sa na zlom fóre. Toto naozaj nie je technická podpora MS. I keď nekomentujem na čo sa tu zvrhla celá diskusia.
-
Z meho pohledu je uplne jedno, jestli je to webDav nebo samba share. Proste je to namapovane bud jako disk s pismenkem ve Windows nebo jako adresar ve filesystemu v Linuxu. Pro zalohovaci aplikaci je to transparentni - proste zalohuje z jednoho adresare (rychleho) do druheho (pomaleho).
Reseni, ktere si vyprodukuju jsem tu uz napsal:
-----
pro vsechny lokalni soubory udelat
-- vzit soubor, spocitat CRC a zapsat do databaze spolu s atributy souboru, nazvem a cestou
pro vsechny zaznamy v databazi
-- pokud je neexistuje soubor drive nebo se zmenil CRC, zkopirovat do vzdaleneho disku
-- pokud soubor drive existoval a ted uz ne, smazat z vzdaleneho disku
-----
Sitovou komunikaci resit nepotrebuju, pro aplikaci to jsou jen dva adresare. Zaroven mi to bude fungovat nezavisle na tom, jake vzdalene uloziste si namapuju do filesystemu.
To prece neni tak slozite pochopit, ne?
-
Z meho pohledu je uplne jedno, jestli je to webDav nebo samba share. Proste je to namapovane bud jako disk s pismenkem ve Windows nebo jako adresar ve filesystemu v Linuxu. Pro zalohovaci aplikaci je to transparentni - proste zalohuje z jednoho adresare (rychleho) do druheho (pomaleho).
Předpokládám, že SMB umožňuje zapisovat i do části souboru – že můžete na server poslat příkaz „přepiš bajty 10–20 tímhle: …“. To u WebDAVu nejde, tam musíte vždy zapsat celý nový soubor. To je z hlediska zálohování dost podstatný rozdíl, a dost podstatně to ovlivňuje i tu síťovou komunikaci, která se bude dít pod tím namapovaným diskem.
Sitovou komunikaci resit nepotrebuju, pro aplikaci to jsou jen dva adresare. Zaroven mi to bude fungovat nezavisle na tom, jake vzdalene uloziste si namapuju do filesystemu.
S tímhle přístupem ale riskujete, že budete mít síťové přenosy násobně větší, než kdybyste se síťovou komunikací zabýval. Zvlášť pokud mapujete WebDAV jako klasický disk, hrozí, že se ty soubory budou opakovaně přenášet sem a tam, přestože by stačilo nahrát na server novou verzi nebo dokonce data souboru vůbec nepřenášet.
Použít takové řešení samozřejmě můžete, ale není to řešení vhodné pro pomalou linku, naopak je to řešení pro případ „nebudu nic vymýšlet, na optice je spousta volného pásma“.
-
Reseni, ktere si vyprodukuju jsem tu uz napsal:
Tak to budeš psát přesně ten unison, akorát ten navíc finálně synchronizuje algoritmy rsyncu.
-
Tak to budeš psát přesně ten unison, akorát ten navíc finálně synchronizuje algoritmy rsyncu.
Takže pokud se spustí nad WebDAVem připojeným jako disk, bude se ten soubor přenášet mnohokrát sem a tam.
Myslím, že ta „pomalá linka“ v názvu tématu je součástí zadání, není to cíl, ke kterému se snažíme dojít, ať už bude původně linka jakkoli kapacitní…
-
Tak to budeš psát přesně ten unison, akorát ten navíc finálně synchronizuje algoritmy rsyncu.
Takže pokud se spustí nad WebDAVem připojeným jako disk, bude se ten soubor přenášet mnohokrát sem a tam.
Myslím, že ta „pomalá linka“ v názvu tématu je součástí zadání, není to cíl, ke kterému se snažíme dojít, ať už bude původně linka jakkoli kapacitní…
To ne, ja chci (co nejvice to jde) prenaset data jen jednosmerne. Unison taha i zpatky.
Pripominku s nemoznosti castecneho prepisu pres WebDav beru - nevedel jsem to. Musim rict, ze me ani nenapadlo zkouset sam prepisovat pouze cast souboru. Taky je to tim, ze tam asi nemam zadny velky soubor s malymi zmenami. Treba na virtualni disk by to byl velky problem.
Skoda, ze nemuzu pouzit original synchronizacniho klienta. (deaktivovan u nas centralne).
-
A nestačil by parametr --fastcheck?
-
To ne, ja chci (co nejvice to jde) prenaset data jen jednosmerne. Unison taha i zpatky.
Unison umí tahat i jen jednosměrně a i přitom využívá svou lokální databázi již přenesených změn. Parametr --force http://superuser.com/a/296663
-
To ne, ja chci (co nejvice to jde) prenaset data jen jednosmerne. Unison taha i zpatky.
Unison umí tahat i jen jednosměrně a i přitom využívá svou lokální databázi již přenesených změn. Parametr --force http://superuser.com/a/296663
Ted to testuju, dekuju za napad.
Unison -force localfolder localfolder remotefolder
Vypada to ale, ze to stale testuje zmeny souboru v obou adresarich
S parametrem fastcheck true je to znatelne rychlejsi, ale stejne to zrejme saha na remotefolder a taha datum modifikace a delku souboru
-
Tak se omlouvam - treti synchronizace uz je velmi rychla - podstatne rychlejsi nez prvni (jasne, kopiruje se), ale i nez druha, kde se uz nic nezmenilo.
Uvidim jeste, jestli si necha ulozeny stav neomezene dlouho, nebo jen urcity cas.
-
Jeste mozna zkuste mrknout sem: https://github.com/egorFiNE/bigsync/blob/master/README.md
Je to neco, jako zsync, ale pro upload. Je to sice puvodne navrzeno na velke soubory, ale to by asi nevadilo, da se nastavit velikost bloku. Kazde spusteni prenasi jen jeden soubor, ale to by slo doskriptovat. Akorat je otazka, kde a jak to uklada ty kontrolni soucty, protoze jestli to je pohromade s temi zdrojovymi soubory, tak to by byl asi trochu bordel. Takze by to nekdo musel preorat, aby je to ukladalo jinde.
-
Dobrý den,
pěkná diskuze, když jsem v tom, chci se Vás zeptat, mám lokalní adresář ve kterém se pravidelně v noci ukládájí data, vždy v přesný čas, jak vhodně tento adresář zálohovat na FTP, aktuálně používám jednoduchý vlastní script v bash, ale problém je, že starší podadresáře musím na FTP mazat, protože to není 1:1 kopie, občas nějaký podadresář ve zdroji dat se odstraní, lze to synchronizovat směřem na FTP jako přesnou kopii, např. mountovat FTP a pak to dělat přes rsync? Umí rsync smazat soubory co nejsou v source datech?
Artom
-
man rsync. Mazat samozrejme umi.
--delete delete extraneous files from dest dirs
--delete-before receiver deletes before xfer, not during
--delete-during receiver deletes during the transfer
--delete-delay find deletions during, delete after
--delete-after receiver deletes after transfer, not during
--delete-excluded also delete excluded files from dest dirs
Ale pres namontovany FTP si rsyncu moc neuzijete. Bez podpory na druhe strane to neni ten spravny orgasmus.
-
OK, ale co s tím, když na truhé straně je pouze FTP, myslel jsme, že lze rsync pustit na lokalní adresáč a jako cíl mu předhodit ten FTP mount a říct mu, synchronizuj a co je navíc v destination proti source tak to smaž, vlastně z toho pohledu je to jen porovnání dvou adresářů, to zkusím s nějakým diff.
man rsync. Mazat samozrejme umi.
--delete delete extraneous files from dest dirs
--delete-before receiver deletes before xfer, not during
--delete-during receiver deletes during the transfer
--delete-delay find deletions during, delete after
--delete-after receiver deletes after transfer, not during
--delete-excluded also delete excluded files from dest dirs
Ale pres namontovany FTP si rsyncu moc neuzijete. Bez podpory na druhe strane to neni ten spravny orgasmus.
-
OK, ale co s tím, když na truhé straně je pouze FTP, myslel jsme, že lze rsync pustit na lokalní adresáč a jako cíl mu předhodit ten FTP mount a říct mu, synchronizuj a co je navíc v destination proti source tak to smaž, vlastně z toho pohledu je to jen porovnání dvou adresářů, to zkusím s nějakým diff.
Ano, to mozne je. Akorat kdyz mate FTP server namontovany pres nejaky bazmek, jako nejaky ftpfs, tak nevyuzijete hlavni vyhodu rsync, tedy prenaseni pouze zmenenych bloku. Na to potrebujete rsync i z druhe strany a ulozist, ktere tohle maji, je strasne malo a zadara jsem nenasel zadne. Soudruzi uloznici totiz dosud nepochopili, ze by to bylo vyhodne i pro ne, protoze ne kazdy chce pouzivat jejich uchylne synchronizacni utility a rsync by jim usetril bandwidth.
-
obcas to resim, at nemusim vymyslet kolo - nemate tip na nejake RSYNC placene uloziste - nejlepe vyzkousene ?
gugl nasel : https://www.google.cz/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=rsync%20storage%20online (https://www.google.cz/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=rsync%20storage%20online)
treba tenhle nabizi free up to 1 GB 'taste plane'
https://www.strongspace.com/plans (https://www.strongspace.com/plans)
dik
-
Tak nakonec se Unison prece jenom neukazal jako pouzitelne reseni.
V default nastaveni (tj. nerikam, ze urcite nejde nastavit, tolik casu jsem tomu nedal)
- nenastavuje spravne datum zalozeni a posledni modifikace souboru
- nektera uloziste neumoznuji pouzit urcite znaky (priklad #), je potreba je prekladat
- je to porad pomale
delam testy se svym velmi omezenym resenim (lokalni databaze + lokalni klient, uloziste uplne hloupe). Jestli to nekoho zajima, tak muzu hodit detaily.
-
obcas to resim, at nemusim vymyslet kolo - nemate tip na nejake RSYNC placene uloziste - nejlepe vyzkousene ?
Používám Axfone Disk (https://www.axfone.cz/produkty-a-sluzby/hostingove-sluzby/axfone-disk/).
-
Tak nakonec se Unison prece jenom neukazal jako pouzitelne reseni.
V default nastaveni (tj. nerikam, ze urcite nejde nastavit, tolik casu jsem tomu nedal)
- nenastavuje spravne datum zalozeni a posledni modifikace souboru
- nektera uloziste neumoznuji pouzit urcite znaky (priklad #), je potreba je prekladat
- je to porad pomale
delam testy se svym velmi omezenym resenim (lokalni databaze + lokalni klient, uloziste uplne hloupe). Jestli to nekoho zajima, tak muzu hodit detaily.
Určitě mě/nás to zajímá, zálohování po pomalé lince je velice zajímavé.
Jakákoliv linka se totiž může zdát pomalá, záleží na velikosti a struktuře dat.
Mě by například zajímalo, jak zálohovat pouze rozdíly při záloze obrazů virtuálních strojů.
-
Mě by například zajímalo, jak zálohovat pouze rozdíly při záloze obrazů virtuálních strojů.
Můžete použít klasický rsync nebo třeba mít obrazy virtuálních strojů na souborovém systému btrfs a zálohovat jeho snapshoty.
-
Mě by například zajímalo, jak zálohovat pouze rozdíly při záloze obrazů virtuálních strojů.
Můžete použít klasický rsync nebo třeba mít obrazy virtuálních strojů na souborovém systému btrfs a zálohovat jeho snapshoty.
Tohle je zrovna velky problem. (ja ho pro me neresim, protoze tam tak velke soubory nemam)
1) hloupe uloziste neposkytuje sluzby jako rsync
2) jak jsem byl poucen, webdav neumi nahravat soubory po castech
3) cely soubor pokazde nahravat nechceme
Nekde v predchozich prispevcich byl odkaz na program, ktery umi nahravat soubory po castech, pokud to filesystem podporuje.
Pripadne muze zkust Borg backup. Ten podle popisu podporuje hloupe uloziste, ale nahrava data ve svem formatu (tj, neprectej je bez toho programu)
-
Tohle je zrovna velky problem. (ja ho pro me neresim, protoze tam tak velke soubory nemam)
1) hloupe uloziste neposkytuje sluzby jako rsync
2) jak jsem byl poucen, webdav neumi nahravat soubory po castech
3) cely soubor pokazde nahravat nechceme
Nekde v predchozich prispevcich byl odkaz na program, ktery umi nahravat soubory po castech, pokud to filesystem podporuje.
Pripadne muze zkust Borg backup. Ten podle popisu podporuje hloupe uloziste, ale nahrava data ve svem formatu (tj, neprectej je bez toho programu)
Tohle byl ale nový dotaz, dotyčný tam nepsal nic o tom, že nemůže použít rsync. A pokud použije btrfs snapshoty, bude ukládat jen přírůstkové soubory, takže od úložiště potřebuje jenom to, aby umělo uložit soubor.
To je problém téhle diskuse, že už jsou tady postupně tři dotazy a každý na něco jiného…
-
Napada me silenost typu:
1) udelate dump celeho fs
2) prenesete na druhou stranu a udelate restore
3) na primaru udelate snapshot a pak pres dump delate puze incrementy (dump umi levelovani)
4) prenesete na druhou stranu a delate restore.
5) body 3-4 delate porad do kola a sem tam to prolozite full backupem (pro sichr)
Nikde v praxi jsem to nevidel a je to bastl :). V enterprise sfere se pouziva bud incremental forever (TSM), jurnal incremental forever(taky TSM) sem tam nekde subfile backup (pouze na urcitejch adresarich). Je dobre si tez spocitat/odhadnout jak velke jsou prirustky a jak dlouho se vam budou prenaset.
-
Tohle je zrovna velky problem. (ja ho pro me neresim, protoze tam tak velke soubory nemam)
1) hloupe uloziste neposkytuje sluzby jako rsync
2) jak jsem byl poucen, webdav neumi nahravat soubory po castech
3) cely soubor pokazde nahravat nechceme
Nekde v predchozich prispevcich byl odkaz na program, ktery umi nahravat soubory po castech, pokud to filesystem podporuje.
Pripadne muze zkust Borg backup. Ten podle popisu podporuje hloupe uloziste, ale nahrava data ve svem formatu (tj, neprectej je bez toho programu)
Tohle byl ale nový dotaz, dotyčný tam nepsal nic o tom, že nemůže použít rsync. A pokud použije btrfs snapshoty, bude ukládat jen přírůstkové soubory, takže od úložiště potřebuje jenom to, aby umělo uložit soubor.
To je problém téhle diskuse, že už jsou tady postupně tři dotazy a každý na něco jiného…
Souhlas, je v tom zmatek. Predpokladam ale, ze kdyby mu na druhe strane bezel rsync, tak uz se nepta. (plus odpovidal na muj prispevek, tedy na podvlakno s hloupym ulozistem)
Sehnat uloziste s rsync je ale docela slozite, pokud nemate svuj vlastni server.