Хранилище Zimbra заполнено: как отличить квоту от диска

Если хранилище Zimbra заполнено, сначала я разделяю две причины: закончился ресурс файловой системы или достигнута квота отдельного ящика. Увеличение квоты не освобождает диск. Ниже — порядок проверки, команды чтения и план освобождения места без удаления файлов писем вручную, с расчётом для условного книжного магазина.

Что переполнено: один ящик или файловая система?

Я начинаю с масштаба сбоя. Если письма не получает один сотрудник, проверяю его квоту и ответ сервера при доставке. Если проблема затронула несколько ящиков, проверяю общие ресурсы и службы. Это порядок поиска, а не диагноз по числу жалоб: одновременно могут закончиться и квота, и свободное место. В обслуживании корпоративной почты мне нужен измеримый результат: причина отказа, затронутые ящики и подтверждённая доставка после исправления.

Квота ограничивает объём данных учётной записи внутри Zimbra. Свободное место показывает, сколько ещё может записать файловая система, где находятся почтовые данные и служебные файлы. Эти показатели отвечают на разные вопросы. Например, ящик может оставаться ниже своего лимита, а раздел уже не принимать запись из-за других данных. Обратная ситуация тоже возможна: на разделе места достаточно, но конкретный ящик достиг квоты. Поэтому я не начинаю аварийные работы с массового увеличения лимитов. Диск от административного оптимизма не растёт.

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

Файлы писем и записи о них связаны. Если удалить файл сообщения из /opt/zimbra/store, ссылка на него может остаться в метаданных, а открытие письма закончится ошибкой отсутствующего содержимого. Это не означает обязательное разрушение всей SQL-базы или необходимость переустановки. Но утраченный файл переиндексацией не вернуть: потребуется пригодная копия либо другой источник письма. Я запрещаю ручную чистку хранилища именно по этой причине. Работать со штатным удалением тоже нужно осмысленно: штатная команда не делает ненужное удаление обратимым.

• Один ящик: сверить квоту, фактический объём и ответ доставки.
• Несколько ящиков: проверить файловые системы, очередь и службы.
• Любой сценарий: сохранить время и текст ошибки до изменения настроек.
• Файлы сообщений в /opt/zimbra/store вручную не удалять.

Какие команды покажут, куда ушло место?

На сервере с GNU/Linux я сначала выполняю проверку файловых систем от root или через административную оболочку. Первая команда показывает занятый и доступный объём, вторая — использование inode, то есть записей о файлах. На файловых системах с ограниченным числом inode запись может остановиться при наличии свободных блоков. Смотрю на разделы с данными Zimbra, системными журналами, очередью и резервными копиями. Проверить только корневой раздел недостаточно: почтовое хранилище может быть смонтировано отдельно.

df -h
df -i

Затем оцениваю, какие каталоги выросли. Для обычного размещения Zimbra начальный просмотр выглядит так: du -x -h --max-depth=1 /opt/zimbra. Ключ -x удерживает обход в одной файловой системе, -h делает размеры читаемыми, а --max-depth=1 ограничивает глубину вывода. Если store или другой каталог находится на отдельном разделе, запускаю такой просмотр для его фактической точки монтирования отдельно. На большом хранилище обход создаёт нагрузку чтения, поэтому не запускаю несколько одинаковых измерений одновременно. Одна команда с результатом полезнее пяти зависших терминалов.

Мне нужны две разные проверки: сколько занято и что при этом работает. Из оболочки root перехожу в окружение Zimbra и запрашиваю состояние служб. Эта последовательность ничего не очищает. Если компонент остановлен, сохраняю его имя и сопоставляю со временем ошибок; массовый перезапуск оставляю до появления места и понимания причины. Универсального остатка «обязательно 50 ГБ» для любой установки нет. Рабочий запас я рассчитываю по росту данных и объёму ближайших операций, а требования к установке не выдаю за порог аварии.

su - zimbra
zmcontrol status

Для разбора ошибок почтового хранилища открываю /opt/zimbra/log/mailbox.log: там фиксируются операции mailbox-сервера, в том числе индексирование. Для почтового транспорта смотрю /var/log/zimbra.log при стандартной настройке системного журналирования. Это конкретные точки поиска, а не приказ удалить всё с расширением log. Если журнал быстро растёт, выясняю повторяющуюся ошибку и состояние ротации. Выключать журналирование целиком я не советую: место освободится ненадолго, а свидетельства причины исчезнут. Сохраняю нужный фрагмент на другом ресурсе и устраняю источник роста.

• Сверить доступные блоки и inode на нужных файловых системах.
• Измерить каталоги, учитывая отдельные точки монтирования.
• Выполнить zmcontrol status от пользователя zimbra.
• Сопоставить рост каталогов с журналами ошибок и заданиями копирования.

Как проверить квоту ящика и не обвинить индекс?

Размер одного ящика запрашиваю через zmmailbox, а квоту учётной записи — через атрибут zimbraMailQuota. Команды ниже выполняю от пользователя zimbra на сервере соответствующего ящика; user@example.com заменяю адресом из своей системы. Имя атрибута здесь существенно: zimbraQuota из случайной инструкции не подходит для этой проверки. Эти запросы ничего не удаляют и не увеличивают. Результат сохраняю до изменений, чтобы потом сравнить исходное состояние с итогом.

zmmailbox -z -m user@example.com gms
zmprov ga user@example.com zimbraMailQuota

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

Логический объём ящика нельзя механически вычесть из занятого места раздела и назвать остаток индексом. На разделе есть данные других пользователей, база, журналы, индексы и, возможно, копии. Универсальной нормы расхождения «20–30 %» я не применяю: сравниваемые показатели описывают разный состав данных. Сначала измеряю категории отдельно. Если места хватает, а система тормозит, нужен уже поиск узкого места, а не автоматическое назначение виноватым самого большого ящика.

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

• Размер ящика: zmmailbox -z -m user@example.com gms.
• Квота учётной записи: zmprov ga user@example.com zimbraMailQuota.
• Перед сравнением привести размеры к одинаковым единицам.
• Не запускать переиндексацию по возрасту или универсальному проценту расхождения.

Разбор: ящик ниже квоты, а раздел почти полон

Разберу учебный сценарий для книжного магазина «Полка знаний» в Подмосковье: 20 рабочих мест и собственная Zimbra. Это условный расчёт, а не отчёт о реальной аварии. Задаю исходные данные: файловая система объёмом 200 ГиБ занята на 196 ГиБ, из них 30 ГиБ приходится на завершённые резервные копии, пригодные для переноса. Размер одного ящика — 45 ГиБ при квоте 50 ГиБ. Для простоты расчёта служебные резервы файловой системы и изменение данных во время работ не учитываю. Все объёмы в этом примере заданы в одинаковых единицах.

По этим условиям раздел занят на 98 %, свободны 4 ГиБ, а ящик использовал 90 % квоты. Значит, лимит этого ящика ещё не достигнут. Ни квота, ни цифра 98 % отдельно не доказывают причину остановки доставки: я проверяю доступность записи и ошибки служб. Но запас раздела явно мал по отношению к выбранной операции копирования. Увеличить квоту с 50 ГиБ до большего значения можно, однако свободные 4 ГиБ от этого не изменятся. Предлагать такую правку как освобождение диска — бухгалтерия желаний.

Если подтверждено, что эти 30 ГиБ можно перенести без нарушения цепочки восстановления, сначала проверяю внешнее место назначения, состав копий и их пригодность. Затем переношу выбранный набор по процедуре используемого средства резервирования и лишь после проверки удаляю исходный набор допустимым способом. При неизменности остальных данных занятый объём уменьшится до 166 ГиБ, свободный вырастет до 34 ГиБ, заполнение станет 83 %. Ящик останется размером 45 ГиБ с прежней квотой. Это расчёт ожидаемого эффекта, который после работ нужно сверить с фактическим измерением.

Я не приписываю такому сценарию индекс на 30 ГиБ, самопроизвольную генерацию временных файлов или восстановление ровно за час: без измерений это литературные подробности. Практический итог здесь другой: найден общий потребитель места, выбран проверяемый способ его переноса, квоту не меняют без необходимости. После освобождения проверяю службы и тестовую доставку. Долгосрочное решение принимаю уже по скорости роста: перенастроить хранение копий, расширить существующий том, если позволяет платформа, либо добавить ресурс. Увеличение диска не всегда требует покупки нового физического накопителя.

• Исходные условия: 200 ГиБ всего, 196 ГиБ занято, 4 ГиБ свободно.
• Ящик: 45 ГиБ при квоте 50 ГиБ; превышения квоты нет.
• Проверяемый перенос копий: 30 ГиБ на независимое хранилище.
• Расчёт после переноса: 166 ГиБ занято, 34 ГиБ свободно, заполнение 83 %.
• Эффект подтверждается измерением и проверкой доставки.

Что можно освободить и почему «Архив» не помогает?

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

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

Папка «Корзина» и dumpster — разные этапы хранения. При включённом dumpster сообщения после удаления могут оставаться доступными для восстановления до истечения настроенного срока. Это не универсальная папка Recoverable Items с обязательной ежемесячной чисткой. Я проверяю, включена ли функция, какие сроки действуют и допускается ли окончательное удаление нужных данных. Уменьшение видимого пользователю объёма ещё не доказывает такое же немедленное освобождение файловой системы. Результат проверяю повторным измерением, а право восстановить случайно удалённое письмо не отменяю ради красивой полоски.

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

• Проверить завершённые копии и ротацию журналов до удаления.
• Письма удалять через Zimbra с согласованным составом данных.
• При переносе архива проверить чтение и восстановление с нового ресурса.
• Согласовать сроки хранения и поведение dumpster.
• Лимит размера сообщения настроить под реальные рабочие задачи.

Как подтвердить восстановление и не повторить аварию?

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

Для предупреждения следующего переполнения мне нужны доступные блоки, inode там, где они ограничены, и скорость изменения объёма. Достаточность запаса оцениваю по времени до заполнения и ближайшим тяжёлым операциям. Условный расчёт: 12 ГиБ доступно при устойчивом росте 3 ГиБ в сутки — примерно четыре суток без учёта скачков. Это прогноз по заданным условиям, а не срок, который можно бездействовать. Если ближайшая копия требует больше доступного места, вмешиваться нужно раньше. Одного процента заполнения для решения недостаточно: важны абсолютный остаток и темп роста.

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

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

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

Частые вопросы