Эксплуатация Carbonio CE без платного бэкапа: наш регламент резервных копий, обновлений и защиты почтового сервера

Чего нет в Community Edition и что это значит на практике

Меня зовут Евгений Семёнов, я технический директор ITfresh. Мы сопровождаем собственные почтовые системы — 21 домен и больше двухсот ящиков на своём железе в дата-центре МТС — и почтовые серверы клиентов в рамках IT-аутсорсинга компаний до 50 рабочих мест в Москве. В обзоре Carbonio CE и статье про установку я обещал самый честный разговор серии — про эксплуатацию. Держу слово, потому что главный минус Community Edition вылезает не в день установки, а в день первой аварии.

Минус этот называется модуль Backup — он есть только в платном Carbonio Pro. Вместе с ним в Pro уехали три вещи, которые в 2026 году хочется считать гигиеническим минимумом:

• Realtime-бэкап — каждая операция с ящиком пишется в журнал резервирования почти мгновенно, окно потери данных измеряется секундами;
• восстановление одного письма — «бухгалтер удалил акт сверки в четверг» решается парой кликов в консоли, без раскатывания всего сервера;
• HSM — перенос старой почты на дешёвые медленные диски, что для ящиков-архивов по 30–50 ГБ экономит заметные деньги.

Плюс в Pro остаётся кластеризация — но для наших типовых 20–50 рабочих мест она и не нужна, одиночный сервер с нормальным резервированием переживает всё, кроме пожара в стойке. А вот бэкап нужен всем и всегда. Хорошая новость: для этого масштаба задача полностью решается штатными средствами Linux и утилитами самого Carbonio. Плохая новость, выстраданная на чужих авариях: схему резервирования надо проектировать до первого инцидента, а не после. Восстанавливать почтовый сервер, у которого «бэкапом» был снапшот полугодовой давности, — занятие на выходные и седые волосы.

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

Трёхслойная схема бэкапа ITfresh

Один способ резервирования — это не резервирование, а лотерея. Мы строим три независимых слоя, каждый закрывает свой класс аварий и имеет свою скорость восстановления.

Слой 1. Снапшоты и бэкапы всей виртуальной машины

Carbonio у нас всегда живёт в виртуалке, и первый слой — ночной бэкап всей VM средствами гипервизора: vzdump в Proxmox или задание резервного копирования на VMware. Это страховка от катастрофы: умер диск, развалилась файловая система, обновление превратило сервер в тыкву — откатываемся целиком.

Важный нюанс, который пропускают в девяти инструкциях из десяти: mailboxd — это Java-процесс с горячими Lucene-индексами, рядом крутятся MariaDB и OpenLDAP. Снапшот «на живую» с ненулевой вероятностью даст копию, где база и индексы неконсистентны. Поэтому либо в гостевой системе работает агент с fsfreeze (qemu-guest-agent в Proxmox, VMware Tools с quiesce), либо — параноидальный вариант для самого ценного сервера — короткая остановка сервисов на время создания снапшота: снапшот делается секунды, дельта копируется уже на работающем сервере. Три минуты недоступности почты в 03:00 никто не заметит, а консистентная копия дорогого стоит.

Слой 2. rsync хранилища плюс дампы баз — ядро схемы

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

• хранилище писем /opt/zextras/store — инкрементальный rsync с жёсткими ссылками, поэтому семь «полных» суточных копий занимают чуть больше одной;
• дамп MariaDB — метаданные ящиков, папки, теги, флаги прочтения;
• дамп LDAP через slapcat — учётные записи, домены, классы обслуживания, пароли;
• выгрузку конфигурации — zmprov gacf и настройки сервера, чтобы после аварии не вспоминать, какие лимиты и политики были выставлены.

# /opt/scripts/carbonio-backup.sh — слой 2: файлы + дампы (запуск из cron в 02:30)
#!/bin/bash
set -euo pipefail
TS=$(date +%F)
DST="/backup/carbonio/daily/$TS"
mkdir -p "$DST"

# 1. Хранилище писем: инкрементально, hardlink-ротация
rsync -aH --delete --link-dest=/backup/carbonio/daily/latest/store \
  /opt/zextras/store/ "$DST/store/"

# 2. Метаданные ящиков: MariaDB (пароль берём из localconfig)
PW=$(su - zextras -c 'zmlocalconfig -s -m nokey mysql_root_password')
su - zextras -c "mysqldump -u root -p$PW --single-transaction --all-databases" \
  | gzip > "$DST/mariadb.sql.gz"

# 3. Каталог LDAP: учётки, домены, COS
/opt/zextras/common/sbin/slapcat -F /opt/zextras/data/ldap/config -b "" \
  | gzip > "$DST/ldap.ldif.gz"

# 4. Конфигурация: глобальная и серверная
su - zextras -c 'zmprov gacf' > "$DST/globalconfig.txt"
su - zextras -c "zmprov gs $(hostname -f)" > "$DST/serverconfig.txt"

ln -sfn "$DST" /backup/carbonio/daily/latest

# Ротация 7/4/6: 7 суточных; по воскресеньям копия в weekly (храним 4),
# первого числа — в monthly (храним 6)
find /backup/carbonio/daily/ -maxdepth 1 -type d -mtime +7 -exec rm -rf {} +
[ "$(date +%u)" = 7 ] && cp -al "$DST" "/backup/carbonio/weekly/$TS"
[ "$(date +%d)" = 01 ] && cp -al "$DST" "/backup/carbonio/monthly/$TS"
find /backup/carbonio/weekly/  -maxdepth 1 -type d -mtime +28  -exec rm -rf {} +
find /backup/carbonio/monthly/ -maxdepth 1 -type d -mtime +190 -exec rm -rf {} +

Ротация 7/4/6 — семь суточных, четыре недельных, шесть месячных копий — закрывает и «вчера сломалось», и «в марте удалили папку, заметили в июле». Точные пути к slapcat и сокетам проверьте на своей инсталляции: Carbonio живёт в /opt/zextras, но между релизами детали меняются, эталон — документация docs.zextras.com.

Слой 3. Пообъектные выгрузки критичных ящиков

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

su - zextras -c 'zmmailbox -z -m buh@client.ru \
  getRestURL "//?fmt=tgz"' > /backup/mailboxes/buh-$(date +%F).tgz

Внутри tgz — все письма ящика в формате, который открывается любым архиватором и заливается обратно тем же zmmailbox postRestURL. Это наш ответ на отсутствие «восстановления одного письма» из Pro: не так элегантно, но работает.

Правило 3-2-1 и внешнее хранилище

Все три слоя обязаны соблюдать правило 3-2-1: три копии данных, два разных носителя, одна копия вне площадки. Мы держим выделенное FTP/SFTP-хранилище на отдельном сервере в другом дата-центре, куда слой 2 доезжает сразу после локального прогона. Урок из практики: когда-то у нас бэкапы полгода складывались на тот же RAID, что и продакшен, — при деградации массива «резервная копия» деградировала вместе с ним. С тех пор внешняя площадка — пункт без обсуждений, а хранилище бэкапов смонтировано так, что с почтового сервера его нельзя перезаписать задним числом: доехавшие копии защищены и от шифровальщика.

Учения по восстановлению: бэкап, который не проверяли, — это гипотеза

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

Сценарий 1: «удалили письмо». Самый частый случай. Разворачиваем tgz нужного ящика из слоя 3, находим письмо по дате и теме, заливаем его в подпапку восстановленного через postRestURL или просто пересылаем пользователю. Реальное время — 15–30 минут, из них половина уходит на уточнение у пользователя, что именно он удалил.

Сценарий 2: «умерла база или индекс». MariaDB не стартует после сбоя питания или рассыпался поисковый индекс. Порядок: остановить сервисы, восстановить дамп MariaDB из слоя 2, при необходимости LDAP из ldif (slapadd), затем переиндексация проблемных ящиков — zmprov rim ящик start. Реальное время — 1–2 часа на сервер с полусотней ящиков, дольше всего молотит переиндексация больших архивов.

Сценарий 3: «сгорел сервер». Гипервизор жив — разворачиваем ночную копию VM из слоя 1 и накатываем поверх дельту писем за день свежим rsync из слоя 2: письма, пришедшие после снапшота, лежат в store внешнего хранилища. Гипервизор мёртв — поднимаем VM на резервной площадке. Реальное время — 2–4 часа до рабочей почты, и до 6–8, если пришлось перевозить площадку и ждать обновления DNS.

Обновления Carbonio без поломки прода

Zextras выпускает несколько релизов в год с нумерацией «год.месяц»: 25.9, 25.12, 26.3, на момент написания актуален 26.6.0. Релизы приносят не только заплатки, но и ломающие изменения — свежий пример из прошлой статьи: переход управления сервисами на systemd, после которого привычный zmcontrol исчез, и все старые скрипты мониторинга и рестарта молча перестали работать. Поэтому «обновляйтесь сразу» и «обновляйтесь автоматически» — оба совета вредные. Наш порядок такой:

1. Снапшот VM непосредственно перед обновлением — это точка отката, независимая от ночного бэкапа.
2. Читаем release notes на docs.zextras.com для целевой версии. Ищем слова про смену схемы БД, миграции конфигурации, снятые с поддержки компоненты. Если релиз перескакивает через версию — проверяем, поддерживается ли прямой апгрейд или надо идти по цепочке.
3. Обновляем в окно — вечер пятницы или раннее утро: apt update && apt upgrade по carbonio-пакетам, затем перезапуск сервисов и pending-setup, если релиз его требует.
4. Смоук-тест — пять минут проверок, прежде чем написать «готово»:

# Смоук-тест после обновления (~5 минут)
systemctl list-units 'carbonio-*' --state=failed   # должно быть пусто
su - zextras -c 'zmprov gas'                       # LDAP отвечает, сервер на месте
postqueue -p | tail -n1                            # очередь не копится
curl -sk -o /dev/null -w '%{http_code}\n' https://mail.client.ru/   # 200
openssl s_client -connect mail.client.ru:993 -brief