DavFS2. Куда утекает свободное место? Got error 28 from storage engine

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

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

Однажды утром, после свежего бекапа, 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 раза больше места, чем должна.

Директория кеша подлежит полной очистке.

Зато теперь есть ещё одна мысль для доработки скрипта автоматического бекапа в облако, где используется эта утилита.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *