Эксплуатация mailcow: бэкапы, обновления, антиспам и безопасность — регламент, по которому мы обслуживаем клиентские серверы

Меня зовут Евгений Семёнов, я техдиректор «АйТи Фреш», и это четвёртая статья нашей mailcow-серии — после обзора, пошаговой установки и миграции через imapsync пришло время поговорить о том, что происходит с сервером дальше — все следующие годы его жизни.

Философия эксплуатации: почтовый сервер — не «поставил и забыл»

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

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

Сколько это стоит в человеко-часах? По нашей статистике, здоровый сервер mailcow требует 2–4 часа работы администратора в месяц: ежемесячное обновление со smoke-тестом, разбор карантина и очередей, ревизия ящиков, реакция на редкие алерты. Всё остальное делает автоматика. Наш собственный прод — 21 домен и больше двухсот ящиков на сервере в дата-центре МТС — живёт ровно по регламенту из этой статьи. За последний год на нём не было ни одного инцидента с потерей писем; были два эпизода деградации доставки (про оба честно расскажу ниже) и десяток мелких срабатываний мониторинга, погашенных за минуты. Это нормальный профиль здоровой системы: скучно, предсказуемо, дёшево.

Бэкапы: встроенный механизм и наши доработки

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

backup_and_restore.sh: что кладёт в архив штатный скрипт

У mailcow есть собственный инструмент резервного копирования — helper-scripts/backup_and_restore.sh в корне репозитория. В режиме backup all он забирает всё, из чего состоит сервер как сущность: том vmail с письмами, дамп MariaDB (домены, ящики, алиасы, настройки), данные Redis, ключи шифрования Dovecot (без них зашифрованные письма из бэкапа не прочитать — самый недооценённый пункт списка) и конфигурацию Rspamd с обученной байесовской статистикой. Куда складывать, задаёт переменная окружения MAILCOW_BACKUP_LOCATION, а флаг --delete-days автоматически чистит архивы старше N дней. Наш типовой cron:

# /etc/cron.d/mailcow-backup — каждую ночь в 02:30
30 2 * * * root MAILCOW_BACKUP_LOCATION=/mnt/backup \
  /opt/mailcow-dockerized/helper-scripts/backup_and_restore.sh backup all --delete-days 3

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

Правило 3-2-1: локальный диск — это ещё не бэкап

Архив на том же VPS защищает от кривого обновления и удалённого ящика, но не от смерти диска, не от компрометации сервера и не от пожара в стойке. Поэтому вторым слоем каждую ночь свежий архив уезжает на независимую площадку — FTP-хранилище или объектное хранилище в другом дата-центре и у другого провайдера. Передача только по шифрованному каналу: внутри архива вся переписка компании открытым текстом. Итог складывается в классическое правило 3-2-1: три копии данных (прод, локальный архив, внешний), два разных носителя, одна копия географически в другом месте. Глубину внешнего хранения держим 30 дней — этого хватает, чтобы поймать даже проблему, которую заметили через две недели.

Восстановление — единственная честная проверка бэкапа

Зелёный статус ночного задания доказывает только то, что скрипт отработал, — не то, что из архива поднимется живой сервер. Поэтому раз в квартал мы разворачиваем клиентский бэкап на тестовом VPS: чистая машина, свежий клон mailcow, restore из последнего архива, проверка входа в пару ящиков и наличия вчерашних писем. Норматив — работающий сервер из бэкапа за 2 часа. Эта цифра — не спортивный интерес: она и есть реальный RTO, который мы можем пообещать клиенту при полной гибели площадки. Дважды квартальная проверка ловила проблемы, которые иначе всплыли бы в день аварии: один раз внешнее хранилище молча резало архивы по квоте, второй — в бэкап не попадали ключи шифрования после переноса каталога установки.

Точечное восстановление: «бухгалтер удалил папку»

Самый частый сценарий восстановления — вовсе не катастрофа, а звонок: «у бухгалтера пропала папка “Поставщики” за прошлый год». Полный restore ради одной папки — стрельба из пушки: он откатит весь сервер, включая сегодняшнюю почту остальных ящиков. Действуем иначе: распаковываем архив во временный каталог, из тома vmail достаём maildir нужного ящика — письма там лежат обычными файлами — и заливаем недостающую папку в живой ящик по IMAP. Пользователь получает свою папку обратно, остальные двести ящиков ничего не замечают. Умение делать такие точечные операции — то, что отличает эксплуатацию от «у нас есть бэкап».

Обновления: update.sh без страха

mailcow выпускает релизы каждые один-два месяца, а критичные исправления — отдельными ревизиями внутри релиза. Свежий пример: в майском релизе 2026-05 «Mooay 2026» ревизия A от 13 мая принесла SOGo 5.12.8 с четырьмя security-фиксами, а ревизия C от 26 мая — nginx 1.30.2 и закрытие CVE-2026-33278 в DNS-резолвере unbound, причём уязвимость закрыли за считаные дни после публикации. Для меня это главный аргумент в разговоре «а не заглохнет ли опенсорс»: проект, который так реагирует на CVE, жив и здоров. Но это же означает обязательство с нашей стороны — обновления надо ставить, иначе смысл быстрых фиксов теряется.

Наш порядок: бэкап → changelog → update.sh → smoke-тест

Обновление клиентского сервера у нас всегда идёт по одной колее:

1. Внеочередной бэкап тем же backup_and_restore.sh — не надеемся на ночной, делаем свежий прямо перед работами.
2. Читаем changelog релиза. Пять минут чтения предупреждают о переименованных параметрах конфига и миграциях схемы БД.
3. Сухой прогон: ./update.sh --check показывает, есть ли новая версия и что изменится, ничего не применяя. Удобно для планирования окна.
4. Само обновление в нерабочее время — вечером или ранним утром: скрипт подтянет изменения репозитория, скачает свежие образы и пересоздаст контейнеры. Почта недоступна считаные минуты, но закладываем окно в час.
5. Smoke-тест по чек-листу: отправка письма наружу, приём снаружи, вход в SOGo, синхронизация ActiveSync на тестовом смартфоне, зелёные статусы всех контейнеров. Только после этого работы считаются законченными.

Если обновление сломалось: отката «одной кнопкой» нет

Здесь развею опасное заблуждение, которое регулярно встречаю: флага --rollback у update.sh не существует. Понадеявшись на него, при неудачном обновлении вы останетесь наедине с нерабочим сервером. Настоящий путь назад — git: перед каждым обновлением скрипт сам создаёт коммит с пометкой «Before update», и откат выглядит так:

cd /opt/mailcow-dockerized
git log --pretty=oneline | grep -i "before update"   # находим точку возврата
docker compose down
git checkout <commit>      # хэш из предыдущей команды
docker compose pull
docker compose up -d

Важная оговорка: git откатывает код и конфигурацию стека, но не базу данных. Если релиз успел прогнать миграции схемы MariaDB, чистого отката кодом уже не получится — именно на этот случай делается бэкап из пункта 1, из которого восстанавливается состояние «до». За годы нам понадобился полный откат один раз, и пре-апдейтный архив превратил потенциальную ночь героизма в сорок минут штатной процедуры.

Почему нельзя копить релизы по полгода

Соблазн «работает — не трогай» понятен, но у mailcow он наказуем. Каждый релиз может нести миграции схемы БД, и разработчики тестируют переход с предыдущей версии, а не прыжок через пять. Чем длиннее разрыв, тем выше шанс, что цепочка миграций споткнётся на середине — и вы получите худший вариант: наполовину обновлённую базу. Плюс всё это время сервер возит известные уязвимости в компонентах, которые смотрят в интернет. Наш стандарт: плановое обновление раз в месяц, security-ревизии — вне очереди в ближайшее удобное окно.

Антиспам Rspamd: тюнинг под реальную компанию

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

Обучение на спаме и хэме: самая недооценённая настройка — люди

Байесовский классификатор Rspamd обучается на примерах, и mailcow устроил это максимально просто: письмо, перемещённое пользователем в папку Junk, автоматически учит фильтр «это спам»; вытащенное из Junk обратно — «это нормальное письмо». Никаких консолей. Поэтому первое, что мы делаем после внедрения, — не крутим конфиги, а рассылаем сотрудникам инструкцию на один абзац: спам не удаляйте, а перетаскивайте в «Спам»; ошибочно попавшее туда — вытаскивайте во «Входящие». Через месяц такой дисциплины фильтр знает специфику именно вашей переписки лучше любых универсальных правил. Это буквально важнее всех остальных настроек этого раздела.

Белые и чёрные списки — через панель, а не конфиги

Вторая по частоте операция — исключения. У каждого клиента есть контрагент с кривым почтовым сервером, чьи письма вечно пахнут спамом для любого фильтра. В mailcow белый и чёрный списки ведутся прямо в веб-панели на двух уровнях: администратор домена задаёт правила для всей компании, пользователь — для своего ящика. Мы заводим доменный whitelist ключевых контрагентов ещё при сдаче сервера, а пользователям показываем, где добавить своё. Это снимает большую часть будущих тикетов «почему письмо от Иван Иваныча в спаме».

Русскоязычная специфика и цена greylisting

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

Карантин: пусть решает пользователь, а не фильтр

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

ClamAV: честный разговор про 1,5 гигабайта

Антивирусный слой в стеке — ClamAV, и у него есть цена: контейнер держит в памяти базы сигнатур и стабильно ест 1–1,5 ГБ RAM. Ловит он в основном массовые угрозы — заражённые вложения из старых ботнет-рассылок; таргетированный документ он, будем честны, скорее пропустит. Поэтому на серверах с 6 ГБ памяти мы осознанно отключаем его параметром SKIP_CLAMD=y в mailcow.conf, компенсируя жёсткими правилами по вложениям и антивирусом на рабочих станциях. На машинах от 8 ГБ оставляем: лишний слой обороны за копейки памяти, которой и так хватает. Это решение всегда фиксируем письменно в паспорте сервера — «антивирус отключён тогда-то по такой-то причине», чтобы через год оно не стало сюрпризом.

Безопасность: чем закрыт сервер по нашему стандарту

Почтовый сервер — публичная услуга по определению: его порты обязаны смотреть в интернет, спрятать его за VPN нельзя. Значит, брутфорс и сканеры — не риск, а фон, который начинается в первые часы жизни машины. Вот наш обязательный минимум.

Принудительная 2FA для админ-панели

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

netfilter: автобан и грабля с забаненным офисом

Контейнер netfilter в составе mailcow автоматически банит адреса, перебирающие пароли по SMTP, IMAP и панели, — аналог fail2ban, работающий из коробки. Штука отличная, но с ней связана наша любимая грабля. Классика жанра: сотрудник сменил пароль ящика, а в его телефоне остался старый — и телефон молча долбит IMAP неверным паролем каждые тридцать секунд. Несколько попыток — и netfilter банит IP. Проблема в том, что из офиса все выходят с одного внешнего адреса: банится не телефон, а вся компания разом, и у двадцати человек «отвалилась почта». Лечение штатное: офисные подсети клиента вносятся в whitelist netfilter в админке — свои адреса не банятся никогда, а брутфорс изнутри офиса нам всё равно виден по логам. Делаем это превентивно при сдаче каждого сервера.

TLS-гигиена и инцидент с истёкшим сертификатом

По протоколам стандарт скучный: только TLS 1.2 и выше, устаревшие SSL/TLS-версии выключены, сертификаты Let's Encrypt продлеваются встроенным ACME-контейнером без участия человека. Но расскажу инцидент, который случился на реальном сервере. На машине, где параллельно с почтой жил сторонний сервис, коллега когда-то настроил продление его сертификата через certbot в standalone-режиме — а этот режим поднимает собственный веб-сервер на 80-м порту. Порт был занят nginx самого mailcow, certbot тихо падал, а вслед за конфликтом перестало отрабатывать и штатное продление. Итог обнаружили пользователи: «почта ругается на сертификат». Сертификат к тому моменту был просрочен. Вывод мы зашили в стандарт: у 80-го порта на почтовом сервере один владелец — nginx mailcow, все прочие сертификатные нужды решаются через webroot или DNS-проверку, а срок действия сертификата мониторится снаружи независимо от механизма продления — об этом в следующем разделе.

Четыре настройки против «взлома изнутри»

Остальной пакет защищает не от хакеров снаружи, а от последствий компрометации одного ящика:

• Ограничение протоколов per-mailbox (функция 2026 года): у сервисных и «архивных» ящиков отключаем ActiveSync и DAV — меньше поверхность атаки у учёток, которым мобильная синхронизация не нужна.
• sender_acl: ящик может отправлять только от своих адресов — взломанная учётка курьера не сможет писать «от директора» внутри домена.
• Запрет открытого relay — сервер отправляет только за аутентифицированных пользователей; проверяем это внешним тестом при каждой сдаче.
• Rate-limit на ящик: потолок исходящих в час. Именно он превращает взломанный ящик из катастрофы в неприятность — спам-рассылка упирается в лимит на первых десятках писем, а не на десятой тысяче, когда IP уже в блэклистах.

Мониторинг и типовые инциденты

Мониторинг — третий кит, который делает первые два честными. Наш обязательный набор метрик для каждого почтового сервера:

• Место на диске — том vmail растёт незаметно и постоянно: люди шлют друг другу сканы и презентации и ничего не удаляют. Пороги 80 и 90%.
• Очередь Postfix — самый чувствительный индикатор: растущая очередь означает либо проблемы доставки, либо (хуже) рассылку с взломанного ящика.
• Статусы контейнеров — все ~18 должны быть живы; упавший acme или netfilter снаружи не виден неделями, если его не проверять.
• Срок сертификата — независимо от ACME-автоматики, урок из инцидента выше: алерт за 14 дней до истечения.
• Присутствие IP в блэклистах — скрипт по cron опрашивает Spamhaus и коллег; попадание в список надо узнавать от мониторинга, а не от клиента, у которого «перестали доходить письма».
• Успешность ночного бэкапа — и факт завершения, и размер архива: усохший вдвое архив подозрительнее несделанного.

Три инцидента из практики

Первый: диск съели логи. На сервере одного клиента место закончилось не из-за писем, а из-за журналов: после смены провайдерского резолвера контейнерные логи распухали на гигабайты в сутки от повторяющихся DNS-ошибок. MariaDB, оставшись без места, остановилась — встала и почта. Алерт на 80% диска дал нам сутки форы: ротацию логов ужесточили, причину шума убрали, пользователи ничего не заметили. С тех пор лимит на размер контейнерных логов — обязательная строка паспорта сервера.

Второй: «в блэклистах нас нет, а Mail.ru режет». Коварный случай: все публичные списки чисты, SPF/DKIM/DMARC зелёные, а письма клиента в адрес контрагентов на Mail.ru стали уходить в спам и получать временные отказы. Причина — внутренняя репутационная система провайдера: после пары жалоб пользователей «в спам» на массовую, но легитимную рассылку счетов домен тихо придушили лимитами. Внешней диагностики у такого нет — только постмастер-кабинет провайдера и переписка с поддержкой. Решали неделю: разобрали жалобы, вынесли рассылку счетов на отдельный субдомен с собственной репутацией, снизили темп отправки. Урок: доставляемость — это не только DNS-записи, и мониторить надо в том числе ответы принимающих серверов в логах Postfix.

Третий: взломанный ящик — пойман за 20 минут. Пароль сотрудника утёк с каким-то сторонним сервисом, и ночью с его ящика началась рассылка. Дальше сработала связка из этой статьи: rate-limit прижал темп, а алерт на рост очереди Postfix поднял дежурного через двадцать минут после старта. Пароль сброшен, сессии убиты, очередь вычищена, IP в блэклисты попасть не успел. Без мониторинга эту рассылку заметили бы утром — по заблокированному всеми провайдерами адресу.

Telegram-алерты как минимальный SLA-инструмент

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

Регламент одним листом

Всё сказанное выше сворачивается в одну таблицу. Именно она висит в паспорте каждого обслуживаемого нами почтового сервера:

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

Почтовый сервер, который обслуживают по регламенту, — скучная и дешёвая в содержании система: 2–4 часа в месяц против авралов, потерянной переписки и «недели без почты». Собственно, за эту скуку клиенты нам и платят. Если хотите такой же предсказуемости для своей почты — напишите мне в Telegram @ITfresh_Boss или позвоните +7 903 729-62-41: возьмём на обслуживание существующий mailcow или развернём новый по регламентам из этой серии статей.