На сервере стало уменьшаться свободное место. Какое-то время не придавал этому значения, т.к. чётко знал, что у меня дважды в день работает скрипт автоматического бекапа базы данных с выгрузкой в облако.
Хранить бекапы в том же месте, что резервировалось — глупый риск. Поэтому я просто чистил устаревше архивы на сервере ручками раз в несколько дней, т.к. они уже есть в облаке.
Однажды утром, после свежего бекапа, MySQL стал падать с ошибкой:
Got error 28 from storage engine
Эта ошибка возникает во время выборки записей из БД. Поскольку выборка хранится в кеше на диске и в этот момент возникает ошибка, значит что-то с ним не так. Самое банальное — закончилось место. По факту так и оказалось. MySQL-у просто негде было хранить файлы кеша.
Но как? На сервере свежий бекап только один, и его размер несоизмеримо меньше, чем сейчас должно быть свободного места.
Начал поиски обжоры.
Глаз сразу упал на огромного размера директорию /var/cache. Захожу внутрь.
В директории /var/cache/davfs2/webdav.yandex.ru+mnt-yadisk+root/ хранится кеш файлов, которые davfs2 отправляет в облако Яндекс.Диска. Последняя директория может отличаться своим именем от моего, смотря в какую точку у тебя монтируется Я.Диск.
В моём случае это бекапы базы данных. Кеш представляет собой полные копии отправленных файлов с оригинальным размером, но в конец имени каждого файла ставятся 6 рандомных (?) символов для 100% уникальности. Плюс есть файл index с xml-описанием этих файлов.
Супер.
Об этой особенности davfs2 я не знал. Получается, в результате работы моего скрипта мы имеем два локальных дубликата одной РК: оригинал РК и тот файл, что образуется после заливки оригинала в облако. Одна РК занимает в 2 раза больше места, чем должна.
Директория кеша подлежит полной очистке.
Зато теперь есть ещё одна мысль для доработки скрипта автоматического бекапа в облако, где используется эта утилита.