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. Ci ho provato scpma ci sarebbe voluta 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?

Consiglierei tar. Quando gli alberi dei file sono già simili, rsync funziona 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

Disco rigido esterno e consegna nello stesso giorno del corriere.

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 su come configurare 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 relativo non sicuro (senza dipendenza da SSH): http://transamrit.net/docs/rsync/

Senza molte discussioni, usa netcat, il coltellino di rete Swissarmy. 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 -

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 ricorsione incrementale .

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.

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. Ad esempio qualcosa del genere

rsync -ax -e 'ssh -c blowfish' /local/path user@host:/remote/path

Spostando 80 TB di dati (milioni di piccoli file) ieri, il passaggio da rsynca tar si è rivelato molto più veloce , quando abbiamo smesso di provare

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

e passò tarinvece a ...

# 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 i atimefile:

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 un'idea del mio capo e entrambi i miei colleghi l' hanno eseguita e hanno fatto un ottimo commento sul suo blog . Mi piacciono le belle foto . :)

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 aprire e chiudere 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, è possibile utilizzare l'archiviazione rapida con ssh, in questo modo:

ssh postgres@10.32.32.32 "cd /db; fast-archive -c data --exclude=data/\*.pid" | fast-archiver -x

Uso anche l' netcatapproccio tar through , tranne che preferisco usare socat- molta più potenza per ottimizzare la tua situazione - ad esempio, modificando mss. (Inoltre, se vuoi ridi, ma trovo gli socatargomenti più facili da ricordare perché sono coerenti). Quindi per me, questo è molto comune 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.

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

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'

• Network File System (NFS) e quindi copiarli con qualsiasi cosa tu voglia, ad esempio Midnight Commander (mc), Nautilus (da gnome). 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 --mirrorcome 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 della mia esperienza con esso, posso dire che è lento rispetto alle altre soluzioni.

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 [user@]remote_host '
        gunzip |
        tee >(sha512sum >&2) |
        tar xC /directory/to/extract/to
    '

pvè un bel programma di visualizzazione dei progressi per la tua pipe ed pigzè un programma gzip parallelo che utilizza tutti i thread quanti la tua CPU ha di default (credo fino a 8 max). È possibile ottimizzare il livello di compressione per adattarsi meglio al rapporto tra CPU e banda di rete e scambiarlo con pxz -9ee pxz -dse si dispone di una CPU molto maggiore 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 [user@]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 dd if=/dev/zero of=/thefs/zero.dat bs=64k && sync && rm /thefs/zero.dat && umount /thefscosa azzererò la maggior parte dello spazio inutilizzato, il che accelera lo xfer.

Non credo 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 eri rimasto la prossima volta.

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

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 $USER@$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.

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.

Non hai menzionato se le due macchine si trovano sulla stessa LAN o se un canale sicuro (cioè usando SSH) è obbligatorio, 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 sul lato mittente:

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 -1fornisce leggera compressione senza saturare la CPU in modo che rende un buon compromesso, dando un po 'di compressione mantenendo la massima produttività. (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 unisono in seguito per assicurarmi di avere tutto.
• Puoi usare tarinvece che cpiose preferisci.
• Anche se finissi per usare ssh, mi assicurerei che non stia usando alcuna compressione stessa, e gzip -1invece ti installi attraverso te stesso per evitare la saturazione della CPU. (O almeno impostare CompressionLevel su 1.)

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

scp -C -c arcfour256 ./local/files.mp3 remoteuser@remoteserver:/opt/remote

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

Se hai un server ftp sul lato src, puoi usare ncftpget dal 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

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. Basta copiarlo nel tuo / usr / local / bin su entrambe le macchine src e di destinazione e funzionerà praticamente.

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:name@server.xy/

o

/#ftp:name@ip.ad.dr.ess/

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

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

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 -

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.

Se invii tramite MP3 e altri file compressi, non otterrai molto da alcuna soluzione che tenti di comprimere ulteriormente tali 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 da guadagnare senza migliorare l'hardware. (Schede di rete più veloci tra questi server, ad esempio.)

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 utilizza 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

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 rsyncsenza -H(impiegato 9 ore)
• quando rsync ha finito, ho sincronizzato la cpooldirectory e ho iniziato con la pcdirectory; Ho tagliato il trasferimento.
• quindi riavviato rsynccon -Hflag e tutti i file collegati nella pcdirectory sono stati trasferiti correttamente (la procedura ha rilevato tutti i file reali cpoole quindi collegati alla pcdirectory) (sono state necessarie 3 ore).

Alla fine ho potuto verificare df -mche 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.