Zálohování po pomalé lince

[peter]

@JardaP moja rozvlacna reakcia s komentarom na temu normalne jednanie bola urcena cloveku pod menom Lol Phirae, priamo pod vasou reakciou sa ocitla omylom.

[Reklama]

[Pavouk106]

@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.

[JardaP .]

@peter: Koukal jste na unison? Podotykam, ze manual jsem zase necetl, ale zanesla se ke mne ozvena....

[peter]

@JardaP ano, robi to co potrebujem, dik za  tip.

[Pavouk106]

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?

[Reklama]

[andy]

Je uz toto stabilne? http://docs.oracle.com/cd/E37670_01/E37355/html/ol_sendrecv_btrfs.html

[peter]

@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.

[dustin]

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:

Kód: [Vybrat]

#! /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


[Filip Jirsák]

- 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?

[JardaP .]

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.

[Někdo]

- 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!

[j]

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

[Filip Jirsák]

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.

[Tomáš Crhonek]

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.).)

[peter]

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.