Vraag De snelste manier om 55 GB aan afbeeldingen over te zetten naar een nieuwe server


Ik heb momenteel twee CentOS-servers. Ik moet weten hoe en wat de snelste manier zou zijn om de images directory te "targen" en het SCP erover heen?

Is dat de snelste manier die ik zojuist heb voorgesteld, omdat tarring voor altijd duurt ... Ik heb het commando uitgevoerd:

tar cvf imagesbackup.tar images

En ik wilde het gewoon overnemen.

Laat me weten of er een snellere manier is. Ik heb remote / SSH-toegang tot beide machines.


61
2017-12-02 12:39


oorsprong


Sneakernet? - Nick T
Zien unix.stackexchange.com/questions/227951/... - rogerdpack


antwoorden:


In plaats van tar te gebruiken om naar uw lokale schijf te schrijven, kunt u met SSH rechtstreeks naar de externe server via het netwerk schrijven.

server1$ tar -zc ./path | ssh server2 "cat > ~/file.tar.gz"

Elke reeks die volgt op uw "ssh" -opdracht zal worden uitgevoerd op de externe server in plaats van de interactieve aanmelding. Je kunt input / output van en naar die externe commando's via SSH pipen alsof ze lokaal waren. Door de opdracht tussen aanhalingstekens te plaatsen, vermijdt u elke verwarring, vooral wanneer u omleiding gebruikt.

Of u kunt het tar-bestand direct op de andere server extraheren:

server1$ tar -zc ./path | ssh server2 "tar -zx -C /destination"

Let op de zelden gebruikte -C keuze. Het betekent "eerst deze map veranderen voordat je iets doet".

Of misschien wilt u "trekken" van de doelserver:

server2$ tar -zx -C /destination < <(ssh server2 "tar -zc -C /srcdir ./path")

Merk op dat de  <(cmd)  construct is nieuw voor bash en werkt niet op oudere systemen. Het voert een programma uit en stuurt de uitvoer naar een pipe, en vervangt die pipe in het commando alsof het een bestand was.

Ik had het bovenstaande eenvoudig als volgt kunnen schrijven:

server2$ tar -zx -C /destination -f <(ssh server2 "tar -zc -C /srcdir ./path")

Of als volgt:

server2$ ssh server2 "tar -zc -C /srcdir ./path" | tar -zx -C /destination

Of u kunt uzelf wat verdriet besparen en gewoon rsync gebruiken:

server1$ rsync -az ./path server2:/destination/

Vergeet ten slotte niet dat het comprimeren van de gegevens vóór de overdracht uw bandbreedte zal verminderen, maar bij een zeer snelle verbinding kan het de handeling zelfs tot een goed einde brengen. meer tijd. Dit komt omdat uw computer mogelijk niet snel genoeg comprimeert om bij te houden: als comprimeren 100 MB duurt langer dan nodig is sturen 100 MB, dan is het sneller om het ongecomprimeerd te verzenden.

U kunt ook overwegen piping om uzelf te gzippen (in plaats van de optie -z te gebruiken), zodat u een compressieniveau kunt opgeven. Het is mijn ervaring dat bij snelle netwerkverbindingen met comprimeerbare gegevens, gzip op niveau 2 of 3 (de standaardinstelling is 6) de beste algehele doorvoer in de meeste gevallen geeft. Zoals zo:

server1$ tar -c ./path | gzip -2 | ssh server2 "cat > ~/file.tar.gz"

90
2017-12-03 10:44



Rsync werkte prachtig - comprimeert on-the-fly, kopieert hele mappen, wordt hervat via een verbroken link. Alles in één eenvoudige opdracht. Hou ervan. Dit zijn de opties die ik nuttig vond: z: comprimeren r: recurse = kopie submap v: uitgebreid. Mijn Rsync-opdrachtvoorbeeld: rsync -azvr / src-path / gebruikersnaam @ dest_server: / dest / path / - Bastion


Ik zou in de verleiding komen om het over mijzelf te rsyncen - het doet compressie en behandelt koppelverlies goed.


67
2017-12-02 12:47



rsync is precies het juiste hulpmiddel. - Rich
+1 - Yay rsync! - Evan Anderson
+1, gewoon om op te stapelen. Bovendien hou ik erg van rsync. - Steven Monday
Maar wanneer u rsync gebruikt, moet u gegevens toch handmatig comprimeren (als u uw gegevens wilt opslaan) - wlk
Hoe kun je het gecomprimeerde bestand opslaan met rsync? - Dolan Antenucci


Als je ze gewoon op de grond zet en niets anders, dan verspilt dit veel tijd met slechts een minimale snelheidswinst.

Dus het eenvoudig tarreren van de bestanden met de cvf-switches kost effectief de tijd die het kost om alle 55 GB-afbeeldingen te lezen en ze terug naar schijf te schrijven. (In feite zal het nog meer tijdverspilling zijn, omdat er een aanzienlijke overhead zal zijn).

Er is slechts één voordeel dat u hier behaalt, de overhead voor het uploaden van veel bestanden wordt verminderd. U kunt snellere overdrachtstijden krijgen als u de afbeeldingen comprimeert (maar aangezien ik geloof dat ze al in een gecomprimeerd formaat zitten, zal dit niet veel helpen). Gewoon meer verspilling van rekentijd.

Het grootste nadeel van het overbrengen van een groot tar-archiv via draad is dat als er iets fout gaat, dit kan betekenen dat je opnieuw moet beginnen.

Ik zou die manier gebruiken:

md5sum /images/* > md5sum.txt
scp -r images/* user@host:/images/

Op de nieuwe server

md5sum /images/* > md5sum_new.txt

En dan gewoon diff. En omdat scp on-the-fly compressie ondersteunt, is er geen behoefte aan aparte archieven.

Bewerk

Ik bewaar de MD5-informatie omdat deze nuttig was voor het OP. Maar een opmerking raakte me met nieuw inzicht. Dus een beetje zoeken leverde deze nuttige informatie op. Houd er rekening mee dat het onderwerp hier SFTP is niet rechtstreeks SCP.

In tegenstelling tot FTP voegt SFTP wel overhead toe aan de overdracht van bestanden. Aangezien een bestand wordt overgedragen tussen client en server, wordt het onderverdeeld in kleinere brokken die 'pakketten' worden genoemd. Stel dat elk pakket 32 ​​KB is. Het SFTP-protocol voert een controlesom uit op elk 32 KB-bestand terwijl het wordt verzonden en omvat die controlesom, samen met dat pakket. De ontvanger krijgt dat pakket en decodeert de gegevens en verifieert vervolgens de controlesom. De controlesom zelf is "sterker" dan de CRC32-controlesom. (Omdat SFTP 128-bits of meer controlesom gebruikt, zoals MD5 of SHA, en omdat dit wordt gedaan op elk pakket, is er een zeer gedetailleerde integriteitscontrole die wordt uitgevoerd als onderdeel van de overdracht.) Zo is het protocol zelf is langzamer (vanwege de extra overhead), maar de succesvolle voltooiing van een overdracht betekent de facto dat het integraal is overgedragen en dat er geen behoefte is aan een aanvullende controle.


12
2017-12-02 12:47



Heel erg bedankt, wat doet de md5sum? en wat is diff? Bedankt, nu uitvoeren! - Andrew Fashion
md5sum (of md5) neemt een controlesom van de bestanden op. Diff zoekt naar verschillen in de bestanden (man diff). De controlesom maakt een reeks, een hash, dat als het bestand wordt gewijzigd tijdens het transport ... een beetje wordt omgedraaid, een fout ... komt niet overeen wanneer u het opnieuw aan de andere kant neemt. Voor grote bestanden heb je een verhoogde kans op fouten. Dat is waarom wanneer u sites ziet waarmee u .iso-bestanden kunt downloaden, ze vaak een MD5-checksum hebben waarmee u uw gedownloade bestand kunt vergelijken om er zeker van te zijn dat het overeenkomt met en niet corrupt is. - Bart Silverstrim
Oh wauw, dat heb ik nooit geweten. Dank je! - Andrew Fashion
scp is versleuteld en garandeert integriteit over de hele lijn. Er is nog steeds een kleine kans dat de gegevens corrupt zijn in het geheugen of op schijf natuurlijk, maar dat is vrij zeldzaam. - EvilRyry
Is de overhead van SFTP-checksums eigenlijk van praktisch belang? Ik kan het me niet voorstellen. 4 bytes voor elke 32768 klinken niet significant. Dat is 128 kB per GB. Als je dat 'langzamer' noemt, lijkt het een overdrijving in alles behalve een saaie theoretische betekenis. - underscore_d


Bovenop de suggestie van mev5sum van Pacey zou ik het volgende gebruiken:

Op de bestemming: nc -w5 -l -p 4567 | tar -xvf -

Dan op de bron: tar -cvf - /path/to/source/ | nc -w5 destinationserver 4567

Het is nog steeds een tar / untar en er is geen codering, maar het is direct naar de andere server. Start ze beiden in tandem (-w5 geeft je 5 seconden genade.) en zie hoe het gaat. Als de bandbreedte krap is, voegt u -z toe aan de teer aan beide uiteinden.


8
2017-12-02 13:42



Ik denk dat het andersom is dat hij eerst moet uitvoeren op de bestemming (om de socket te openen) en vervolgens op de bron (om te verzenden) - Dimitrios Mistriotis
in plaats van de bestemmingsserver plaats ik root@1.1.1.1? - Andrew Fashion
Nee, alleen het IP-adres. netcat gebruikt geen ander protocol dan TCP :) Deze opdracht is ook de snelste van alle bovenstaande opdrachten. Er is precies één gelezen per bestand op de bron, het exacte minimale netwerkverkeer om de bestanden over te zetten, en exact één schrijven per bestand op de bestemming. Als u reserve-CPU-cycli hebt, zal het toevoegen van de vlag -z (voor compressie) het verder versnellen, omdat er minder netwerkgegevens moeten worden overgedragen. - Jeff McJunkin
@ user36845 - True. Ik bedoelde niet een chronologie met de bovenstaande bestelling, maar je hebt gelijk, de socket moet eerst worden geopend. Ik zal het bewerken om het te verduidelijken. :) - SmallClanger
Ik weet niet zeker waarom ssh / scp met 125MB / s tot 133MB / s aftopten, maar netcat kan die gegevens gemakkelijk bij ~ 380MB / s doorsturen (zelfde link) - ThorSummoner


Eén punt - niet alle hosts hebben rsync en hosts kunnen ook verschillende versies van tar hebben. Om deze reden zou je als eerste aanloophaven kunnen aanbevelen met behulp van de vaak-verwaarloosde cpio.

U kunt over SSH cpio doen om ad-hocreplicatie van bestands- / directorystructuren tussen hosts uit te voeren. Op deze manier heb je een fijnere controle over wat er wordt verzonden als je cpio, nom-nom, moet "voeden". Het is ook meer argument-draagbaar, cpio verandert niet veel - dit is een belangrijk punt als je op meerdere hosts let in een heterogene omgeving.

Voorbeeld van kopiëren / exporteren / home en submappen naar externe host:

cd /export/ find . home -print | cpio -oaV | ssh 10.10.10.10 'cd /export/home; cpio -imVd'

Het bovenstaande zou de inhoud van / export / home en eventuele subdirs kopiëren naar / exporteren / home op de externe host.

Ik hoop dat dit helpt.


1
2017-12-02 14:54



Hij zei wel dat het twee CentOS-boxen waren, dus zouden ze rsync hebben en compatibele versies van tar opslaan. Tools zoals rsync zijn gemaakt om tools zoals cpio :) te vervangen. U kunt niet "cvio" hervatten, in ieder geval zonder te weten waar u precies wilt beginnen en uw zoekopdracht naar wens filteren. Dat is onnodige overhead. Dat gezegd hebbende, nuttige informatie voor 'oude' UNIX-vakken :) - Rafiq Maniar
Ja, dat is en ik ben me kwijt haha - Andrew Fashion


I je hebt SSH-toegang, je hebt rsync-toegang.

rsync -av -e ssh /storage/images/ user@[ip or domain name]:/storage/images/

of

rsync -av -e "ssh -l user" /storage/images/ [ip or domain name]:/storage/images/

Als u een foutmelding krijgt als "rsync-fout: sommige bestanden konden niet worden overgedragen (code 23) op main.c (977) [afzender = 2.6.9]", controleer dan uw gebruiker en groepen tussen de servers; je zou een mismatch kunnen hebben.

Gebruik de optie rsync "-z" als u wilt dat rsync de overdracht comprimeert. Deze optie gebruikt meer CPU maar minder bandbreedte, dus houd daar rekening mee.

Er is een "- voortgang" optie die je een procent overdracht geeft, wat best leuk is als je van dat soort dingen houdt.


1
2017-12-03 22:01





Bevinden ze zich op een gedeeld netwerk in plaats van internet nodig te hebben voor het overbrengen van bestanden? NFS of FTP kan een stuk sneller zijn dan de overhead van SCP, hoewel u de codering tijdens de overdracht zou verliezen.


0
2017-12-02 13:20



verschillende servers op afgelegen locaties - Andrew Fashion


Of u kunt altijd teerpijpen gebruiken:

(cd /path && tar -cjf - * ) | ssh user@host 'tar -xjf - -C /path'

'j' = bzip2, je kunt 'z' gebruiken voor gzip of --lzma als je tar dit ondersteunt.


0
2017-12-03 07:08