(rsync включен) смонтированный том: жесткие ссылки, похоже, сохраняются, но пространство рассчитывается как полные файлы

(rsync включен) смонтированный том: жесткие ссылки, похоже, сохраняются, но пространство рассчитывается как полные файлы

Я пытаюсь настроить схему ротационного резервного копирования с эффективным использованием пространства с помощью rsnapshot / rsync с сервера на хранилище Hetzner. Мне сложно понять, как жесткие ссылки на месте назначения влияют на отчет об использовании диска. Короче говоря: хотя жесткие ссылки, кажется, присутствуют на месте назначения резервного копирования, они, похоже, не учитываются при использовании диска, а вместо этого считаются полными файлами.

Поскольку папка назначения rsnapshot должна находиться в локальной файловой системе, я настроил рабочий процесс, состоящий из двух частей:

  1. создать локальный снимок с помощьюrsnapshot, в локальной папке на исходном сервере
  2. rsync, что локальный снимок через SSH сrsyncк месту назначения

Кажется, это работает хорошо и быстро, но у меня есть одно замечание: использование диска, сообщаемое в месте назначения (с du -sh), похоже, суммирует размер всех снимков,даже если они, кажется, были скопированы правильно с использованием жестких ссылокПримечание: поскольку хранилища Hetzner не поддерживают интерактивный вход по SSH, я проверяю это место назначения резервной копии как смонтированный том с CIFS.

Например, после 3 раундов этой комбинации rsnaphsot + rsync папка назначения содержит папки daily.0, daily.1и daily.2. При проверке случайных файлов в этих папках снимков на наличие жестких ссылок я получаю ожидаемые результаты:

  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
    

    возвращает 3 файла с идентичными инодами и количеством ссылок 3 (как и ожидалось)

  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
    

    возвращает 3 файла (как и ожидалось)

Полагаю, это означает, что эти снимки были правильно скопированы в место назначения в виде жестких ссылок.

Но... при проверке использования ими диска в месте назначения: du -sh /mnt/user.your-storagebox.de/rsync-backupвозвращается значение 12G. Это неожиданно, так как исходная папка-источник занимает всего около 4G. По-видимому, использование диска рассчитывается кумулятивно, несмотря на жесткие ссылки?

С другой стороны, при проверке папки назначения через rsnapshot duя получаю вывод, чтоделаетпохоже, учитывают жесткие ссылки:

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

Это сбивает с толку: либо снимки копируются с помощью жестких ссылок и должны занимать минимальное пространство (что, по-видимому, и происходит при проверке инодов), либо этого не происходит и они занимают гораздо больше места, чем ожидалось (как следует из выходных данных du -sh).

Моя главная проблема: правильно ли указано использование диска на этом смонтированном томе или нет? Есть ли какие-либо предостережения относительно использования du -shсмонтированных томов, о которых мне следует знать?

решение1

Моя версия du(Debian, du (GNU coreutils) 8.30) обрабатывает файлы с жесткими ссылками и подсчитывает множественные экземпляры только один раз. Похоже, что ваша этого не делает. Вы можете проверить это довольно легко, хотя

Подготовьте сценарий

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

Попытка № 1. Два файла скопированы, но не имеют жесткой ссылки

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"

Попытка № 2. Два файла, соединенных жесткой ссылкой

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

Если ваш экземпляр duне может обработать несколько экземпляров одного и того же жестко связанного файла, ваш эксперимент №2 вернет сумму обоих, etc.1как etc.2это было в эксперименте №1.

Используя эту информацию, вы можете определить, является ли ваша версия duвводящей в заблуждение или файлы действительно занимают больше места на диске, чем вы ожидаете. (Учитывая ваши другие показатели, я почти уверен, что это первое.)

Связанный контент