%20volume%20montado%3A%20links%20f%C3%ADsicos%20parecem%20preservados%2C%20mas%20o%20espa%C3%A7o%20%C3%A9%20calculado%20como%20arquivos%20completos.png)
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:
- crie um instantâneo local cominstantâneo, em uma pasta local no servidor de origem
- 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.1
e daily.2
pastas. Ao verificar arquivos aleatórios nessas pastas de instantâneos em busca de links físicos, obtenho os resultados esperados:
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)
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 -sh
saí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 -sh
volumes 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 du
nã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.2
assim como fez para a avaliação nº 1.
Usando essas informações, você pode determinar se sua versão du
está 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.)