Fórum Root.cz
Hlavní témata => Server => Téma založeno: Honza1 16. 02. 2017, 15:29:31
-
Zdravim
Chtel bych se zeptat, co je nejlepsi pri prenosu dat na server, ze serveru, mezi servery.
Jde o to, aby nevznikala pri prenosu chyba (hash kontrola ?) a zpusob byl relativne odolny proti nestabilite internetu a kratkym vypadkum.
U velkych souboru chybi moznost navazani v pripade preruseni, u pomalych rychlosti a s nestabilnim netem nejde prenest cely soubor najednou.
To ze nesmi byt zmena v souboru mezi zacatkem a koncem prenosu je jasne.
Pouzivam mc, tam je nevyhoda, ze soubor je kopirovan do tmp, coz zbytecne zere systemove prostredky, mc je docela odolny proti kratkym vypadkum, po znovu-rozbehnuti netu pokracuje, po preruseni provoz navazat jsem neprisel jak.
Pouziti torrent protokolu nebude moc fungovat (ani moc netusim jak na to), i kdyz splnuje vsechny pozadavky a dobre funguje v nestabilni siti. Sitari tento protokol nemaji radi kvuli castemu "zneuzivani" a byva i zakazan.
Resenim by mohlo byt scp, nemam tolik zkusenosti s nim.
Co pouzivate vy ?
-
Na takové přenosy používám rsync. Je bezpečný, protože používá protokol SSH, umí navázat přerušené spojení a sám kontroluje správné kontrolní součty v souborech. Pokud něco nesedí, umí si sám zasynchronizovat jen rozdíly. Podle mě je to přesně to, co hledáš.
-
rsync
http://superuser.com/questions/302842/resume-rsync-over-ssh-after-broken-connection
-
Jestli ty soubory maji byt velke, tak radsi rsync -z.
-
... umí navázat přerušené spojení ...
Jak? Asi jsem neco v manualu prehledl, je dlouhy jak lovosice.
-
Pokud se použije parametr --append, nechá si příjemce i data, která nebyla poslána kompletně. Pak stačí přenos pustit znovu a budou se přenášet jen ta data, která protistrana ještě nemá. Jsou tam ještě další zajímavé parametry, jako třeba --partial.
-
Aha: This causes rsync to update a file by appending data onto the end of the file, which presumes that the data that already exists on the receiving side is identical with the start of the file on the sending side. If a file needs to be transferred and its size on the receiver is the same or longer than the size on the sender, the file is skipped.
To bych se asi bal pouzit. Kdyz mi na zdrojovem souboru zatim nekdo kus umaze, tak se to nesesynchronizuje. Pokud sedi velikost, ale zmeni se obsah, tak take. Takz kdyz --append, tak leda nasledne pustit rsync bez --append a vynutit kontrolu vsech souboru podle checksumu. A to nevim, jestli se vyplati.
-
Mno a nebo to nejdriv ... zazipujes/zararujes/... rozparcelujes na rozumne velky casti a na druhy strane rozbalis, cimz zaroven overis, ze je to OK. Pripadne se jeste da pouzit neco na tema https://alternativeto.net/software/quickpar/ coz ti vysledek nejen zkontroluje, ale v zavislosti na nastaveni i vyleci (samo za cenu zvetseni objemu).
-
Aha: This causes rsync to update a file by appending data onto the end of the file, which presumes that the data that already exists on the receiving side is identical with the start of the file on the sending side. If a file needs to be transferred and its size on the receiver is the same or longer than the size on the sender, the file is skipped.
To bych se asi bal pouzit. Kdyz mi na zdrojovem souboru zatim nekdo kus umaze, tak se to nesesynchronizuje. Pokud sedi velikost, ale zmeni se obsah, tak take. Takz kdyz --append, tak leda nasledne pustit rsync bez --append a vynutit kontrolu vsech souboru podle checksumu. A to nevim, jestli se vyplati.
Z man rsync:
--append-verify
This works just like the --append option, but the existing data on the receiving side is included in the full-file checksum verification step, which will cause a file to be resent if the final verification step fails
(rsync uses a normal, non-appending --inplace transfer for the resend).
Note: prior to rsync 3.0.0, the --append option worked like --append-verify, so if you are interacting with an older rsync (or the transfer is using a protocol prior to 30), specifying either append option will initi‐
ate an --append-verify transfer.
-
Mno a nebo to nejdriv ... zazipujes/zararujes/... rozparcelujes na rozumne velky casti a na druhy strane rozbalis, cimz zaroven overis, ze je to OK..
To se ale hodi leda tak na prvotni prenos dat, pokud mam na cili dost mista. Pro pozdejsi sync je to uplne na hovno, protoze se bude syncovat mnohem vetsi objem dat, nez by bylo nutne.
-
Z man rsync:
--append-verify
This works just like the --append option, ...
Ano, videl jsem. Ale tady uz nechapu, co mi to prinese ve srovnani se spustenim rsyncu bez jakehokoliv --append parametru. Nejak to tam nerozpitvavaji, ale mam pocit, ze uz to vyjde prakticky na jedno kopyto.
-
zkus flash disk, to by mohlo splnovat pozadavky
-
Diky, ten rsync vyzkousim. Melo by to jit.
Zabalit do archivu, ktery bude rozdeleni na male casti, to je dobry napad. Jednotlive casti archivu maji jen treba 1 MB nebo 10 MB a po preruseni spojeni se muze navazat (prepisou se soubory, kde se lisi velikost, tedy nejsou kompletni). Rozbalenim pak overim, ze cely prenos je v poradku, stejne tak jako testem archivu.
-
(prepisou se soubory, kde se lisi velikost, tedy nejsou kompletni).
Jeste si ten manual trochu prectete. Prepisou se pouze bloky, kde nesedi checksum.
-
Zabalit do archivu, ktery bude rozdeleni na male casti, to je dobry napad. Jednotlive casti archivu maji jen treba 1 MB nebo 10 MB a po preruseni spojeni se muze navazat (prepisou se soubory, kde se lisi velikost, tedy nejsou kompletni).
To je zbytečně málo. Při --partial (a ještě doporučuju --inplace) rsync lišící se soubory přečte a dotáhne jenom rozdíly. Rozdělovat kvůli výkonu (a hlavně diskovému I/O) má cenu na jednotky až desítky GB, nikoli MB.
Rozbalenim pak overim, ze cely prenos je v poradku, stejne tak jako testem archivu.
Kontrola asi neuškodí, ale rsync checksum souborů kontroluje sám.
-
Kontrola asi neuškodí, ale rsync checksum souborů kontroluje sám.
Pokud je nekdo nervozni, ze mohlo dojit k chybe, tak lze vynutit kompletni kontrolu i u souboru, kde sedi cas a velikost: --checksum a nejspis by to udelal i --ignore-times.
Pokud souboru neni mnoho, tak si lze nechat spocitat md5sum na obou koncich a jednoduse mrknout, jestli to sedi.
-
"Chtel bych se zeptat, co je nejlepsi pri prenosu dat na server, ze serveru, mezi servery.
hash kontrola ?......odolny proti nestabilite internetu...u velkych souboru moznost navazani v pripade preruseni......."
Nejjednodussi pro tebe asi bude pouzit tohle
https://en.wikipedia.org/wiki/Syncthing -->Efficient syncing is achieved via compression of metadata or all transfer data, block re-use and lightweight scanning for changed files, once a full hash has been computed and saved.
https://syncthing.net/ --> Simple. Syncthing doesn't need IP addresses or advanced configuration: it just works, over LAN and over the Internet. Every machine is identified by an ID. Just give your ID to your friends, share a folder and watch: UPnP will do if you don't want to port forward or you don't know how. Synchronize as many folders as you need with different people.
Kdyz se ptas na velky soubory tak tipuju ze chces zalohovat na server naky videa, bitmapy apod.
Sam to pouzivam na serveru ze kteryho semi replikujou files do founu, pripadne kdyz chci nekomu nasdilet neco tak mu to nasypu do jeho folderu co ma vyhrazenej na serveru a on kdyz si zapne PC a pripoji na net tak se mu to nareplikuje do jeho lokalniho folderu.
Ma to autentifikaci obou stran, je to sifrovany a vyvojar je Sved sedici ve Svedsku.
Vzniklo to jako open-source alternativa k uzavrenymu https://en.wikipedia.org/wiki/Resilio_Sync ktery taky funguje dobre a to zejmena k volnemu sireni napr.podcastu po svete, protoze nepotrebuje "pridani kontaktu/autentizaci druhe strany", ale u ktereho kdyz byli tvurci dotazani jak protokol funguje tak se akorat vzdycky kroutili jak uzovky a misto odpovedi poslali jen PR kecy.
"Pouziti torrent protokolu - netusim jak na to......Sitari tento protokol nemaji radi kvuli castemu "zneuzivani" a byva i zakazan..."
To se da obejit prenastavenim standartnich znamych BT portu na jine, ci zapnutim "protocol obfuscation" v nekterych klientech. Pouzivani DHT taky pomaha protoze BT klient komunikuje ciste P2P a nepinka pravidelne urcite tracker-IP cehoz si ISP muze snadno vsimnout. Samozrejme ze pres DPI se da odhalit ledacos ale na HW toho typu vetsina ISP v CR nema $.
Tohle pouzivaj big ISP v USA kdy ti schvalne kriplej BT anebo Skype aby ti pak nasledne mohli vnutit jejich vlastni sluzby poskytujici to samy samozrejme za patricne vypalne.
"Sitari tento protokol nemaji radi..."
Dokud plati net-neutrality tak je sitarum kulovy do toho jaky protokoly chtes ty jako zakaznik provozovat -pokud nejde o firemni sit, tam rozhoduje majitel protoze ty nejsi zakaznik ale zamestnanec ;)
Sitari se maj hlavne starat o stabilitu site a nizkou latenci. BT protokol nemaj obvykle ISP radi predevsim proto, ze dokaze vyuzit do mrte pridelenou bandwidth a kdyz to takle udela vic useru tak se v plny nahote ukaze ze milej ISP slibuje a kasiruje od BFU za trafik kterej vubec neni schopnej dodat (overselling)
http://stopthecap.com/2011/01/31/when-providers-oversell-the-network-paying-for-10mbps-service-getting-1-2mbps-service-instead/
-
jeste na doplneni-NextCloud (coz je novy projekt od lidi co puvodne vyvijeli OwnCloud do doby nez je v nejlepsim kapitalistickem stylu z iluzi vylecili US angel-investors) ma taky zabudovanou funkci pro sdileni souboru.....
BTW- tady je srovnani ruznych softu: https://en.wikipedia.org/wiki/Comparison_of_file_synchronization_software