Dotaz: Dva NASy, dve lokality, pomala linka a externi disk

[petrfm]

Ahoj, kuriozni problem, ktery ma mozna snadne reseni. Mam dva nasy v ruznych lokalitach, na kterych bych mel rad stejny obsah. Fungovalo by to zaroven jako zaloha v jine geograficke lokalite. Jeden NAS je doma, druhy v praci.

V praci mam rychlou linku, takze stahuju hudbu, filmy, fotky, nekdy tam stahuju videa z kamery, atd.

Doma bude taky NAS s linuxem, ale hooodne pomala linka - wifi, jen cca 4Mb/s, takze nehrozi ty rozdily tahat po netu.

Jak synchronizovat ty dva NASy, aby mely stejny obsah? Rad bych jednou za cas (1x tydne) pripojil 1TB externi disk a udelal ten prenos offline. Napadlo mne, linkovat novinky do slozky - ZALOHOVAT a pak je jen mezi sebou zkopirovat, proste nahrat na druhy NAS.

Jenomze to je pakarna a bude mne to bavit 2x, navic kdo ma furt delat ty symlinky a pak je mazat, atd. Proto by to chtelo chytrejsi reseni, automaticke, nejakym zalohovacim nastrojem, ktery by si vyexportoval seznam souboru a jednoduse by mi po pripojeni disku nakopiroval to, co se lisi od obsahu druheho NASu. Pak bych ten disk vzal, pripojil k druhemu nasu, ten by si SAM nasel nove soubory a ulozil je do slozek.

Uplne idealni by bylo, kdyby to dokazalo treba male zmeny <1GB synchronizovat samo, pres net a vetsi soubory nachystat na prenos pres disk.

Resili jste nekdy takovou situaci? jak a cim?

Odpovědi

[NN]

Obycejny rsync a rozdilove kopirovani?

[petrfm]

Tomu bych rozumel, kdybych ty data posilal po siti. Ale jak to dostat na externi disk a potom z nej na cilovem nasu ty rozdily nacist?

Tohle asi moc lidi neresi, ani google moc neporadil Dalsi reseni by bylo, mit 1:1 kopii na tom externim disku. Jenze NAS by mel mit 4TB a externi disk jen 1TB - cili potreboval bych, aby to skutecne ukladalo jen rozdily a aby si to idealne porovnavalo ty soubory budto primym spojenim mezi temi nasyy - to by slo zaridit, nebo pomoci nejakeho souboru, ulozeneho na webu.

[pavele]

unison

[dustin]

Přesně tak, unison zvládá synchronizovat i po docela pomalých linkách, používáme je pro tyto účely spoustu let. Je i překvapivě rychlý, stovky GB mezi souborovými servery na filiálkách synchronizujeme každých 10 minut a stíhá (samozřejmě změny jsou v běžném rozsahu kancelářských souborů a trochu videí). Jen je potřeba sledovat jeho logy a ručně řešit případné konflikty.

[NN]

Odkdy funguje rsync pouze po siti?

[Jan Kratochvíl]

Já bych to řešil rsyncem, nějak bych omezil rychlost (shaper), aby ti to nezabilo tu wifinu a i kdybys to jel na 1Mbit, tak za tejden to přenese 60Giga...

[chsajarsa]

rsync ma prepinac --bwlimit na omezeni rychlosti i v sobe. Tento prepinac funguje i pokud pustite rsync jako daemona.

[petrfm]

Mozna by to bylo reseni. Dokaze si to ale poradit s vypadky site? Navazat samo spojeni, atd? Ta wifi je fakt dost nestabilni, nekdy to jede, nekdy ne, nekdy to vypadne uplne a to posledni, co bych chtel delat, neustale nahazovat spojeni na nejakem zalohovacim bazmeku.

Jinak je fakt, ze kdyby se to nastavilo trvale, s tim, ze by to v noci, treba od 1-6h prikourilo rychlost na 4Mb, tak by to mozna i stacilo. Velke zmeny bych si pamatoval / ukladal rucne do nejakeho extra adresare a prenasel na disku no a ty male zmeny by se kopirovaly samy.

Rychlost jsem v nejhorsim schopny omezit na routeru - bude na obou bodech mikrotik.

[dustin]

Díval ses na ten unison? Ten je přímo určen k oboustranné synchronizaci velkých úložisť, udržuje si na obou stranách databázi o svých souborech. S rsyncem budeš bojovat, protože není primárně určený pro oboustranné změny. Jinak unison pro vlastní přenos změn používá algoritmus rsyncu, takže je to stejně efektivní.

Tenhle skript spouštíme na jedné straně v cronu:

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/share/ ssh://remote.adresa.cz//srv/samba/share/  2>&1 | tee -a /root/sync.log | egrep -i '<-\?->|failed:|has been modified' | grep -vi '^props'
fi

Je samozřejmě potřeba, aby se root přihlásil přes ssh pod rootem na druhé straně klíčema. Nemusí to běžet pod rootem, pokud nepotřebuješ nastavovat i práva (což mi potřebujeme). Nejlépe přes nějakou vpnku, pak lze místo ssh volat nešifrovaný unison server rovnou po síti a je to možná i trochu rychlejší. Tutoriál např. http://www.markus-gattol.name/ws/unison.html

Omezení přenášeného pásma pomocí trickle např. http://pauldreik.blogspot.cz/2012/08/bandwidth-limit-ssh.html

[petrfm]

VPNka tam jede, asi bych nelajznul pustit SSH na verejne IP. Nemam tam defakto nic pristupneho z venku, mimo 80tky a te VPNky. Cili bych si asi vytvoril extra konto jen pro ten nas.

Jak rikam, na obou stranach bude mikrotik, takze mozna bude jednodussi omezovat rychlost na nem. (da se defakto priskrtit konkretni ucet na VPNce) navic to pujde jednoduse merit, zobrazovat v grafu, apod.

Jinak na unison jsem koukal a ano, asi pujdu do nej.

[zly clovek]

Tahleta obava poustet SSH ne verejne IP adrese je dost komicka. Zvlaste, kdyz tam bezi neco urcite okamzite zaplatovane na portu 80. Nebojite se treba, ze nekdo umi poslat takova data, ze pri prutoku skrz AX procesor zesili, nenapadne vybehne zadem bedny a ukousne obsluze p..el?

[dustin]

OK. Při komunikaci přes vpn (tedy již šifrované) se mi osvědčilo přes (x)inetd spouštět unison --server (např. http://www.cis.upenn.edu/~bcpierce/unison/download/resources/xinetd-chroot-howto.txt ), místo dalšího šifrovaného spojení v rámci vpnky přes ssh. Samozřejmě to pak chce ten port firewallem omezit na IP adresu primárního serveru atd...

[kdave]

Na to by se dal pouzit btrfs send/receive, ten umi ulozit seznam zmen mezi dvema stavy filesystemu (zaznamenanymi jako snapshot) tak, aby se jeho aplikaci na cilovem filesystemu dostahlo stejneho obsahu. A ten seznam zmen je binarni stream, da se ulozit do souboru (i kdyz se spis casteji pouziva pres pipe/sit).

Po prvnim prenosu, kdy je potreba prenest v podstate cely filesystem, se uz pocitaji jen inkrementalni zmeny. Na zdroji i cili je potreba vzdy udrzovat alespon posledni snapshot. Pri prenosu se udela snapshot soucasneho stavu, mezi nimi se udela send. Na cili se provede receive, coz vyrobi snapshot se stejnym obsahem jako ma zdroj. Po prenosu se muzou stare snapshoty smazat.

Nevim, jestli je na to nejaky hotovy tool, ale neni to nic sloziteho na naskriptovani.

Predpoklada to pouziti btrfs (nebo zfs, umi totez, nezkousel jsem), coz muze byt problem s prekonvertovanim dat z jineho filesystemu, kdyz pominu otazky stability a neduvery k novemu filesystemu.