Přenos velkých souborů mezi servery

[Honza1]

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 ?

[Reklama]

[Petr Krčmář]

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áš.

[drn]

rsync

http://superuser.com/questions/302842/resume-rsync-over-ssh-after-broken-connection

[JardaP .]

Jestli ty soubory maji byt velke, tak radsi rsync -z.

[JardaP .]

... umí navázat přerušené spojení ...

Jak? Asi jsem neco v manualu prehledl, je dlouhy jak lovosice.

[Reklama]

[Petr Krčmář]

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.

[JardaP .]

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.

[j]

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

[rsync]

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.

[JardaP .]

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.

[JardaP .]

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.

[flash]

zkus flash disk, to by mohlo splnovat pozadavky

[Honza1]

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.

[JardaP .]

(prepisou se soubory, kde se lisi velikost, tedy nejsou kompletni).

Jeste si ten manual trochu prectete. Prepisou se pouze bloky, kde nesedi checksum.

[Jenda]

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.