Диск почтового сервера на 92%

Цифры, от которых отталкиваюсь:

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

Коротко

• 92% — это не «есть ещё 8%», а «осталось столько, сколько нарастает за известное время». Смотреть надо на скорость, а не на процент.
• У почты заполненный диск отказывает не одним способом, а несколькими сразу.
• Кроме места надо мониторить inode и возраст последнего успешного бэкапа.
• Бэкап, который никогда не восстанавливали, — это не бэкап, а предположение.

Чем опасно заполнение диска именно у почты

Обычный веб-сервис на полном диске перестаёт писать логи и продолжает кое-как работать. Почтовый сервер устроен иначе: запись — это его основная операция. Каждое входящее письмо надо положить на диск.

Отсюда несколько отказов сразу, и все неприятные по-разному.

Приём писем прекращается. В лучшем случае отправляющая сторона получит временную ошибку и будет повторять попытки несколько дней — тогда почта «задержится», но не потеряется. В худшем письмо будет отвергнуто окончательно. Разница между этими двумя исходами зависит от того, как именно сервер ответит, и это не то, чем хочется управлять в аварийном режиме.

Индексы Dovecot перестают обновляться. Пользователи при этом видят не ошибку, а странности: письма есть, но не находятся поиском, папка показывает не то количество.

База и очереди страдают молча. Сервис, которому не дали дописать файл, ведёт себя непредсказуемо, и восстановление после такого дороже, чем после честного отказа.

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

Почему процент — плохая метрика

92% выглядит как «есть запас 8%». В абсолютных числах запас — 196 ГБ, и это звучит солидно.

Но сам по себе процент не отвечает на единственный важный вопрос: сколько осталось времени. Ответ на него даёт не занятое место, а скорость роста. Если почта прибавляет гигабайт в сутки — впереди полгода. Если двадцать — две недели. Одна и та же цифра 92% означает в этих случаях совершенно разное.

Поэтому метрика, которую стоит снимать, — не «сколько занято», а «на сколько выросло за неделю». Первая подсказывает, что пора беспокоиться. Вторая говорит, когда именно.

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

Что мониторить, кроме занятого места

Свободные inode. Maildir хранит каждое письмо отдельным файлом, и на файловой системе можно исчерпать не место, а количество файлов. Симптом при этом особенно сбивает с толку: df показывает свободные гигабайты, а файл создать нельзя.

df -i /var/lib/docker

Возраст последнего успешного бэкапа. Не факт его существования, а именно возраст последнего успешного — потому что молча сломавшийся бэкап выглядит точно так же, как работающий, ровно до того дня, когда понадобится.

Размер самых больших ящиков. Полезно знать не только общий объём, но и то, кто его занимает:

docker compose exec dovecot-mailcow doveadm quota get -A

Квота домена, если она общая. Она может кончиться раньше, чем диск, и последствия будут видны раньше — вплоть до того, что люди не смогут войти в почту.

Про резервное копирование

Две вещи, которые я считаю обязательными, и обе про проверку, а не про настройку.

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

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

Дополнительный аргумент для почтового сервера: полный диск умеет ломать и сам бэкап. Если копия делается локально перед отправкой, то на 98% заполнения она перестанет создаваться — и вы потеряете резервирование ровно тогда, когда оно нужнее всего.

Что бы я сделал иначе

Поставил бы порог не на 90%, а на скорость роста, и завёл бы предупреждение задолго до того, как цифра станет тревожной.

Причина простая. 92% — это уже не метрика для планирования, это метрика для реагирования. На таком уровне выбор невелик: срочно чистить, срочно расширять или срочно архивировать. Все три варианта делаются в спешке, а спешка на почтовом сервере — отдельный источник происшествий.

Разговор «у нас прибавляется столько-то в месяц, через полгода упрёмся» проходит спокойно и заканчивается решением. Разговор «осталось 8%» проходит иначе.