Pregunta ¿Copiando localmente un gran árbol de directorios? cp o rsync?


Tengo que copiar un gran árbol de directorios, alrededor de 1.8 TB. Todo es local. Por costumbre lo usaría rsyncSin 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, por lo que no tengo que preocuparme por la actualización condicional de algunos archivos. Es todo el disco local, así que no tengo que preocuparme por ssh o la red.

La razón por la que me siento tentado lejos de rsync es que rsync puede hacer más de lo que necesito. rsync checksums archivos. No necesito eso, y me preocupa que pueda tomar más tiempo que el CP.

Entonces, ¿qué crees, rsync o cp?


217
2017-07-20 14:36


origen


Si rsync hace exactamente lo que quiere que haga, si ya está bastante familiarizado con su uso para esta aplicación en particular, y si funciona lo suficientemente rápido para adaptarse a sus gustos, ¿por qué motivo desea cambiar? - eleven81
Porque me preocupa que rsync tome más tiempo que cp, ya que rsync hace un montón de suma de comprobación que cp no hace - Rory
La sobrecarga de la CPU de la suma de comprobación es pequeña en comparación con el disco / red i / o. A menos que el disco esté en el mismo sistema y el sistema operativo pueda hacer alguna copia inteligente de la unidad de disco en el controlador del bus. - Martin Beckett
La comprobación se realiza en archivos que difieren en el tamaño y la marca de tiempo. Si está paranoico (como después de un corte de energía durante la copia) puede forzar la suma de comprobación en todos los archivos, pero en una transferencia local, eso suele ser más lento que comenzar de cero. - korkman
Tal vez tenga curiosidad por mejorar su flujo de trabajo y no entierre su cabeza en la arena pensando que lo sabe todo. Este comentario realmente me molesta. - Martin Konecny


Respuestas:


Utilizaría rsync, ya que significa que si se interrumpe por cualquier motivo, puede reiniciarlo fácilmente con muy poco costo. Y al ser rsync, incluso puede reiniciarse a través 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 -a bandera - 'archivo'. Por lo tanto:

rsync -a source dest

Aunque UID / GID y enlaces simbólicos se conservan por -a (ver -lpgo), su pregunta implica que podría querer un completo copia de la información del sistema de archivos; y -a no incluye enlaces físicos, atributos extendidos o ACL (en Linux) o los anteriores ni bifurcaciones de recursos (en OS X.) Por lo tanto, para una copia robusta de un sistema de archivos, deberá incluir esos indicadores:

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

El cp predeterminado comenzará de nuevo, aunque el -u bandera hará "copiar solo cuando el archivo SOURCE es más nuevo que el archivo de destino o cuando falta el archivo de destino". Y el -a La bandera (archivo) será recursiva, no se copiará los archivos si tiene que reiniciar y conservar los permisos. Asi que:

cp -au source dest

188
2017-07-20 14:40



La bandera -u de cp probablemente no sea la mejor solución, ya que no detectaría un archivo parcialmente copiado / dañado. Lo bueno de rsync es que puede hacer que md5 sume los archivos para detectar diferencias. - Chad Huneycutt
Agregar la opción -w (--whole-file) aceleraría un rsync interrumpido, ya que solo copiaría el archivo en lugar de la suma de comprobación. - hayalci
en realidad, rsync detecta transferencias locales y permite la copia de archivos completos sin sumar la comprobación de forma automática. - korkman
y --progress que es realmente útil! - Matt
-P o --progress muestra el progreso de cada archivo individualmente. Es útil para copiar archivos grandes, no para muchos (miles) archivos pequeños, ya que significa muchos más resultados que no se pueden leer. No muestra el progreso general de todos los archivos combinados. - SPRBRN


Al copiar en el sistema de archivos local, siempre uso las siguientes opciones de rsync:

# 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 utilizando la configuración rsync anterior en el siguiente comando tar como lo sugiere otra respuesta:

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

89
2018-05-07 19:09



Estoy teniendo el siguiente error: rsync: --no-compress: unknown option @Ellis Percival. - alper
Esto se está aclarando rápido. Más rápido para hacer esto que rm -rf /src/. - dgo
Como @alper, --no-compress no era una opción para mi versión de rsync (en CentOS 7); Utilicé --compress-level = 0 en su lugar. - Paul


Cuando tengo que copiar una gran cantidad de datos, normalmente uso una combinación de tar y rsync. El primer paso es tar, 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 motivo. O tal vez el proceso se interrumpa, 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 inclinada en /src/ es importante.


78
2017-07-20 15:15



+1 He encontrado que tar es generalmente más rápido para copias grandes que rsync. También me gusta la idea de terminar con un rsync final. - Geoff Fritz
tar es una buena opción si el directorio de destino está vacío. Aunque mi camino sería: cd $ DSTDIR; tar c - C $ SRCDIR. | alquitrán - asdmin
Esa es la belleza de este método. No necesita duplicar el espacio porque en realidad nunca crea un archivo tar intermedio. El alquitrán antes de la tubería empaqueta los datos y los transmite a la salida estándar, y el alquitrán después de la tubería lo toma de la entrada estándar y lo desempaqueta. - Chad Huneycutt
Hice un cp -a para una transferencia de 12 gb, y este método para una transferencia de 42 gb. El método del alquitrán tomó alrededor de 1/4 del tiempo. - NGaida
Yo tambien puse pv en el medio para poder ver el progreso, estimando el tamaño de todos los datos usando df. Tambien utilicé --numeric-owner, como el disco de origen era de otro sistema y no quería tar ensuciar a los dueños tar -C /old-path --numeric-owner -S -c . | pv -tpeba -s 100G | tar -C /new-path --numeric-owner -S -xp - Petr Pudlák


rsync

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

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

cpio

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

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

alquitrán

Esto también es bueno, y continúa en fallos de lectura.

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

Tenga en cuenta que todos ellos son sólo para copias locales.


13
2018-02-26 17:06



¿Por qué usas las banderas -S y -D para rsync? - miyalys


rsync -aPhW --protocol=28 Ayuda a acelerar esas copias grandes con RSYNC. Siempre hago rsync porque la idea de estar a medio camino a través de 90GiB y romperlo me asusta lejos del PC


6
2017-07-20 16:24



¿Cuál es el valor de usar el protocolo más antiguo en esa cadena de comando? - ewwhite
En una máquina Mac, la versión anterior de Rsync enviada se bloquea en algunas de las nuevas revoluciones del protocolo rsync, como la 29. Al decirle que se mueva al protocolo anterior, NO se verifica una y otra vez. - oneguynick
Supongo que el número 28 ya no es válido? - SPRBRN


los rsync comando siempre calcula sumas de comprobación en cada byte que transfiere.

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

-c, --checksum  Saltar basado en la suma de comprobación, no en tiempo mod y tamaño "

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

Tenga en cuenta que rsync siempre verifica que cada archivo transferido se reconstruyó correctamente en el lado receptor al verificar su suma de comprobación del archivo completo, pero que la verificación automática posterior a la transferencia no tiene nada que ver con la opción anterior a la transferencia. "¿Necesita este archivo? ¿Para actualizarse?" comprobar.

Asi que rsync también, siempre, calcula una suma de comprobación de todo el archivo en el lado receptor, incluso cuando -c/ --checksum La opción es "off".


6
2017-11-28 01:20



Si bien su publicación agregó alguna información interesante aquí, las críticas y los insultos disminuyen el valor de su publicación. Este sitio no es un foro para comentarios no constructivos. Si pudo modificar la fuente, ¿ha enviado sus modificaciones como parche? ¿Has publicado tu versión en github o algo así? Si se siente tan convencido acerca de esto, podría ser mejor si intentara hacer algo un poco más constructivo en lugar de ser insultante. - Zoredache
Sí, el último párrafo no era realmente necesario. - Sherwin Flight


Lo que sea que prefieras. Simplemente no olvides el -a cambiar cuando decidas usar cp.

Si realmente necesitas una respuesta: usaría rsync porque es mucho más flexible. ¿Necesita apagarse antes de que se complete la copia? Solo presiona ctrl-c y reanuda tan pronto como tu espalda. ¿Necesitas excluir algunos archivos? Solo usa --exclude-from. ¿Necesitas cambiar de titularidad o permisos? rsync hará eso por ti.


5
2017-07-20 14:40



¿Qué hace la bandera -p otra vez? - Rory
Conservará la propiedad, las marcas de tiempo y los permisos. - innaM
cp -a sería mejor. - David Pashley
En efecto. La respuesta cambió en consecuencia. - innaM


rsync es genial, pero tiene problemas con los árboles de directorios realmente grandes porque almacena los árboles en la memoria. Estaba buscando para ver si solucionaban 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
2017-07-20 16:14



Si usa la versión 3, no mantiene todo el árbol en la memoria si es grande, usa un algoritmo de recursión incremental: samba.org/ftp/rsync/src/rsync-3.0.0-NEWS - Kyle Brandt♦


Este hilo fue muy útil y debido a que había muchas 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 tomó 232 minutos
  • tar tomó 206 minutos
  • cpio tomó 225 minutos
  • rsync + parallel tomó 209 minutos

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

Se publican las referencias completas. aquí


5
2018-05-11 19:14



404 Pagina no encontrada - Amedee Van Gasse
Gracias. La URL de @AmedeeVanGasse se ha corregido un poco después de que informaste :) - arjones
¿Por qué no hacer benchmarking? cp? Este es el título de la pregunta! - calandoa
@calandoa creo cp es inseguro, es decir: cuando se rompe tienes que volver a empezar, así es como prefiero las opciones que se pueden reanudar, ergo rsync es mi favorito :) - arjones