kutombawewe.net

¿Copiando un árbol de directorio grande localmente? cp o rsync?

Tengo que copiar un gran árbol de directorios, aproximadamente 1,8 TB. Todo es local. Por costumbre, usaría rsync, sin embargo, me pregunto si tiene mucho sentido y si prefiero usar cp.

Me preocupan los permisos y uid/gid, ya que deben conservarse en la copia (sé que rsync hace esto). Así como cosas como enlaces simbólicos.

El destino está vacío, así que no tengo que preocuparme por actualizar condicionalmente algunos archivos. Es todo un disco local, así que no tengo que preocuparme por ssh o la red.

La razón por la que me sentiría tentado de rsync es porque rsync podría hacer más de lo que necesito. archivos de suma de comprobación rsync. No necesito eso, y me preocupa que pueda llevar más tiempo que cp.

Entonces, ¿qué piensas, rsync o cp?

244
Rory

Usaría rsync ya que significa que si se interrumpe por cualquier motivo, puede reiniciarlo fácilmente con muy poco costo. Y siendo rsync, incluso puede reiniciarse a la mitad de un archivo grande. Como otros mencionan, puede excluir archivos fácilmente. La forma más sencilla de preservar la mayoría de las cosas es usar el indicador -a - "archivar". Entonces:

rsync -a source dest

Aunque UID/GID y los enlaces simbólicos se conservan con -a (Consulte -lpgo), Su pregunta implica que podría querer una copia completa de la información del sistema de archivos; y -a no incluye enlaces duros, atributos extendidos o ACL (en Linux) o las bifurcaciones de recursos nor anteriores (en OS X.) Por lo tanto, para una copia robusta de un sistema de archivos, deberá incluir esas banderas:

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

El cp predeterminado comenzará nuevamente, aunque la bandera -u"copie solo cuando el archivo SOURCE sea más nuevo que el archivo de destino o cuando falte el archivo de destino". Y el indicador -a (Archivo) será recursivo, no volverá a copiar los archivos si tiene que reiniciar y preservar los permisos. Entonces:

cp -au source dest
214
Hamish Downer

Cuando copio al sistema de archivos local, tiendo a usar rsync con las siguientes opciones:

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

Aquí está mi razonamiento:

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

He visto transferencias un 17% más rápidas usando la configuración de rsync anterior sobre el siguiente comando tar como lo sugiere otra respuesta:

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

Cuando tengo que copiar una gran cantidad de datos, generalmente uso una combinación de tar y rsync. El primer paso es alquitranado, algo como esto:

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

Por lo general, con una gran cantidad de archivos, habrá algunos que tar no podrá manejar por cualquier razón. O tal vez el proceso se interrumpirá, o si se trata de una migración del sistema de archivos, es posible que desee hacer la copia inicial antes del paso de migración real. En cualquier caso, después de la copia inicial, hago un paso rsync para sincronizarlo todo:

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

Tenga en cuenta que la barra diagonal final en /src/ es importante.

79
Chad Huneycutt

rsync

Aquí está el rsync que uso, prefiero cp para comandos simples, no este.

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

cpio

Aquí hay una manera que es aún más segura, cpio. Es casi tan rápido como el alquitrán, quizás un poco más rápido.

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

tar

Esto también es bueno y continúa con fallas de lectura.

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

Tenga en cuenta que todos son solo para copias locales.

14
AskApache

Lo que sea que prefieras. Solo no olvides el -a cambia cuando decides usar cp.

Si realmente necesita una respuesta: usaría rsync porque es mucho más flexible. ¿Necesita apagar antes de completar la copia? Simplemente ctrl-c y reanudar tan pronto como su espalda ¿Necesita excluir algunos archivos? Solo usa --exclude-from. ¿Necesita cambiar la propiedad o los permisos? rsync lo hará por usted.

7
innaM

El comando rsync siempre calcula sumas de verificación en cada byte que transfiere.

La opción de línea de comando --checksum solo se refiere a si las sumas de verificación de los archivos se utilizan para determinar qué archivos se transfieren o no, es decir:

-c, --checksum omitir en función de la suma de comprobación, no del mod-time & size "

La página de manual también dice esto:

Tenga en cuenta que rsync siempre verifica que cada archivo transferido se haya reconstruido correctamente en el lado receptor al verificar la suma de comprobación de todo el archivo, pero que la verificación automática después de la transferencia no tiene nada que ver con la opción antes de la transferencia "¿Necesita este archivo? ¿Para actualizarse?" cheque.

Entonces rsync también, siempre, calcula una suma de verificación de todo el archivo en el lado receptor, incluso cuando -c/ --checksum la opción está "desactivada".

7
John

rsync -aPhW --protocol=28 ayuda a acelerar esas copias grandes con RSYNC. Siempre uso rsync porque la idea de estar a mitad de 90GiB y romper me asusta lejos de CP

6
oneguynick

Este hilo fue muy útil y debido a que había tantas opciones para lograr el resultado, decidí comparar algunas de ellas. Creo que mis resultados pueden ser útiles para que otros tengan una idea de lo que funcionó más rápido.

Para mover 532Gb de datos distribuidos entre 1,753,200 archivos tuvimos esos tiempos:

  • rsync tardó 232 minutos
  • tar tomó 206 minutos
  • cpio tomó 225 minutos
  • rsync + parallel tardó 209 minutos

En mi caso, preferí usar rsync + parallel. Espero que esta información ayude a más personas a decidir entre estas alternativas.

Los puntos de referencia completos se publican aquí

6
arjones

rsync es excelente, pero tiene problemas con los árboles de directorio realmente grandes porque almacena los árboles en la memoria. Solo estaba buscando para ver si solucionarían este problema cuando encontré este hilo.

También encontré:

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

También puede dividir manualmente el árbol y ejecutar múltiples rsyncs.

5
n3bulous

Cuando hago una copia local de un directorio local, mi experiencia es que "cp -van src dest" es un 20% más rápido que rsync. En cuanto a la reiniciabilidad, eso es lo que hace "-n". Solo necesita rm el archivo parcialmente copiado. No es doloroso a menos que sea un ISO o algo así.

3
Ron

ARJ IS SO OLD SCHOOL !! Realmente dudo que ARJ y/o rsync den rendimiento.

Definitivamente lo que siempre hago es usar cpio:

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

Esto es casi más rápido que el CP, definitivamente más rápido que el alquitrán y sin canalizar nada.

2
Gonzalo Gorosito

Definitivamente quieres probar rclone . Esto es una locura rápido:

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

Esta es una copia local desde y hacia un SSD LITEONIT LCS-256 (256GB).

Puedes añadir --ignore-checksum en la primera ejecución para hacerlo aún más rápido.

1
Frédéric N.

Ambos funcionarán bien.

0
pauska

Hay algunas aceleraciones que se pueden aplicar a rsync:

Evitar

  • -z/--compress: la compresión solo cargará la CPU, ya que la transferencia no se realiza a través de una red sino a través de la RAM.
  • --append-verify: reanudar una transferencia interrumpida. Esto suena como una buena idea, pero tiene el caso de falla peligrosa: cualquier archivo de destino del mismo tamaño (o mayor) que la fuente será IGNORADO. Además, comprueba la suma de todo el archivo al final, lo que significa que no hay una velocidad significativa durante --no-whole-file al agregar un caso de falla peligrosa.

Utilizar

  • -S/--sparse: convierte secuencias de nulos en bloques dispersos
  • --partial o -P cual es --partial --progress: guarda los archivos parcialmente transferidos para reanudarlos en el futuro. Nota: los archivos no tendrán un nombre temporal, así que asegúrese de que nada más espere usar el destino hasta que se haya completado la copia completa.
  • --no-whole-file para que todo lo que deba reenviarse utilice la transferencia delta. Leer la mitad de un archivo parcialmente transferido suele ser mucho más rápido que volver a escribirlo.
  • --inplace para evitar la copia del archivo (pero solo si nada está leyendo el destino hasta que se complete la transferencia completa)
0
Tom Hale

tar también haría el trabajo, pero no reanudará la interrupción como lo hará rsync.

0
pgs

¿Qué pasa si usas ARJ?

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

dónde -jm -m1 son niveles de compresión y -je lo convierte en un ejecutable. Ahora tienes un bash encapsulado de archivos.

Luego para la extracción al mapa objetivo

filepack -y  

donde se realizará el mapa fuente (donde -y siempre es aceptar, sobrescribir, omitir, etc.)

Luego se puede scp ftp el paquete de archivos al área de destino y ejecutarlo, si es posible.

0
herauthon