(rsync activado) volumen montado: los enlaces físicos parecen conservarse, pero el espacio se calcula como archivos completos

Question

Estoy intentando configurar un esquema de copia de seguridad rotativa que ahorre espacio con rsnapshot/rsync desde un servidor a una caja de almacenamiento de Hetzner. Me cuesta entender cómo los enlaces físicos en el destino afectan el uso del disco que se informa. En resumen: aunque los enlaces físicos parecen estar ubicados en el destino de la copia de seguridad, no parecen tenerse en cuenta en el uso del disco, sino que se cuentan como archivos completos.

Dado que la carpeta de destino de rsnapshot debe estar en el sistema de archivos local, configuré un flujo de trabajo que consta de 2 partes:

1. crear una instantánea local coninstantánea, en una carpeta local en el servidor de origen
2. rsync esa instantánea local a través de SSH consincronizaciónal destino

Parece funcionar bien y rápido, pero tengo una preocupación: el uso del disco informado en el destino (con du -sh) parece acumular el tamaño de todas las instantáneas.aunque parecen haber sido copiados correctamente mediante enlaces físicos. Nota: dado que las cajas de almacenamiento de Hetzner no permiten el inicio de sesión SSH interactivo, estoy inspeccionando este destino de copia de seguridad como un volumen montado con CIFS.

Por ejemplo, después de 3 rondas de este combo rsnaphsot + rsync, la carpeta de destino contiene las carpetas daily.0, daily.1y daily.2. Cuando reviso archivos aleatorios en esas carpetas de instantáneas en busca de enlaces físicos, obtengo los resultados esperados:

1. find /mnt/user.your-storagebox.de/rsync-backup/ -name "output.file" -print0 | xargs -0 ls -li:

   351317 -rw-rw---- 3 root root 8650 Dec 15 11:25 /mnt/user.your-storagebox.de/rsync-backup/daily.0/home/user/output.file
   351317 -rw-rw---- 3 root root 8650 Dec 15 11:25 /mnt/user.your-storagebox.de/rsync-backup/daily.1/home/user/output.file
   351317 -rw-rw---- 3 root root 8650 Dec 15 11:25 /mnt/user.your-storagebox.de/rsync-backup/daily.2/home/user/output.file
   

   devuelve 3 archivos con inodos idénticos y un recuento de enlaces de 3 (como se esperaba)

2. find /mnt/user.your-storagebox.de/rsync-backup/ -samefile /mnt/user.your-storagebox.de/rsync-backup/daily.0/home/user/output.file

   /mnt/user.your-storagebox.de/rsync-backup/daily.0/var/tomcat/vhosts/output.file
   /mnt/user.your-storagebox.de/rsync-backup/daily.2/var/tomcat/vhosts/output.file
   /mnt/user.your-storagebox.de/rsync-backup/daily.1/var/tomcat/vhosts/output.file
   

   devuelve 3 archivos (como se esperaba)

Supongo que esto indica que estas instantáneas se copiaron correctamente en el destino como enlaces físicos.

Sin embargo... al verificar el uso de su disco en la ubicación de destino: du -sh /mnt/user.your-storagebox.de/rsync-backup, se devuelve un valor de 12G. Esto es inesperado, ya que la carpeta de origen original solo tiene aproximadamente 4G. Aparentemente, ¿el uso del disco se calcula de forma acumulativa, a pesar de los enlaces físicos?

OTOH, al inspeccionar la carpeta de destino a través de rsnapshot du, obtengo un resultado quehaceparecen tener en cuenta los enlaces físicos:

4.3G    /mnt/user.your-storagebox.de/rsync-backup/daily.0/
41K     /mnt/user.your-storagebox.de/rsync-backup/daily.1/
41K     /mnt/user.your-storagebox.de/rsync-backup/daily.2/
4.3G    total

Esto es confuso: o las instantáneas se están copiando con enlaces físicos y deberían ocupar un espacio mínimo (lo que parece ser el caso al inspeccionar los inodos), o no lo están y están ocupando mucho más espacio de lo esperado (como lo sugiere La du -shsalida).

Mi principal preocupación es: ¿el uso del disco informado en este volumen montado es correcto o no? ¿Existe alguna advertencia sobre el uso de du -shvolúmenes montados que deba tener en cuenta?

Answer 1

Mi versión de du(Debian du (GNU coreutils) 8.30) maneja archivos con enlaces físicos y cuenta las instancias múltiples solo una vez. Parece que el tuyo no. Sin embargo, puedes verificar esto con bastante facilidad.

Prepara el escenario

mkdir zzz                 # Scenario workspace
tar cf zzz/etc.1 /etc     # Ignore "tar: Removing leading `/' from member names"

Prueba #1. Dos archivos copiados pero no vinculados

cp zzz/etc.1 zzz/etc.2    # Create copy

du -s zzz/etc.1           # 2580 KB, in my instance
du -s zzz/etc.2           # As you would expect, the same value
du -s zzz                 # 5164 KB, because the files are "different"

Prueba #2. Dos archivos vinculados entre sí

rm zzz/etc.2
ln zzz/etc.1 zzz/etc.2    # Create hardlink

du -s zzz/etc.1           # Unchanged from above, of course, 2850 KB
du -s zzz/etc.2           # As you would expect, still the same value
du -s zzz                 # For me, this is still the same value, 2580 KB

Si su instancia de duno puede manejar varias instancias del mismo archivo vinculado, su prueba n.° 2 devolverá el total de ambas etc.1y etc.2tal como lo hizo para la prueba n.° 1.

Con esta información, puede determinar si su versión dues engañosa o si los archivos realmente están consumiendo más espacio en disco del que esperaría. (Dadas sus otras métricas, estoy bastante seguro de que es la primera).