Il modo più semplice per il trasferimento rapido di file tra server Linux?

16

Devo trasferire file da un server CentOS a un altro. Trasferirà file da 5 MB ogni 10 minuti circa. Non è necessaria la crittografia.

Cosa è stato facile per un rapido trasferimento di file?

C'è qualcosa di più semplice di ftp?

Grazie!

linux  file-transfer 
— Alex L
fonte
1
Ho fiducia che il catrame su netcat trionferà ... heh heh ...: serverfault.com/questions/18125/…
— Evan Anderson,
Dal momento che non ho bisogno di crittografia ma ho bisogno di velocità, preferisco rsync.
— Alex L
Ho appena appreso che i trasferimenti http non hanno molte spese generali, quindi forse potrei semplicemente usarlo.
— Alex L,
Non modificare una risposta alla tua domanda, pubblicala invece come risposta. Tornato alla situazione precedente.
— HopelessN00b,
per "veloce" vedere anche unix.stackexchange.com/questions/48399/…
— rogerdpack

Risposte:

25

rsync

Userei rsync prima di usare ftp o tftp.

Più opzioni e (nella mia esperienza) trasferimento più affidabile.

— KPWINC
fonte
1
Ho anche scoperto che rsync in genere ottiene un throughput più elevato rispetto a qualsiasi altra cosa (scp, cifs, nfs)
— Ophidian,
che dire dei trasferimenti http?
— Alex L
@Ophidian Intendi usare rsync come demone? Altrimenti come può essere più veloce di scp, poiché entrambi usano ssh e c'è la crittografia.
— Balki,
@balki Sì, il demone rsync. Non è particolarmente loquace, fa un buon lavoro di alimentazione dei dati dal disco sulla linea e fa il minimo lavoro necessario per completare la richiesta (ad esempio applica le differenze per i file di testo).
— Ofide
21

tar over ssh va bene, ma tar over TCP via netcat è il più basso possibile! Se questa è una cosa una tantum, provaci:

Sul ricevitore:

nc -l -p 8989 | tar x

Sul mittente:

tar cf - /source-path | nc (receiving host ip address) 8989

Se questo è qualcosa che farai regolarmente, probabilmente userò rsync.

— Evan Anderson
fonte
+1 per netcat, il coltellino svizzero
— chmeee
Lo stesso per non aver letto Evan. Hahaha! In realtà non è una cosa sola. Ha detto che trasferirà file da 5 MB ogni 10 minuti circa. Forse l'invio tramite codice Morse sarebbe una buona alternativa? ;-) (nota: scherzo privato tra Evan e me)
— KPWINC,
8

Due persone hanno menzionato tar over ssh, ma non hanno detto come farlo. Per la cronaca, la procedura di base è eseguire:

tar cf - files... | ssh remotehost 'cd /destination && tar xvf -'

Oppure, se si desidera iniziare i trasferimenti dall'estremità ricevente:

ssh remotehost 'cd /source && tar cf - files' | tar xvf -

Il vantaggio di farlo in questo modo rispetto alla soluzione netcat di Evan è che il tutto può essere avviato da un computer; non è necessario coordinare due invocazioni netcat. Se è necessario eseguirlo automaticamente, è possibile impostare una chiave ssh che consenta di effettuare connessioni senza passphrase e utilizzare quella chiave per queste connessioni.

ssh ha un'opzione -C per comprimere il suo flusso di dati, oppure puoi usare la capacità di compressione integrata di GNU tar:

tar zcf - files... | ssh remotehost 'cd /destination && tar xzvf -'

Rsync è un'altra opzione, ma il suo punto di forza è nell'aggiornamento dei file che già esistono sul lato ricevente. Ho trovato che è più lento di scp o tar / ssh quando lo si utilizza per trasferire file che non esistono già dall'altra parte.

— Kenster
fonte
1
+1 Cosa, vuoi dire, non tutti sanno intuitivamente come fare tar su ssh? Strano. :)
— caos,
tar, di per sé, non è affidabile - non esiste un controllo di integrità, tuttavia con SSH (TLS) si ottiene l'integrità grazie alla capacità di TLS di rilevare in volo le modifiche ai dati. Rsync è una scelta migliore e Rsync in quanto farà un migliore controllo dell'integrità senza crittografia; l'OP ha dichiarato che la crittografia non era necessaria.
— Kilo,
Di quale controllo di integrità ha bisogno tar? I livelli TCP e ssh forniscono un trasporto dati affidabile. Se stai affermando che il catrame stesso può avere dei bug, devi trattare rsync allo stesso modo. In effetti ho avuto i trasferimenti rsync bloccati su di me a causa di problemi di protocollo. Non ricordo di aver mai fatto una pipeline tar / untar.
— Kenster,
6

Vorrei usare scpo tarpiù ssh, onestamente. La crittografia rallenta le cose, ma la facilità di installazione e utilizzo, l'affidabilità e (soggettivamente, ovviamente) la familiarità mi rendono disposto a prendere il colpo, a meno che non abbia davvero bisogno di quella velocità.

Puoi velocizzare il trasferimento ssh dicendogli di usare anche una cifra più veloce di quella predefinita. L'impostazione predefinita è di solito 3dese di solito puoi farlo -c des, quindi ovviamente sarà più veloce, ed -c blowfishè rappresentato altrettanto velocemente, anche se non l'ho provato esattamente.

(Ai tempi di SSHv1, si poteva fare spesso -c none, ma immagino che qualcuno abbia deciso che era un juju cattivo.)

— caos
fonte
4

Se devi passare attraverso scp / ssh, i miei esperimenti mostrano che la cifra più veloce abilitata di default in questi giorni è RC4. Si specifica la cifra tramite ' -c arcfour ' nel comando ssh / scp:

per copia iniziale:

  • scp -c arcfour -r foo/ desthost:/destdir

per aggiornamenti:

  • rsync -e 'ssh -c arcfour' -r foo/ desthost:/destdir
— allaryin
fonte
3

Rsync è una buona strada da percorrere perché se ti ritrovi a trasferire gli stessi file più di una volta, questo accelera la copia, come mostrato con questa citazione dalla pagina man. 

   rsync is a program that behaves in much the same way that rcp does, but
   has many more options and uses  the  rsync  remote-update  protocol  to
   greatly  speed  up  file  transfers  when the destination file is being
   updated.
   The rsync remote-update protocol allows rsync to transfer just the dif-
   ferences between two sets of files across the network connection, using
   an efficient  checksum-search  algorithm  described  in  the  technical
   report that accompanies this package.
— thepocketwade
fonte
2

FTP è piuttosto semplice, ma un modo ancora più semplice potrebbe essere quello di creare una condivisione NFS su una macchina e montarla sull'altra. Quindi la copia dei file consisterà nel fare un cp da una directory all'altra.

— Swoogan
fonte
a seconda delle esigenze. Non userei NFS su Internet per esempio.
— Kyle Hodgson,
1
Buon punto. In tal caso, consiglierei rsync in quanto può riprendere da dove era interrotto se interrotto. Anche perché trasferisce solo il delta tra l'origine e la destinazione.
— Swoogan,
la domanda era molto generica, mi piace il soulution pubblicato da Swoogan, in particolare quell'autore ha menzionato la necessità della soluzione più semplice e non richiede la crittografia
— integratorIT
2

Se vuoi la velocità puoi usare netcat e tar. Sarà più veloce di ssh, rsync o scp su una rete locale in cui la crittografia non è un problema. Google "netcat tar".

DestinationServer

nc -l -p 7878 | tar -C /target/dir -xzf -

SourceServer

tar -cz /source/dir | nc DestinationServer 7878

Ciò ovviamente richiede che netcat sia effettivamente installato. Google "netcat tar" per maggiori informazioni.

— robertmoggach
fonte
1

Credo che tu abbia già risolto il tuo problema ma nel caso in cui il tuo ssh funzioni su un'altra porta (non sulla porta standard 22) puoi usare questo

rsync -avz --rsh = 'ssh -pXXXXX' / local / dir / root@192.168.1.2: / remote / dir

Nota: - sostituire XXXXX con il numero di porta - sostituire 192.16.1.2 con l'IP del server remoto corretto

— mangia
fonte
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.