После mount файлы исчезли: как найти скрытые данные каталога

В /srv/data были файлы, затем подключили отдельный диск, и каталог выглядит пустым. Позже корневой раздел начал заполняться, хотя du по видимым каталогам не находит источник. Монтирование могло закрыть доступ к прежнему содержимому: старые файлы остались на нижележащей файловой системе.

Проверить границу монтирования

findmnt -T /srv/data
findmnt -T / -o TARGET,SOURCE,FSTYPE
df -h / /srv/data

Если /srv/data обслуживается отдельным устройством, видимые файлы относятся к нему. Само mount не переносит туда содержимое старого каталога. Чтобы понять происхождение данных, сравните источники файловых систем, время подключения и порядок запуска приложения.

Типичный сценарий: после загрузки служба начинает писать в /srv/data раньше подключения тома. Затем том монтируется и закрывает уже созданные файлы. Они занимают корневой раздел, но обычный обход /srv/data видит верхний том. Удаление видимых файлов тогда освобождает место на другом устройстве.

Открыть нижний слой отдельно

Самый простой способ на стенде — остановить потребителей и штатно размонтировать том. Для рабочей системы это может быть недопустимо. Другой приём — нерекурсивно bind-монтировать родительскую файловую систему в отдельную диагностическую точку, чтобы не переносить её вложенные mounts.

mkdir /mnt/root-view
mount --bind / /mnt/root-view
findmnt -T /mnt/root-view/srv/data
du -sh /mnt/root-view/srv/data

Это действия администратора для согласованного обслуживания; каталог /mnt/root-view должен быть новым и пустым. Обычный --bind отличается от --rbind: рекурсивный вариант перенесёт вложенные монтирования и снова скроет искомый слой. Поведение описано в mount(8).

До чтения и тем более изменения проверьте findmnt: путь диагностического представления должен вести к ожидаемому нижнему источнику. Если структура содержит другие mounts или symlink, скорректируйте план. Не считайте наличие похожих имён достаточным доказательством.

Разобрать найденные файлы

Предположим, рабочий /srv/data содержит 2 ГиБ на data-LV, а /mnt/root-view/srv/data — 18 ГиБ на root-LV. Это два разных набора. Сохраните даты, владельцев и назначение нижних файлов. Среди них могут быть результаты, которые приложение создало до подключения тома и ещё нигде не обработало.

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

Не допустить повторения

Настройте явную зависимость службы от доступности нужной файловой системы. В systemd для пути подходит RequiresMountsFor=/srv/data, с проверкой фактического unit и поведения при отказе mount. Само наличие каталога ничего не говорит о подключённом устройстве, поэтому проверка test -d не защищает от записи в нижний слой.

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

Ещё по теме

• Нужна копия каталога только для чтения: проверяем readonly bind
• Mount появился в другом окружении: проверяем propagation