%20%D1%81%D0%BC%D0%BE%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D1%8B%D0%B9%20%D1%82%D0%BE%D0%BC%3A%20%D0%B6%D0%B5%D1%81%D1%82%D0%BA%D0%B8%D0%B5%20%D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B8%2C%20%D0%BF%D0%BE%D1%85%D0%BE%D0%B6%D0%B5%2C%20%D1%81%D0%BE%D1%85%D1%80%D0%B0%D0%BD%D1%8F%D1%8E%D1%82%D1%81%D1%8F%2C%20%D0%BD%D0%BE%20%D0%BF%D1%80%D0%BE%D1%81%D1%82%D1%80%D0%B0%D0%BD%D1%81%D1%82%D0%B2%D0%BE%20%D1%80%D0%B0%D1%81%D1%81%D1%87%D0%B8%D1%82%D1%8B%D0%B2%D0%B0%D0%B5%D1%82%D1%81%D1%8F%20%D0%BA%D0%B0%D0%BA%20%D0%BF%D0%BE%D0%BB%D0%BD%D1%8B%D0%B5%20%D1%84%D0%B0%D0%B9%D0%BB%D1%8B.png)
Я пытаюсь настроить схему ротационного резервного копирования с эффективным использованием пространства с помощью rsnapshot / rsync с сервера на хранилище Hetzner. Мне сложно понять, как жесткие ссылки на месте назначения влияют на отчет об использовании диска. Короче говоря: хотя жесткие ссылки, кажется, присутствуют на месте назначения резервного копирования, они, похоже, не учитываются при использовании диска, а вместо этого считаются полными файлами.
Поскольку папка назначения rsnapshot должна находиться в локальной файловой системе, я настроил рабочий процесс, состоящий из двух частей:
- создать локальный снимок с помощьюrsnapshot, в локальной папке на исходном сервере
- rsync, что локальный снимок через SSH сrsyncк месту назначения
Кажется, это работает хорошо и быстро, но у меня есть одно замечание: использование диска, сообщаемое в месте назначения (с du -sh
), похоже, суммирует размер всех снимков,даже если они, кажется, были скопированы правильно с использованием жестких ссылокПримечание: поскольку хранилища Hetzner не поддерживают интерактивный вход по SSH, я проверяю это место назначения резервной копии как смонтированный том с CIFS.
Например, после 3 раундов этой комбинации rsnaphsot + rsync папка назначения содержит папки daily.0
, daily.1
и daily.2
. При проверке случайных файлов в этих папках снимков на наличие жестких ссылок я получаю ожидаемые результаты:
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 (как и ожидалось)
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
вводящей в заблуждение или файлы действительно занимают больше места на диске, чем вы ожидаете. (Учитывая ваши другие показатели, я почти уверен, что это первое.)