Как я очищаю ящики Zimbra: копия, корзина, контроль

Чтобы безопасно очистить ящик Zimbra, я проверяю восстановление из копии, согласовываю состав удаляемых писем и очищаю нужную папку штатным инструментом. Затем отдельно измеряю размер ящика и свободное место на диске. Ни перенос в «Архив», ни увеличение квоты сами по себе место не освобождают. Ниже — команды, порядок проверки и пример регламента.

Что проверить перед очисткой ящиков Zimbra

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

Для отчёта по серверу база знаний даёт конкретный инструмент: zmprov gqu. Отдельный ящик проверяю через zmmailbox gms. Команды ниже выполняю на сервере Zimbra от системного пользователя zimbra; mail.example.com заменяю именем нужного mailbox-сервера, user@example.com — адресом проверяемого аккаунта. На установке с несколькими mailbox-серверами собираю отчёт с каждого. Для административной консоли типовой адрес — https://mail.example.com:7071/; фактический адрес беру из настроек своей установки.

zmprov gqu mail.example.com
zmmailbox -z -m user@example.com gms
zmmailbox -z -m user@example.com gaf

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

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

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

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

Как составить план очистки для небольшого офиса

Разберу условное ателье «Нить времени» в Подмосковье: 32 рабочих места. Это учебная ситуация с расчётными объёмами, а не отчёт о реальном клиенте. Количество рабочих мест само по себе не определяет число аккаунтов: отдельно учитываю личные и общие ящики. Для примера беру три наиболее заполненных рабочих ящика с одинаковой квотой 50 ГиБ. Значение выбрано для расчёта, универсальной рекомендуемой квотой оно не является.

В этом примере исходное использование — 49, 48 и 46 ГиБ. После просмотра содержимого владельцы согласовали удаление 6, 7 и 6 ГиБ из корзин. При отсутствии новых поступлений расчёт выглядит так: | Ящик в примере | До, ГиБ | Согласовано удалить, ГиБ | После, ГиБ | |---|---|---|---| | Рабочий А | 49 | 6 | 43 | | Рабочий Б | 48 | 7 | 41 | | Общий | 46 | 6 | 40 | | Сумма | 143 | 19 | 124 | Это изменение учёта данных в ящиках. Из таблицы нельзя вывести, сколько физических гигабайтов немедленно вернётся файловой системе.

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

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

Результат такого пилота я принимаю по актуальным измерениям: новые размеры ящиков, состояние доставки и доступность сохранённых писем. Расчётные 19 ГиБ не выдаю за измеренный выигрыш диска. После пилота уточняю план для остальных аккаунтов и только затем согласовываю следующую группу. Если выяснилось, что данные нужны в работе, меняю план хранения. Удаление не становится правильным от того, что его уже внесли в календарь.

• Зафиксировать исходные размеры и версии
• Согласовать папки с владельцами
• Запланировать проверку восстановления
• Начать с одного рабочего ящика
• Принять пилот по измерениям

Какая копия нужна до удаления писем

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

База знаний подтверждает экспорт данных Zimbra в TGZ. Но экспорт через веб-интерфейс или zmmailbox не является полным резервированием почтовой системы. Он не подменяет копии конфигурации, каталога учётных записей и других компонентов, необходимых для восстановления сервиса. Я выбираю поддерживаемую для установленной редакции схему резервирования и отдельно сохраняю согласованную выборку писем. Для больших объёмов проверяю ограничения экспорта и делю проверку на части, если единый архив не проходит испытание.

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

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

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

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

Как очистить корзину и не перепутать её с Dumpster

Обычную корзину я очищаю адресно. Сначала повторно проверяю аккаунт и путь через gaf из первого раздела. Если в выводе нужная папка действительно имеет путь /Trash, её содержимое согласовано и копия проверена, использую emptyFolder, сокращённо ef. Ниже показана операция для одного ящика. Она удаляет содержимое указанной папки; это не предварительный просмотр. Адрес примера обязательно заменяю до запуска, путь беру из вывода своей установки.

zmmailbox -z -m user@example.com ef /Trash

Здесь нельзя подставлять PurgeMessagesRequest в качестве синонима очистки корзины. В официальном описании SOAP-запроса указано удаление писем по срокам хранения из корзины, спама и всего ящика. Если элемент mbox не задан, обработка распространяется на все ящики сервера. Я убираю такой запрос из универсального рецепта: его область зависит от действующих политик, а не от желания автора инструкции. Команда короткая, последствия в её длину не помещаются.

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

Я не опустошаю Dumpster автоматически ради красивого числа в отчёте. Сначала проверяю срок хранения, разрешения на окончательное удаление и ограничения для выбранного аккаунта. Если требуется сохранить переписку, меняю план ёмкости или переноса данных. Отключать защиту хранения только ради освобождения места — значит менять задачу без согласования. У пользователя должно оставаться понятное объяснение, почему письмо ещё восстанавливается или почему после принятого решения уже не будет доступно.

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

• Сверить адрес ящика и путь папки
• Подтвердить копию и согласованный состав
• Выполнить ef только для выбранной корзины
• Отдельно проверить Dumpster и место на диске
• Повторить измерения и тест доставки

Как настроить квоты и сроки без ложных обещаний

Квоту я рассчитываю по фактическому объёму, росту переписки и доступной ёмкости. Офис на 32 рабочих места не получает автоматически норму 5–10 ГБ каждому: у общего ящика с заказами и у технических уведомлений разные задачи. Лимиты можно задавать через класс обслуживания, COS, и настройки аккаунтов. Перед изменением смотрю, откуда берётся действующее значение. Повышение лимита согласовываю вместе с прогнозом ёмкости, иначе оно лишь отодвигает очередное предупреждение.

Для штатного предупреждения проверяю zimbraQuotaWarnPercent и zimbraQuotaWarnInterval: первый задаёт порог, второй — минимальный интервал между предупреждениями. Это не готовая лестница из 80 %, 90 % и 95 %. Например, для выбранного аккаунта можно установить порог 90 % командой ниже. Это пример настройки, а не обязательный стандарт для всех. Прежнее значение сохраняю; после изменения проверяю фактические уведомления и отдельно настраиваю отчёт администратору.

zmprov ma user@example.com zimbraQuotaWarnPercent 90

Из базы добавляю ещё одну конкретную настройку: zimbraMailTrashLifetime отвечает за срок хранения в обычной корзине. Значение подбираю по принятому регламенту; встреченное в чужой инструкции число не становится настройкой своей системы. Проверяю также пользовательскую политику zimbraPrefTrashLifetime: по документации при совместном применении используется меньший срок. Автоматическая обработка зависит и от серверной настройки запуска очистки. Поэтому «хранить неделю» и «запускать уборку раз в неделю» — разные условия.

Фильтр почты не выдаю за ежедневный планировщик удаления по возрасту. Он обрабатывает сообщения по условиям, а в Classic Web App его можно отдельно применить к уже полученным письмам через Run Filter. Наличие такого действия не доказывает, что завтра всё старше выбранного срока исчезнет само. Для регулярной обработки проверяю поддерживаемые политики хранения, область действия и порядок запуска. Сначала испытываю правило на ограниченной выборке с просмотром результата, затем расширяю применение.

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

• Назначить квоты по расходу и росту
• Проверить COS и настройки аккаунта
• Выбрать порог и интервал предупреждений
• Согласовать срок хранения корзины
• Испытать автоматическое правило на выборке

Когда архив освобождает место и как принять работу

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

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

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

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

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

• Проверить доступность и удобство архива
• Согласовать удаление исходников после проверки
• Сверить размер ящиков и запас диска
• Испытать доставку и сигналы мониторинга
• Передать журнал работ и дату следующей проверки

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