Откуда растёт диск VPN-сервера и как его ограничить

Туннель перестаёт принимать соединения, служба дважды перезапускается, и после этого в её журнале ничего не появляется. Эта тишина и есть подсказка: диск заполнил именно журнал, и демону некуда записать ошибку, которую вы ждёте. В такое состояние может попасть любая длительно работающая служба, и удаление каталога с именем logs редко это исправляет. Надёжное решение — знать, какое хранилище выросло, кому принадлежит политика его хранения и освободил ли писатель место на самом деле.

Найдите хранилище, которое выросло, и скорость его роста

Начните с двух чисел, которые легко забыть: свободные блоки и свободные inode. Файловая система может сообщать о множестве места и всё равно отказать в записи, потому что inode закончились, а это бывает, когда служба создаёт по файлу на сеанс. Запросите оба показателя на одном томе, потому что ответы могут разойтись в тот же день. Делайте это, пока хост здоров, чтобы числа описывали нормальную работу, а не сбой.

df -h /var
df -i /var

Затем отнесите рост к владельцу. Собственный показатель расхода journal охватывает только journal и никогда не увидит демон, который пишет по пути из своего файла конфигурации.

journalctl --disk-usage

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

Что ротация делает с открытым файлом

Файл журнала — это имя, указывающее на inode, и место возвращается только когда закрывается последний открытый дескриптор. Переименуйте файл, и писатель продолжает заполнять тот же inode; удалите его, и писатель продолжает заполнять inode вообще без имени. Именно поэтому фраза «я удалил файл, а диск остался полным» описывает файловые дескрипторы, а не сломанную файловую систему. Перезапуск писателя или выбор режима ротации, который заново открывает файл, — это то, что действительно возвращает блоки.

lsof +L1 | head

Политика принадлежит компоненту, который пишет файл. Journal применяет свои ограничения хранения из собственного файла конфигурации, а служба на основе файлов обычно полагается на logrotate, либо с правилом создания и сигналом повторного открытия, либо с режимом обрезки на месте, когда писатель не может открыть файл заново. Сначала подтвердите решение, ничего не меняя:

logrotate -d /etc/logrotate.conf

Где место пределу и каким он должен быть

Ставьте предел там, где настроен писатель, а не в точке монтирования. Квота на весь том защищает хост, но ничего не говорит о том, какая служба откажет первой, а глобальный скрипт очистки склонен удалять доказательства, нужные следующему инциденту. Предел journal, число ротаций с максимальным размером и хранение на уровне приложения каждый ограничивает одного производителя. Вместе они ограничивают общее; по отдельности каждое — догадка.

Рассчитывайте этот предел от срока хранения, который вы можете защитить, а не от свободного места. Если для проверки нужна неделя попыток подключения, journal должен держать неделю при самой высокой ожидаемой скорости, и эта скорость — число, измеренное ранее.

Журнал отладки — временный режим с зафиксированным временем начала, а не план хранения. Держите вопрос приватности в том же решении, потому что журналы соединений несут адреса и идентификаторы. Более долгое хранение — это ещё и выбор обработки данных, и его должен делать тот, кто знает оба ограничения.

Проверьте предел после перезапуска

Изменение хранения, которое держится до следующего перезапуска, не является изменением. Перезапустите писателя, подтвердите, что новый предел действует, и проверьте, что ротация после этого ещё работает. Для journal один перезапуск и одно измерение расхода отвечают на оба вопроса:

systemctl restart systemd-journald
journalctl --disk-usage

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

Сравните следующее измерение с этим

Вернитесь через неделю и сравните скорость роста с записанной. Совпадающая скорость означает, что предел держится и нагрузка стабильна; удвоенная скорость означает, что что-то изменилось, и полезный вопрос — что. Сначала прочитайте содержимое журнала на предмет повторяющихся сбоев, потому что цикл повторных попыток — одновременно симптом и причина объёма. Затем проверьте всё недавно включённое, включая уровни отладки, включённые во время инцидента и так и не выключенные.

Держите резервные копии вне того же тома или примите, что один полный диск унесёт копию с собой. Копия, записанная на хост, который она защищает, не является планом восстановления, и для её хранения нужен собственный ответ.

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