(rsync ativado) volume montado: links físicos parecem preservados, mas o espaço é calculado como arquivos completos

(rsync ativado) volume montado: links físicos parecem preservados, mas o espaço é calculado como arquivos completos

Estou tentando configurar um esquema de backup rotativo com uso eficiente de espaço com rsnapshot/rsync de um servidor para uma caixa de armazenamento Hetzner. Estou tendo dificuldade em entender como os links físicos no destino estão afetando o uso do disco relatado. Resumindo: embora os links físicos pareçam estar presentes no destino do backup, eles não parecem ser levados em consideração no uso do disco, mas sim contados como arquivos completos.

Como a pasta de destino do rsnapshot deve estar no sistema de arquivos local, configurei um fluxo de trabalho que consiste em 2 partes:

  1. crie um instantâneo local cominstantâneo, em uma pasta local no servidor de origem
  2. sincronize novamente esse snapshot local por SSH comsincronizar novamentepara o destino

Isso parece funcionar bem e rápido, mas tenho uma preocupação: o uso do disco relatado no destino (com du -sh) parece acumular o tamanho de todos os instantâneos,mesmo que pareçam ter sido copiados corretamente usando links físicos. Nota: como as caixas de armazenamento Hetzner não permitem login SSH interativo, estou inspecionando esse destino de backup como um volume montado com CIFS.

Por exemplo, após 3 rodadas desta combinação rsnaphsot + rsync, a pasta de destino contém daily.0, daily.1e daily.2pastas. Ao verificar arquivos aleatórios nessas pastas de instantâneos em busca de links físicos, obtenho os 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
    

    retorna 3 arquivos com inodes idênticos e uma contagem de links de 3 (conforme esperado)

  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
    

    retorna 3 arquivos (conforme esperado)

Acho que isso indica que esses instantâneos foram copiados corretamente para o destino como links físicos.

Ainda assim... ao verificar o uso do disco no local de destino: du -sh /mnt/user.your-storagebox.de/rsync-backup, um valor de 12G é retornado. Isso é inesperado, já que a pasta de origem original tem apenas cerca de 4G. Aparentemente, o uso do disco é calculado cumulativamente, apesar dos hard links?

OTOH, ao inspecionar a pasta de destino via rsnapshot du, estou obtendo uma saída quefazparecem levar em conta os links 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

Isso é confuso: ou os snapshots estão sendo copiados com links físicos e devem ocupar um espaço mínimo (o que parece ser o caso ao inspecionar os inodes), ou não estão e estão ocupando muito mais espaço do que o esperado (como sugerido por a du -shsaída).

Minha principal preocupação é: o uso do disco relatado neste volume montado está correto ou não? Há alguma advertência sobre o uso de du -shvolumes montados que eu deva estar ciente?

Responder1

Minha versão do du(Debian du (GNU coreutils) 8.30) lida com arquivos com hardlinks e conta as múltiplas instâncias apenas uma vez. Parece que o seu não. Você pode verificar isso facilmente, embora

Prepare o cenário

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

Teste nº 1. Dois arquivos copiados, mas sem link físico

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"

Teste nº 2. Dois arquivos vinculados juntos

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

Se sua instância dunão puder lidar com várias instâncias do mesmo arquivo com link físico, sua avaliação nº 2 retornará o total de ambas etc.1, etc.2assim como fez para a avaliação nº 1.

Usando essas informações, você pode determinar se sua versão duestá sendo enganosa ou se os arquivos realmente estão usando mais espaço em disco do que você esperaria. (Dadas suas outras métricas, tenho quase certeza de que é a primeira.)

informação relacionada