Резервные копии связаны hardlink: почему размеры каталогов не складываются

Система резервного копирования хранит ежедневные каталоги. Каждый по отдельности выглядит как полный набор на 80 ГиБ, но весь месяц занимает 110 ГиБ. При удалении вчерашней копии место почти не меняется. Если неизменившиеся файлы объединены hardlink, это ожидаемо: несколько имён ссылаются на один inode и одни данные.

Подтвердить общие inode

stat -c '%n device=%d inode=%i links=%h size=%s' /srv/backup/day1/config.db /srv/backup/day2/config.db
du -sh /srv/backup/day1
du -sh /srv/backup/day2
du -sh /srv/backup

Одинаковые device и inode у двух путей подтверждают один объект. links показывает число жёстких ссылок. Сравнивать только inode без устройства нельзя: разные файловые системы могут использовать одинаковые номера. Символическая ссылка — другой механизм; она содержит путь и не делает два имени одним inode.

Обычный du старается не считать один hardlinked inode несколько раз в рамках одного обхода. При отдельных запусках на day1 и day2 каждый обход видит свои данные впервые. Поэтому сумма независимых результатов может быть больше результата одного обхода родительского дерева. Для особого подсчёта есть --count-links; это другая метрика, а не исправление обычного du.

Понять эффект удаления

Предположим, 75 ГиБ в day1 также имеют ссылки из day2, а 5 ГиБ принадлежат только day1. Удаление имён day1 освободит примерно эти уникальные 5 ГиБ, с поправкой на блоки и метаданные. Общие 75 ГиБ останутся нужны day2. Открытые процессы и snapshots файловой системы могут дополнительно удерживать данные.

Поэтому «размер удаляемого каталога» не равен гарантированно освобождаемому месту. Для оценки нужны уникальность объектов относительно остающегося набора и особенности файловой системы. Утилиты резервного копирования часто имеют собственный отчёт об объёме уникальных данных; сверьте его определение с тем, что измеряется.

Не менять содержимое связанной копии

Обычная запись в hardlinked файл через одно имя меняет тот же объект, видимый через остальные имена. Это критично для резервных копий: ручное исправление файла в day1 может изменить и day2. Программа, заменяющая файл через новый inode и rename, ведёт себя иначе. Нельзя выводить безопасность редактирования только из разных путей.

du -sh --count-links /srv/backup
find /srv/backup/day1 -xdev -type f -links +1 -print

Первая команда показывает сумму с повторным учётом ссылок, вторая помогает увидеть многоссылочные файлы в выбранном дереве. Это чтение метаданных, не план удаления. На больших каталогах обход сам создаёт нагрузку, поэтому выбирайте подходящее окно.

Описать retention в терминах восстановления

Удаляйте копии штатным инструментом и по согласованной политике хранения. Проверьте, какие точки восстановления остаются, затем измерьте фактический расход тома. Низкое освобождение места после одного удаления может быть корректной работой дедупликации через hardlink, а не ошибкой команды.

Откройте программу Linux и Bash для DevOps-инженеров. Разбор файловой системы и проверка резервного восстановления помогут читать такие размеры осмысленно и принимать решения о хранении с учётом сохранённых точек восстановления.

Ещё по теме

• Образ занимает мало места, а копия огромная: разбираем sparse-файлы
• CLOSE_WAIT растёт: почему перезапуск сети не закрывает сокеты приложения