sviluppo-web-qa.it

Come copiare rapidamente un gran numero di file tra due server

Devo trasferire un'enorme quantità di mp3 tra due servizi (Ubuntu). Con enorme intendo circa un milione di file che sono in media 300K. Ho provato con scp ma ci sarebbe voluto circa una settimana. (circa 500 KB/s) Se trasferisco un singolo file tramite HTTP, ottengo 9-10 MB/s, ma non so come trasferirli tutti.

C'è un modo per trasferirli tutti rapidamente?

96
nicudotro

Consiglierei tar. Quando gli alberi dei file sono già simili, rsync esegue molto bene. Tuttavia, poiché rsync eseguirà più passaggi di analisi su ciascun file e quindi copierà le modifiche, è molto più lento di tar per la copia iniziale. Questo comando probabilmente farà quello che vuoi. Copierà i file tra le macchine, oltre a preservare le autorizzazioni e le proprietà degli utenti/dei gruppi.

tar -c /path/to/dir | ssh remote_server 'tar -xvf - -C /absolute/path/to/remotedir'

Secondo il commento di Mackintosh sotto questo è il comando che useresti per rsync

rsync -avW -e ssh /path/to/dir/ remote_server:/path/to/remotedir
119
Scott Pack

Disco rigido esterno e consegna nello stesso giorno del corriere.

38
Adam

Userei rsync.

Se li hai esportati via HTTP con elenchi di directory disponibili, puoi usare anche wget e l'argomento --mirror.

Stai già vedendo che HTTP è più veloce di SCP perché SCP sta crittografando tutto (e quindi colli di bottiglia nella CPU). HTTP e rsync si sposteranno più velocemente perché non stanno crittografando.

Ecco alcuni documenti sulla configurazione di rsync su Ubuntu: https://help.ubuntu.com/community/rsync

Questi documenti parlano del tunneling di rsync su SSH, ma se stai semplicemente spostando i dati su una LAN privata non hai bisogno di SSH. (Suppongo che tu sia su una LAN privata. Se stai ricevendo 9-10 MB/sec su Internet, voglio sapere che tipo di connessioni hai!)

Ecco alcuni altri documenti di base che ti permetteranno di configurare un server rsync relativamente insicuro (senza dipendenza da SSH): http://transamrit.net/docs/rsync/

17
Evan Anderson

Senza molte discussioni, usa netcat, il coltellino svizzero di rete. Nessun overhead di protocollo, stai copiando direttamente nel socket di rete. Esempio

srv1$ tar cfv - *mp3 | nc -w1 remote.server.net 4321

srv2$ nc -l -p 4321 |tar xfv -
16
Icapan

Con molti file se vai con rsync, Proverei a ottenere la versione 3 o successiva su entrambe le estremità. Il motivo è che una versione inferiore enumera ogni file prima che inizi il trasferimento. La nuova funzionalità si chiama incrementale-ricorsione .

Un nuovo algoritmo di ricorsione incrementale viene ora utilizzato quando rsync sta parlando con un'altra versione 3.x. Ciò avvia il trasferimento più rapidamente (prima che tutti i file siano stati trovati) e richiede molta meno memoria. Vedi l'opzione --recursive nella pagina man per alcune restrizioni.

8
Kyle Brandt

rsync, come altri hanno già raccomandato. Se l'overhead della CPU dalla crittografia è un collo di bottiglia, utilizzare un altro algoritmo meno intensivo della CPU, come blowfish. Per esempio. qualcosa di simile a

rsync -ax -e 'ssh -c blowfish' /local/path [email protected]:/remote/path

7
janneb

Spostando 80 TB di dati (milioni di piccoli file) ieri, passando da rsync a tarsi è rivelato molto più veloce , come abbiamo smesso di provare

# slow
rsync -av --progress /mnt/backups/section01/ /mnt/destination01/section01

e passato a tar invece ...

# fast
cd /mnt/backups/
tar -cf - section01 | tar -xf - -C /mnt/destination01/ 

Poiché questi server si trovano sulla stessa LAN, la destinazione è montata su NFS sul sistema di origine, che sta eseguendo il push. Non renderlo ancora più veloce, abbiamo deciso di non conservare il atime dei file:

mount -o remount,noatime /mnt/backups
mount -o remount,noatime /mnt/destination01

Il grafico seguente mostra la differenza fatta dalla modifica da rsync a tar. È stata la mia idea del capo e la mia collega entrambe l'hanno eseguita e hanno reso grande scrivere sul suo blog . Mi piace solo belle immagini . :)

rsync_vs_tar

7
Philip Durbin

Quando ho copiato un gran numero di file, ho scoperto che strumenti come tar e rsync sono più inefficienti di quanto debbano essere a causa del sovraccarico di apertura e chiusura di molti file. Ho scritto uno strumento open source chiamato fast-archiver che è più veloce di tar per questi scenari: https://github.com/replicon/fast-archiver ; funziona più velocemente eseguendo più operazioni simultanee sui file.

Ecco un esempio di archiviazione veloce vs. tar su un backup di oltre due milioni di file; l'archiviazione veloce impiega 27 minuti per l'archiviazione, mentre tar richiede 1 ora e 23 minuti.

$ time fast-archiver -c -o /dev/null /db/data
skipping symbolic link /db/data/pg_xlog
1008.92user 663.00system 27:38.27elapsed 100%CPU (0avgtext+0avgdata 24352maxresident)k
0inputs+0outputs (0major+1732minor)pagefaults 0swaps

$ time tar -cf - /db/data | cat > /dev/null
tar: Removing leading `/' from member names
tar: /db/data/base/16408/12445.2: file changed as we read it
tar: /db/data/base/16408/12464: file changed as we read it
32.68user 375.19system 1:23:23elapsed 8%CPU (0avgtext+0avgdata 81744maxresident)k
0inputs+0outputs (0major+5163minor)pagefaults 0swaps

Per trasferire file tra server, puoi usare l'archiviazione rapida con ssh, in questo modo:

ssh [email protected] "cd /db; fast-archive -c data --exclude=data/\*.pid" | fast-archiver -x
4
mfenniak

Uso anche l'approccio tar attraverso netcat, tranne che preferisco usare socat - molta più potenza da ottimizzare per la tua situazione - ad esempio, modificando mss. (Inoltre, se vuoi ridi, ma trovo socat argomenti più facili da ricordare perché sono coerenti). Quindi per me, questo è molto molto recente ultimamente poiché ho spostato le cose su nuovi server:

Host1$ tar cvf - filespec | socat stdin tcp4:Host2:portnum

Host2$ socat tcp4-listen:portnum stdout | tar xvpf -

Gli alias sono opzionali.

3
  • Network File System (NFS) e poi copiali con quello che preferisci, ad es. Midnight Commander (mc), Nautilus (dallo gnomo). Ho usato NFS v3 con buoni risultati.
  • Samba (CIFS) e quindi copia i file con quello che vuoi, ma non ho idea di quanto sia efficiente.
  • [~ # ~] http [~ # ~] con wget --mirror come Evan Anderson ha suggerito o qualsiasi altro client http. Fare attenzione a non avere cattivi collegamenti simbolici o file di indice fuorvianti. Se tutto ciò che hai sono MP3, dovresti essere al sicuro.
  • rsync . L'ho usato con risultati abbastanza buoni e una delle sue belle caratteristiche è che puoi interrompere e riprendere il trasferimento in seguito.

Ho notato che altre persone hanno raccomandato di usare netcat. Sulla base di la mia esperienza con esso posso dire che è lento rispetto alle altre soluzioni.

2

Sembra che ci possano essere un paio di errori di battitura nella risposta in alto. Questo potrebbe funzionare meglio:

tar -cf - /path/to/dir | ssh remote_server 'tar -xvf - -C /path/to/remotedir'
2
retracile

Grazie alla meravigliosa risposta di Scott Pack (prima non sapevo come farlo con ssh), posso offrire questo miglioramento (se bash è la tua Shell). Ciò aggiungerà la compressione parallela, un indicatore di avanzamento e verificherà l'integrità attraverso il collegamento di rete:

tar c file_list |
    tee >(sha512sum >&2) |
    pv -prab |
    pigz -9 |
    ssh [[email protected]]remote_Host '
        gunzip |
        tee >(sha512sum >&2) |
        tar xC /directory/to/extract/to
    '

pv è un bel programma di visualizzazione dei progressi per la tua pipe e pigz è un programma gzip parallelo che utilizza tutti i thread quanti la tua CPU ha di default (credo fino a 8 max). Puoi ottimizzare il livello di compressione per adattare meglio il rapporto tra CPU e banda di rete e scambiarlo con pxz -9e e pxz -d se hai molta più CPU della larghezza di banda. Devi solo verificare che le due somme corrispondano al completamento.

Questa opzione è utile per grandi quantità di dati e reti ad alta latenza, ma non molto utile se il collegamento è instabile e si interrompe. In questi casi, rsync è probabilmente la scelta migliore in quanto può riprendere.

Uscita campione:

6c1fe5a75cc0280709a794bdfd23d7b8b655f0bbb4c320e59729c5cd952b4b1f84861b52d1eddb601259e78249d3e6618f8a1edbd20b281d6cd15f80c8593c3e  -                     ]
 176MiB [9.36MiB/s] [9.36MiB/s] [                                            <=>                                                                        ]
6c1fe5a75cc0280709a794bdfd23d7b8b655f0bbb4c320e59729c5cd952b4b1f84861b52d1eddb601259e78249d3e6618f8a1edbd20b281d6cd15f80c8593c3e  -

Per i dispositivi a blocchi:

dd if=/dev/src_device bs=1024k |
    tee >(sha512sum >&2) |
    pv -prab |
    pigz -9 |
    ssh [[email protected]]remote_Host '
        gunzip |
        tee >(sha512sum >&2) |
        dd of=/dev/src_device bs=1024k
    '

Ovviamente, assicurati che abbiano la stessa dimensione o limite con count =, skip =, seek =, ecc.

Quando copio i filesystem in questo modo, spesso per prima cosa dd if=/dev/zero of=/thefs/zero.dat bs=64k && sync && rm /thefs/zero.dat && umount /thefs per azzerare la maggior parte dello spazio inutilizzato, velocizzando lo xfer.

2
Daniel Santos

Un'altra alternativa è nison . In questo caso potrebbe essere leggermente più efficiente di Rsync ed è più semplice impostare un ascoltatore.

2
Adam D'Amico

Non hai menzionato se le due macchine si trovano sulla stessa LAN o se è obbligatorio un canale sicuro (cioè utilizzando SSH), ma un altro strumento che potresti usare è netcat .

Vorrei usare quanto segue sulla macchina ricevente:

cd <destdir>
netcat -l -p <port> | gunzip | cpio -i -d -m

Quindi dal lato di invio:

cd <srcdir>
find . -type f | cpio -o | gzip -1 | netcat <desthost> <port>

Ha i seguenti vantaggi:

  • Nessun sovraccarico della CPU per la crittografia di ssh.
  • Il gzip -1 Fornisce una leggera compressione senza saturare una CPU, quindi fa un buon compromesso, dando un po 'di compressione mantenendo il massimo rendimento. (Probabilmente non è vantaggioso per i dati MP3, ma non fa male.)
  • Se puoi suddividere i file in gruppi, puoi eseguire due o più pipe in parallelo e assicurarti davvero di saturare la larghezza di banda della rete.

per esempio.,

find <dir1> <dir2> -type f | cpio -o | gzip -1 | netcat <desthost> <portone>
find <dir3> <dir4> -type f | cpio -o | gzip -1 | netcat <desthost> <porttwo>

Appunti:

  • Qualunque sia il modo in cui trasferisci, probabilmente eseguirò un rsync o nisono in seguito per assicurarmi di avere tutto.
  • Puoi usare tar invece di cpio se preferisci.
  • Anche se finissi per usare ssh, mi assicurerei che non stia usando alcuna compressione stessa, e invii tu stesso gzip -1 Per evitare la saturazione della CPU. (O almeno impostare CompressionLevel su 1.)
1
Evan

Se hai un server ftp sul lato src, puoi usare ncftpget da sito ncftp . Funziona perfettamente con piccoli file in quanto utilizza tar internamente.

Un confronto mostra questo: spostare piccoli file da 1,9 GB (33926 file)

  1. L'uso di scp richiede 11m59s
  2. L'uso di rsync richiede 7m10s
  3. L'uso di ncftpget richiede 1m20s
1
Ali Nikneshan

Puoi anche provare a usare il comando BBCP per eseguire il tuo trasferimento. È un ssh parallelo bufferato che urla davvero. Di solito possiamo ottenere il 90% + rateo di linea purché possiamo mantenere il tubo alimentato.

$ bbcp -s 8 -w 64M -N io 'tar -cO srcdirectory' desthostname:'tar -x -C destdir'

Normalmente, ci sforziamo molto per evitare di dover spostare suff. Utilizziamo pool ZFS a cui possiamo sempre "aggiungere" più spazio su disco. Ma a volte ... devi solo spostare le cose. Se abbiamo un filesystem "live" che può richiedere ore (o giorni) per essere copiato anche quando si va a pieno ritmo .. facciamo la solita operazione zfs in due passaggi:

  1. Crea uno snapshot ZFS e trasferiscilo nel nuovo pool sul nuovo computer. Lascia che impieghi tutto il tempo necessario.
  2. Effettuare una seconda istantanea e inviarla come incrementale. Lo snapshot incrementale include solo il set di modifiche (molto più piccolo) dal primo, quindi passa in modo relativamente rapido.
  3. Una volta completata l'istantanea incrementale è possibile girare l'originale e tagliare alla nuova copia e il "tempo di inattività offline" è ridotto al minimo.

Inviamo anche i nostri dump zfs su BBCP ... massimizza l'utilizzo della nostra rete e minimizza i tempi di trasferimento.

BBCP è disponibile gratuitamente, puoi cercarlo su Google ed è una compilazione diretta. Copialo nel tuo/usr/local/bin su entrambe le macchine src e di destinazione e funzionerà praticamente.

1
C. Shamis

Immagino che la mia risposta sia un po 'in ritardo qui, ma ho fatto buone esperienze con l'utilizzo di mc (Midnight Commander) su un server per connettermi tramite SFTP all'altro server.

L'opzione per connettersi tramite FTP è nei menu "Sinistra" e "Destra", inserendo l'indirizzo in questo modo:

/#ftp:[email protected]/

o

/#ftp:[email protected]/

Puoi navigare e fare operazioni sui file quasi come su un filesystem locale.

Ha un'opzione integrata per fare la copia in background, ma preferisco usare il comando screen e staccare dallo schermo mentre mc sta copiando (penso che funzioni anche più velocemente).

1
w-sky

Alla risposta @scottpack dell'opzione rSync

Per visualizzare l'avanzamento del caricamento utilizzare '--progess' come opzione dopo -avW nel comando come mostrato di seguito.

rsync -avW --progress -e ssh /path/to/dir/ remote_server:/path/to/remotedir

 enter image description here 

1
Dinesh Sunny

Un semplice scp con le opzioni appropriate raggiungerà facilmente 9-10 MB/s su LAN:

scp -C -c arcfour256 ./local/files.mp3 [email protected]:/opt/remote

Con queste opzioni è probabile che il throughput sia diventato 4x o 5 volte più veloce di nessuna opzione (impostazione predefinita)

1
user57125

Non penso che farai meglio di scp se non installi schede di rete più veloci. Se lo stai facendo su Internet, non sarà di aiuto.

Consiglierei di usare rsync. Potrebbe non essere più veloce, ma almeno se fallisce (o lo spegni perché sta impiegando troppo tempo), puoi riprendere da dove avevi interrotto la prossima volta.

Se riesci a connettere direttamente le 2 macchine usando Gigabit Ethernet, sarà probabilmente il più veloce.

1
Brent

Per 100 Mb/s il throughput teorico è di 12,5 MB/s, quindi a 10 MB/s si sta andando abbastanza bene.

Vorrei anche fare eco al suggerimento di fare rsync, probabilmente attraverso ssh. Qualcosa di simile a:

rsync -avW -e ssh $SOURCE [email protected]$REMOTE:$DEST

A 100 Mb/s le CPU dovrebbero essere in grado di gestire la crittografia/decrittografia senza influire in modo sensibile sulla velocità dei dati. E se si interrompe il flusso di dati, si dovrebbe essere in grado di riprendere da dove si era interrotto. Attenzione, con "milioni" di file l'avvio richiederà un po 'di tempo prima che trasferisca effettivamente qualsiasi cosa.

1

Ho riscontrato questo, tranne per il fatto che stavo trasferendo i registri Oracle.

Ecco la ripartizione

  • sCP

    inefficient and encrypted (encrypted = slower than unencrypted 
    depending on the link and your processor) 
    
  • rsync

    efficient but typically encrypted (though not necessarily)
    
  • FTP/HTTP

    both seem to be efficient, and both are plaintext. 
    

Ho usato FTP con grande successo (dove un grande successo equivale a ~ 700 Mb/s su una rete Gb). Se ricevi 10 MB (che equivale a 80 Mb/s), probabilmente qualcosa non va.

Cosa puoi dirci sulla fonte e la destinazione dei dati? È singola unità a singola unità? RAID su USB?

So che questa domanda ha già una risposta, ma se la tua rete sta andando così lentamente su un cavo crossover Gb/s, qualcosa deve assolutamente essere risolto.

1
Matt Simmons

Ecco un rapido benchmark per confrontare alcune tecniche,

  • La sorgente è una CPU Intel (R) Xeon (R) a 4 core E5-1620 a 3,60 GHz con 250 Mbps e unità SATA
  • La destinazione è una CPU Intel (R) Xeon (R) a 6 core E-2136 a 3,30 GHz con larghezza di banda di 1 Gbps e unità SSD

Numero di file: 9632, Dimensione totale: 814 MiB, Dimensione media: 84 KiB

  • RSYNC: 1m40.570s
  • RSYNC + COMPRESSIONE: 0m26.519s
  • TAR + NETCAT: 1m58.763s
  • TAR + COMPRESSIONE + NETCAT: 0m28.009s

Il comando per tar/netcat era:

Source : tar -cf - /sourcedir/ | nc -v 11.22.33.44 5000
Dest : nc -v -l 5000 | tar -xf -
1
Antares

Se invii tramite MP3 e altri file compressi, non otterrai molto da qualsiasi soluzione che tenti di comprimere ulteriormente quei file. La soluzione sarebbe qualcosa che può creare connessioni multiple tra entrambi i server e quindi mettere più stress sulla larghezza di banda tra i due sistemi. Una volta raggiunto questo limite, non c'è molto che si possa guadagnare senza migliorare l'hardware. (Schede di rete più veloci tra questi server, ad esempio.)

0
Wim ten Brink

Ho dovuto copiare il disco BackupPC in un'altra macchina.

Ho usato rsync.

La macchina aveva 256 MB di memoria.

La procedura che ho seguito è stata questa:

  • eseguito rsync senza -H (impiegato 9 ore)
  • quando rsync ha finito, ho sincronizzato la directory cpool e ho iniziato con la directory pc; Ho tagliato il trasferimento.
  • quindi riavviato rsync con -H flag e tutti i file collegati nella directory pc sono stati trasferiti correttamente (la procedura ha trovato tutti i file reali nella directory cpool e quindi collegati alla directory pc) ( impiegato 3 ore).

Alla fine ho potuto verificare con df -m che non è stato speso spazio aggiuntivo.

In questo modo eludo il problema con la memoria e rsync. Per tutto il tempo posso verificare le prestazioni usando top and atop e infine ho trasferito 165 GB di dati.

0
Hector

Ho provato un paio di strumenti per copiare un file da 1 GB Il risultato è il seguente: HTTP il più veloce, con wget -c nc secondo in linea scp più lento e fallito un paio di volte. Nessun modo di riprendere rsync usa ssh come backend, quindi lo stesso risultato. In conclusione, andrei per http con wget -bqc e gli darei un po 'di tempo. Spero che questo aiuti

0
Mijo

rsync o potresti voler tar in modo che sia tutto all'interno di un file e quindi scp. Se ti manca lo spazio su disco puoi reindirizzare il tar direttamente su ssh mentre viene creato.

0
Adam Gibbins