Чинить Zimbra или переезжать: 14 параметров для решения

К клиенту-бухгалтерской фирме на Тверской я приехал не чинить почту, а ответить на один вопрос: во что вкладываться. Сервер работал, но упирался в конец поддержки. Ниже — четырнадцать параметров, по которым я принимаю такое решение за день, и разбор того, как один непроверенный пункт чуть не перевернул смету на четверть миллиона.

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

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

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

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

Первый час ушёл на снятие фактуры. Вот что я увидел:

Release 8.8.15_GA_3869.RHEL7_64_20190917004220 RHEL7_64 FOSS edition, Patch 8.8.15_P30.

$ cat /etc/redhat-release
CentOS Linux release 7.9.2009 (Core)

$ zmprov gad | wc -l
2
$ zmprov -l gaa | wc -l
34
$ du -sh /opt/zimbra/store /opt/zimbra/index /opt/zimbra/db
389G    /opt/zimbra/store
27G     /opt/zimbra/index
19G     /opt/zimbra/db

Два домена. Тридцать четыре ящика, из них шесть служебных — galsync, spam, ham, virus-quarantine и две заброшенные учётки уволившихся. Реальных пользовательских — 28, ровно по числу людей.

Дальше плохое. Ветка 8.8.15 Open Source снята с общей поддержки 31 декабря 2023 года — обновлений безопасности с тех пор не выходило. Под сервером CentOS 7.9, у которой поддержка закончилась 30 июня 2024-го. То есть на февраль 2026 года мёртвы оба слоя: и приложение, и операционная система. Патч 8.8.15 P46, который закрывает RCE через postjournal, на сервере не стоял — там был P30.

Счёт подрядчика, из-за которого меня позвали, был на «обновление до Zimbra 10». Я сразу сказал: в лоб этого может не получиться, и на официальном форуме есть целая ветка людей, у которых обновление с восьмёрки и девятки до десятки в их конфигурации не прошло. Но говорить это без цифр — то же самое, что гадать. Поэтому я пошёл по списку.

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

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

Пункт 2 — редакция. У Open Source-редакции нет встроенного бэкапа. Вообще. Это не мелкая деталь, а отдельная строка в любой смете: либо вы платите за коммерческий модуль, либо строите свою схему и потом её обслуживаете. Клиенты про это чаще всего не знают и искренне верят, что «Zimbra бэкапится сама». На Тверской фраза «а разве она не сама?» прозвучала дословно.

Пункт 10 — телефоны. В бесплатной редакции с телефона гарантированно живёт только почта по IMAP. Календарь и контакты вытянуть можно — по CalDAV и CardDAV, но каждый телефон настраивается руками и без push. ActiveSync с автоматической настройкой профиля, push-уведомлениями и глобальной адресной книгой — это отдельный модуль, который к бесплатной редакции докупается. Если ваши люди годами живут с телефонным календарём — вы уже за что-то платите, и это меняет расчёт целиком: платный модуль надо будет либо продлевать на старой платформе, либо заменять функцией новой.

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

Восемь из четырнадцати параметров снимаются одной пачкой команд. Под пользователем zimbra:

zmcontrol -v
cat /etc/os-release | head -2
zmprov gad
zmprov -l gaa | wc -l
zmprov gaaa
du -sh /opt/zimbra/store /opt/zimbra/index /opt/zimbra/db
zmprov -l gaa | while read u; do echo -n "$u "; zmmailbox -z -m "$u" gms; done | sort -k2 -h | tail -5
zmprov gs $(zmhostname) zimbraServiceEnabled

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

Как читать:

Шестая строчка таблицы — про тот самый пункт, на котором я в феврале чуть не сел в лужу.

К концу второго часа картина казалась очевидной. Двадцать восемь ящиков, 389 ГБ store, календари пустые у всех кроме двух человек, общих папок три, телефоны настроены по IMAP. Классический «переезжаем за выходные». Я так и написал в черновике: переезд на mailcow, 26 часов работ, две ночи, откат через сохранённый старый сервер.

Пункт 11 я почти пропустил. Логика была ленивая: откуда у бухгалтерской фирмы самописные расширения к почте. Проверил формально, для галочки:

$ ls /opt/zimbra/zimlets-deployed/
com_zimbra_attachcontacts  com_zimbra_date  com_zimbra_email  com_zimbra_url
com_buhfirm_dela

$ zmprov gc default zimbraZimletAvailableZimlets | grep buhfirm
zimbraZimletAvailableZimlets: +com_buhfirm_dela

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

Заодно выяснилось, что под него в схему LDAP добавлен свой атрибут для хранения идентификатора договора. То есть сервер не «чистая Zimbra из коробки», а Zimbra с правками в каталоге — и это ровно тот класс конфигураций, где обновление на десятку спотыкается.

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

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

Дальше я свёл всё в две колонки. Часы наши, реальные. Ставка инженера у нас 3 500 ₽ в час, по ней и считаю рубли — если у вашего подрядчика ставка другая, пропорция между колонками от этого не меняется.

Разница в шестнадцать часов, или 56 000 ₽, — это не разница. Она укладывается в погрешность одной непредвиденной ночи. Поэтому решение принималось не по нижней строке, а по строке «что получаем на выходе» и по пункту 14: кто это будет вести дальше.

А теперь про цену бездействия, потому что был и третий сценарий — «ничего не делать». Считаю честно. Сервер с непокрытым RCE, доступный из интернета, в бухгалтерской фирме, у которой в почте лежат сканы паспортов, договоры и платёжки семидесяти юрлиц. Разбор одной такой компрометации у другого нашего клиента занял три недели и 147 часов работ — по той же ставке это 514 500 ₽: криптомайнер, root через sudo, повторное заражение уже после первой чистки — сервер в итоге пришлось выводить и мигрировать всё равно, но в аварийном режиме и без выбора платформы. То есть «ничего не делать» — это не ноль часов. Это те же 88 часов и 308 000 ₽, только когда-нибудь потом, плюс полмиллиона на разбор и три дня, в которые 28 бухгалтеров не работают. День простоя мы для таких смет считаем скромно: 28 человек по 8 часов при себестоимости часа 1 200 ₽ — это 268 800 ₽ в сутки, то есть три аварийных дня стоят дороже всего планового переезда.

Выбрали переезд. Решающими оказались три пункта: мёртвая ОС под сервером, отсутствие человека, который вёл бы Zimbra дальше, и то, что бэкапа фактически не было — рсинк каталога /opt/zimbra на NAS раз в неделю без единой попытки восстановления за шесть лет.

Куда переехали — на mailcow. Не потому что она объективно лучше всех, а потому что мы её знаем: у нас в собственном парке 22 домена и 218 ящиков на ней, и я представляю, что там сломается и когда. Для тех, кому важна максимальная близость к привычному интерфейсу и логике Zimbra, ближайший кандидат другой — Carbonio Community Edition, она собрана на том же стеке: Postfix, OpenLDAP, Jetty, делает её та же команда Zextras.

Порядок был обычный:

1. Снизили TTL DNS до 300 секунд за сутки до переключения.
2. Выгрузили домены, ящики, алиасы, списки рассылки и хэши паролей через zmprov.
3. Подняли новую площадку, создали учётки, залили хэши — люди зашли со старыми паролями, ни одной заявки «не могу войти».
4. Прогнали почту через imapsync в три захода: полный прогон, дельта через неделю, финальная дельта в ночь переключения.
5. Переключили MX в ночь с субботы на воскресенье, старый сервер держали ещё девять дней с отключённой отправкой.

imapsync --host1 mail.old.local --user1 user@buh.example --password1 'xxx' \
         --host2 mail.new.local --user2 user@buh.example --password2 'yyy' \
         --useheader "Message-Id" --automap --skipcrossduplicates --nofoldersizes

Грабли этого переезда. Утилита по умолчанию сверяет письма по заголовкам Message-Id и Received. У трёх ящиков в архиве 2014–2016 годов нашлась пачка писем одной кривой рассылки с повторяющимися идентификаторами — прогон посчитал их дублями и часть не перенёс. Для этих трёх пришлось гонять отдельно, с явным указанием критерия. Заметили только потому, что после каждого прогона сверяли число писем по папкам.

Итог: 91 час вместо 88 по смете — 318 500 ₽ против 308 000 ₽ в счёте, три ночных окна, простой почты — 40 минут на переключении MX. Зимлет переписали не как зимлет, а как отдельную веб-страницу с поиском по номеру договора, которую открывают в соседней вкладке. Бухгалтеры поворчали неделю и привыкли.

Не пытайтесь принять это решение из одной цифры. «У нас старая версия» — не аргумент за переезд, а «сервер работает» — не аргумент против. Аргумент — это четырнадцать строк с проставленными галочками и две сметы рядом.

Порядок, который я бы советовал повторить:

• Снять первые пять параметров командами — это двадцать минут и не требует ничего останавливать.
• Пройти по пунктам 7–11 с людьми, а не с сервером. Спросить каждый отдел, чем они в почте пользуются кроме писем. Отдельно спросить про телефоны.
• Проверить пункт 12 не наличием бэкапа, а датой последнего успешного восстановления. Если такой даты нет — считайте, что бэкапа нет.
• Честно ответить на пункт 14. Он весит больше, чем кажется: любая платформа, которую некому вести, через два года окажется в том же состоянии, что ваша нынешняя.

Отдельно скажу про масштаб, потому что этот вопрос задают. Наш самый крупный переезд с Zimbra — 617 ящиков и 3,8 ТБ store, 28 часов — но это часы самого переноса данных, без зимлетов, бэкапа и разбора конфигурации; весь проект там был кратно больше, просто перенос шёл потоком, а ящики-гиганты уехали в четыре отдельных окна. То есть объём сам по себе не является причиной оставаться. Причиной остаться бывает сложность конфигурации, а не её размер.

Если хотите второе мнение до того, как подписывать чей-то счёт — пришлите мне вывод zmcontrol -v, содержимое /etc/os-release, три цифры du -sh по store, index и db и список из /opt/zimbra/zimlets-deployed/. По этим пяти вещам я за день скажу, в какую сторону у вас клонится решение и почему. Если из них будет видно, что чинить дешевле — так и напишу.

Сколько по времени занимает такой аудит и надо ли останавливать почту?

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

У нас 8.8.15. Может, просто обновиться до десятки и не переезжать?

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

Что дешевле в эксплуатации после переезда — Carbonio, mailcow или что-то из реестра?

По деньгам за лицензии в бесплатных редакциях всё примерно одинаково, то есть ноль. Разница в часах вашего администратора. Carbonio CE ближе всего к Zimbra по логике и по стеку — та же связка Postfix, OpenLDAP и Jetty, привычная админ-панель, меньше переучивания. mailcow проще в обслуживании за счёт контейнеров, но там нет тяжёлого коллаборативного слоя и своего движка расширений. Решения из реестра отечественного ПО имеет смысл рассматривать, когда у вас есть требование по импортозамещению или аттестация — для двадцати восьми рабочих мест без такого требования это лишние деньги и лишняя зависимость.

Как понять, используются ли у нас календари, не спрашивая всех подряд?

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

Мы боимся потерять письма при переезде. Насколько это реальный риск?

Реальный, но управляемый, и управляется он сверкой, а не верой в инструмент. Мы после каждого прогона считаем письма по каждой папке на источнике и на приёмнике и смотрим на расхождения поимённо. На переезде бухгалтерской фирмы такая сверка поймала три ящика, где часть архива 2014–2016 годов не поехала из-за повторяющихся идентификаторов писем в старой рассылке. Итоговая сводка утилиты при этом рапортовала об успехе. Если вам обещают перенос без пофайловой сверки — просите добавить сверку в план работ, она стоит немного, а спасает от разговора через месяц.