Rsync -avzHP sigue enlaces duros en lugar de copiarlos como enlaces duros

Utilizo rsnapshot para crear copias de seguridad por hora / día / semana / mes de mi "trabajo" compartido. Ahora estoy tratando de copiar todo el directorio de respaldo en una unidad externa usando rsync.

Usé este comando / parámetros dentro de una sesión de pantalla (sí, rsync-exclude.txt se encuentra en el directorio desde el que ejecuto el comando)

rsync -avzHP --exclude-from 'rsync-exclude.txt' /share/backup/ /share/eSATADisk1/backup/;

Todo se está ejecutando en un QNAP TS-439, la unidad interna es un disco único (sin RAID) formateado EXT4, la unidad externa tiene formato EXT3.

Lo que sucede es: Rsync sigue cada enlace duro y copia el archivo real en lugar de recrear el enlace duro actualizado en la unidad externa. No reconocí esto de inmediato, por lo que la unidad externa terminó destrozada con xxx copias de los mismos archivos.

Lo que quiero lograr es: copiar toda la estructura de archivos generada por rsnapshot en la unidad externa manteniendo los enlaces duros para ahorrar espacio. Nota: Esto no debe hacerse necesariamente con rsync.

Gracias por tus ideas y tiempo. Agradecería tu ayuda, a lo grande.

Actualización: Aprendí que rsnapshot no está usando enlaces simbólicos, está usando enlaces duros, así que ahora uso la opción -H que debería preservar la estructura de enlace rígido de acuerdo con Rsnapshot a múltiples destinos (o mantener la estructura de enlaces duros) pero aún así no funcionará ... ¿que me estoy perdiendo aqui?

Actualización 2: Encontré otra opinión / declaración sobre este tema aquí: rsync con --hard-links freezes Steven Monday sugiere no intentar rsync estructuras de archivos grandes que contengan enlaces duros , ya que absorbe mucha memoria y es una tarea difícil para rsync. Entonces, probablemente una mejor solución sería hacer un .img de la estructura de datos que estoy tratando de respaldar. ¿Qué piensas?

La opción rsyncdel comando -H(u --hard-links), en teoría, hará lo que está tratando de lograr, que es, en resumen: crear una copia de su sistema de archivos que conserve la estructura rígida del original. Como mencioné en mi respuesta a otra pregunta similar , esta opción está condenada a fallar una vez que su sistema de archivos de origen supera un cierto umbral de complejidad del enlace duro.

La ubicación precisa de ese umbral puede depender de su RAM y la cantidad total de enlaces duros (y probablemente una serie de otras cosas), pero he descubierto que no tiene sentido tratar de definirlo con precisión. Lo que realmente importa es que el umbral es demasiado fácil de cruzar en situaciones del mundo real, y no sabrás que lo has cruzado, hasta que llegue el día en que trates de correr una rsync -aHo una cp -alucha que finalmente falla .

Lo que recomiendo es esto: copie su sistema de archivos fuertemente vinculado como una unidad, no como archivos. Es decir, copie toda la partición del sistema de archivos como un gran blob. Hay varias herramientas disponibles para hacer esto, pero la más omnipresente es dd.

Con el firmware estándar, su NAS de QNAP debería estar ddintegrado, así como también fdisk. Con fdisk, cree una partición en la unidad de destino que sea al menos tan grande como la partición de origen. Luego, use ddpara crear una copia exacta de su partición de origen en la partición de destino recién creada.

Mientras la ddcopia está en progreso, debe asegurarse de que nada cambie en el sistema de archivos de origen, para que no termine con una copia corrupta en el destino. Una forma de hacerlo es a umountla fuente antes de comenzar el proceso de copia; Otra forma es montar la fuente en modo de solo lectura.

-l es para enlaces simbólicos, ¿por qué haría algo para los enlaces duros?

(Lo siento, esta es una respuesta y no un comentario, todavía no tengo derechos de comentario y esta respuesta necesitaba una respuesta)

Otra nota que debería ser un comentario: ¿todo esto es hardware nativo o estás en una VM, montaje en red?

Editar

Ignore mi comentario anterior sobre por qué está utilizando enlaces duros, me perdí el rsnapshotcomentario.

Sería útil tener una prueba que primero pruebe rsync entre dos directorios locales del disco local, luego contra su disco remoto. Esta pequeña prueba muestra los -Hwokrs de opciones como se esperaba. La -iopción para lsmuestra los inodos, lo que muestra que los enlaces se han conservado, sin copias adicionales.

$ rsync -avzHP src/ dest
sending incremental file list
created directory dest
./
file111_prime.txt
           9 100%    0.00kB/s    0:00:00 (xfer#1, to-check=0/3)
file111.txt => file111_prime.txt

sent 156 bytes  received 59 bytes  430.00 bytes/sec
total size is 18  speedup is 0.08

$ ls -liR
.:
total 8
414044 drwxrwxr-x. 2 nhed nhed 4096 Feb 25 09:58 dest
414031 drwxrwxr-x. 2 nhed nhed 4096 Feb 25 09:58 src

./dest:
total 8
414046 -rw-rw-r--. 2 nhed nhed 9 Feb 25 09:57 file111_prime.txt
414046 -rw-rw-r--. 2 nhed nhed 9 Feb 25 09:57 file111.txt

./src:
total 8
414032 -rw-rw-r--. 2 nhed nhed 9 Feb 25 09:57 file111_prime.txt
414032 -rw-rw-r--. 2 nhed nhed 9 Feb 25 09:57 file111.txt

Una prueba posterior rsync -avzHP src/ host:/tmpa un host remoto aún mantenía los enlaces duros

Esta es una posibilidad remota, pero si no puede encontrar otra solución, le sugiero que intente formatear la unidad USB como EXT4. Tal vez este podría ser el problema: https://bugzilla.samba.org/show_bug.cgi?id=7670

Dado que hay suficientes enlaces duros en una carpeta de origen y un volumen de destino lo suficientemente pequeño, la copia con rsync --hard-links puede fallar. Rsync falla al agotar el número máximo de enlaces duros en el destino <...> el problema real no es rsync sino el sistema de archivos subyacente.

¿Has intentado agregar la -lopción?

Sé que la página de manual dice que está incluida, -apero las páginas de manual no siempre son 100% precisas.