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 senso 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, rsynco cp?

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 la -abandiera - 'archivio'. Così:

rsync -a source dest

Sebbene UID / GID e collegamenti simbolici siano conservati da -a(vedi -lpgo), la tua domanda implica che potresti voler una copia completa delle informazioni del filesystem; e -anon include hard-link, attributi estesi o ACL (su Linux) o precedenti o fork di risorse (su OS X.) Pertanto, per una copia affidabile di un filesystem, è necessario includere tali flag:

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

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

cp -au source dest

Quando si copia sul file system locale, utilizzo sempre le seguenti opzioni rsync:

# 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ù rapidi 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 -)

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

Si noti che la barra finale /src/è importante.

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

catrame

Anche questo è positivo e continua in caso di 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.

Qualunque cosa tu preferisca. Basta non dimenticare l' -ainterruttore quando si decide di utilizzare cp.

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

Il rsynccomando calcola sempre i checksum su ogni byte che trasferisce.

L'opzione della riga di comando --checksumriguarda 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 checksum dell'intero file, ma che la verifica automatica dopo il trasferimento non ha nulla a che fare con questa opzione prima del trasferimento "Questo file ha bisogno di per essere aggiornato? " dai un'occhiata.

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

rsync -aPhW --protocol=28aiuta 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

rsync è eccezionale, ma ha 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.

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 532 Gb di dati distribuiti tra 1.753.200 file abbiamo avuto quei tempi:

• rsync ci sono voluti 232 minuti
• tar ci sono voluti 206 minuti
• cpio ci sono voluti 225 minuti
• rsync + parallel ci sono voluti 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 è pubblicato qui

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.

ARJ È COSÌ 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.

Sicuramente vuoi provare rclone . 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).

È possibile aggiungere --ignore-checksumalla prima esecuzione per renderlo ancora più veloce.

Entrambi funzioneranno bene.

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

E se usi ARJ?

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

dove -jm -m1sono i livelli di compressione e lo -jerende 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è sempre accettare, sovrascrivere, saltare ecc.)

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

Ci sono alcune accelerazioni che possono essere applicate a rsync:

Evitare

• -z/ --compress: la compressione caricherà la CPU solo perché il trasferimento non è su una rete ma su RAM.
• --append-verify: riprende un trasferimento interrotto. Sembra una buona idea, ma presenta un 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 non si accelera significativamente --no-whole-filedurante l'aggiunta di un caso di errore pericoloso.

Uso

• -S/ --sparse: trasforma sequenze di null in blocchi sparsi
• --partialo -Pche è --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-filein 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)