sviluppo-web-qa.it

Copia di un albero di directory di grandi dimensioni localmente? cp o rsync?

Devo copiare un grande albero di directory, circa 1,8 TB. È tutto locale. Per abitudine userei rsync, tuttavia mi chiedo se c'è molto punto e se dovrei piuttosto usare cp.

Sono preoccupato per i permessi e uid/gid, dal momento che devono essere conservati nella copia (so che rsync lo fa). Così come cose come symlink.

La destinazione è vuota, quindi non devo preoccuparmi di aggiornare in modo condizionale alcuni file. È tutto il disco locale, quindi non devo preoccuparmi di ssh o di rete.

Il motivo per cui sarei tentato di allontanarmi da rsync, è perché rsync potrebbe fare più del necessario. file checksum rsync. Non ne ho bisogno e sono preoccupato che potrebbe richiedere più tempo di cp.

Quindi cosa ne pensi, rsync o cp?

244
Rory

Vorrei usare rsync in quanto significa che se viene interrotto per qualsiasi motivo, è possibile riavviarlo facilmente con un costo molto basso. Ed essendo rsync, può anche riavviare in parte attraverso un file di grandi dimensioni. Come altri citano, può escludere facilmente i file. Il modo più semplice per preservare la maggior parte delle cose è usare il -a flag - "archivio". Quindi:

rsync -a source dest

Sebbene UID/GID e symlink siano conservati da -a (vedi -lpgo), la tua domanda implica che potresti volere una copia completa delle informazioni sul filesystem; e -a non include hard link, attributi estesi o ACL (su Linux) o le forcelle di risorse nor sopra (su OS X.) Pertanto, per una copia affidabile di un filesystem, " Dovremo includere quelle bandiere:

rsync -aHAX source dest # Linux
rsync -aHE source dest  # OS X

Il cp predefinito ricomincerà, sebbene -u flag "copia solo quando il file SOURCE è più recente del file di destinazione o quando manca il file di destinazione". E il -a flag (archivio) sarà ricorsivo, non ricopia i file se è necessario riavviare e conservare le autorizzazioni. Così:

cp -au source dest
214
Hamish Downer

Quando si copia sul file system locale, tendo a usare rsync con le seguenti opzioni:

# rsync -avhW --no-compress --progress /src/ /dst/

Ecco il mio ragionamento:

-a is for archive, which preserves ownership, permissions etc.
-v is for verbose, so I can see what's happening (optional)
-h is for human-readable, so the transfer rate and file sizes are easier to read (optional)
-W is for copying whole files only, without delta-xfer algorithm which should reduce CPU load
--no-compress as there's no lack of bandwidth between local devices
--progress so I can see the progress of large files (optional)

Ho visto trasferimenti più veloci del 17% usando le impostazioni rsync sopra sopra il seguente comando tar come suggerito da un'altra risposta:

# (cd /src; tar cf - .) | (cd /dst; tar xpf -)
120
Ellis Percival

Quando devo copiare una grande quantità di dati, di solito uso una combinazione di tar e rsync. Il primo passo è tarare, qualcosa del genere:

# (cd /src; tar cf - .) | (cd /dst; tar xpf -)

Di solito con una grande quantità di file, ce ne saranno alcuni che tar non può gestire per nessun motivo. O forse il processo verrà interrotto, o se si tratta di una migrazione del filesystem, potresti voler fare la copia iniziale prima dell'effettiva fase di migrazione. Ad ogni modo, dopo la copia iniziale, faccio un passo rsync per sincronizzare tutto:

# cd /dst; rsync -avPHSx --delete /src/ .

Nota che la barra finale su /src/ è importante.

79
Chad Huneycutt

rsync

Ecco la rsync che uso, preferisco cp per comandi semplici, non questo.

$ rsync -ahSD --ignore-errors --force --delete --stats $SRC/ $DIR/

cpio

Ecco un modo ancora più sicuro, cpio. È veloce quanto il catrame, forse un po 'più veloce.

$ cd $SRC && find . -mount -depth -print0 2>/dev/null | cpio -0admp $DEST &>/dev/null

tar

Anche questo va bene e continua con errori di lettura.

$ tar --ignore-failed-read -C $SRC -cf - . | tar --ignore-failed-read -C $DEST -xf -

Nota che sono tutti solo per copie locali.

14
AskApache

Qualunque cosa tu preferisca. Non dimenticare il -a cambia quando decidi di usare cp.

Se hai davvero bisogno di una risposta: userei rsync perché è molto più flessibile. È necessario arrestare prima di completare la copia? Basta ctrl-c e riprendere non appena la schiena. Devi escludere alcuni file? Usa --exclude-from. Devi modificare la proprietà o le autorizzazioni? rsync lo farà per te.

7
innaM

Il comando rsync calcola sempre i checksum su ogni byte che trasferisce.

L'opzione della riga di comando --checksum riguarda solo se i checksum dei file vengono utilizzati per determinare quali file trasferire o meno, ovvero:

-c, --checksum salta in base al checksum, non a mod-time e dimensioni "

La manpage dice anche questo:

Si noti che rsync verifica sempre che ogni file trasferito sia stato correttamente ricostruito sul lato ricevente controllando il relativo checksum del file intero, ma che la verifica automatica dopo il trasferimento non ha nulla a che fare con questa opzione prima del trasferimento "Questo file ha bisogno per essere aggiornato? " dai un'occhiata.

Quindi anche rsync calcola sempre un checksum dell'intero file sul lato ricevente, anche quando -c/ --checksum L'opzione è "off".

7
John

rsync -aPhW --protocol=28 aiuta ad accelerare quelle copie di grandi dimensioni con RSYNC. Vado sempre in sincronia perché il pensiero di essere a metà di 90GiB e la sua rottura mi spaventa dal CP

6
oneguynick

Questo thread è stato molto utile e poiché c'erano così tante opzioni per ottenere il risultato, ho deciso di metterne a confronto alcuni. Credo che i miei risultati possano essere utili per gli altri hanno un'idea di cosa ha funzionato più velocemente.

Per spostare 532Gb di dati distribuiti tra 1.753.200 file abbiamo avuto quei tempi:

  • rsync ha impiegato 232 minuti
  • tar ha impiegato 206 minuti
  • cpio ha impiegato 225 minuti
  • rsync + parallel ha impiegato 209 minuti

Nel mio caso ho preferito usare rsync + parallel. Spero che queste informazioni aiutino più persone a decidere tra queste alternative.

Il benchmark completo viene pubblicato qui

6
arjones

rsync è eccezionale, ma presenta problemi con alberi di directory molto grandi perché memorizza gli alberi in memoria. Stavo solo cercando di vedere se avrebbero risolto questo problema quando ho trovato questo thread.

Ho anche trovato:

http://matthew.mceachen.us/geek/gigasync/

È inoltre possibile spezzare manualmente l'albero ed eseguire più rsync.

5
n3bulous

Quando eseguo localmente una copia della directory locale, la mia esperienza è che "cp -van src dest" è il 20% più veloce di rsync. Per quanto riguarda la ristartabilità, ecco cosa fa "-n". Hai solo bisogno di rm il file parzialmente copiato. Non doloroso a meno che non sia un ISO o alcuni di questi.

3
Ron

ARJ IS SO VECCHIA SCUOLA !! Dubito davvero che ARJ e/o rsync daranno prestazioni.

Sicuramente quello che faccio sempre è usare cpio:

find . -print | cpio -pdm /target/folder

Questo è quasi veloce di CP, decisamente più veloce di tar e senza tubazioni.

2

Sicuramente vuoi provare rclone una prova. Questa cosa è follemente veloce:

Sudo rclone sync /usr /home/fred/temp -P -L --transfers 64

Transferred:       17.929G / 17.929 GBytes, 100%, 165.692 MBytes/s, ETA 0s
Errors:                75 (retrying may help)
Checks:            691078 / 691078, 100%
Transferred:       345539 / 345539, 100%
Elapsed time:     1m50.8s

Questa è una copia locale da e verso un SSD LITEONIT LCS-256 (256 GB).

Puoi aggiungere --ignore-checksum al primo avvio per renderlo ancora più veloce.

1
Frédéric N.

Entrambi funzioneranno bene.

0
pauska

Ci sono alcune accelerazioni che possono essere applicate a rsync:

Evitare

  • -z/--compress: la compressione caricherà la CPU solo poiché il trasferimento non è su una rete ma su RAM.
  • --append-verify: riprende un trasferimento interrotto. Sembra una buona idea, ma presenta il pericoloso caso di errore: qualsiasi file di destinazione della stessa dimensione (o maggiore) rispetto alla fonte verrà IGNORATO. Inoltre, esegue il checksum dell'intero file alla fine, il che significa che nessuna velocità significativa su --no-whole-file durante l'aggiunta di un caso di errore pericoloso.

Uso

  • -S/--sparse: trasforma sequenze di null in blocchi sparsi
  • --partial o -P che è --partial --progress: salva tutti i file parzialmente trasferiti per il futuro ripristino. Nota: i file non avranno un nome temporaneo, quindi assicurati che nient'altro si aspetti di utilizzare la destinazione fino al completamento dell'intera copia.
  • --no-whole-file in modo che tutto ciò che deve essere reinviato utilizzi il delta transfer. La lettura della metà di un file parzialmente trasferito è spesso molto più rapida della scrittura di nuovo.
  • --inplace per evitare la copia del file (ma solo se nulla sta leggendo la destinazione fino al completamento dell'intero trasferimento)
0
Tom Hale

tar farebbe anche il lavoro, ma non riprenderà dall'essere interrotto come farà rsync.

0
pgs

E se usi ARJ?

arj a -jm -m1 -r -je filepack /source

dove -jm -m1 sono livelli di compressione e -je lo rende un eseguibile. Ora hai un bash incapsulato di file.

Quindi per l'estrazione sulla mappa di destinazione

filepack -y  

dove verrà creata la mappa di origine (dove -y accetta sempre, sovrascrive, salta ecc.)

Si può quindi scp ftp il filepack nell'area di destinazione ed eseguirlo, se possibile.

0
herauthon