Zimbra 9 → 10.1: что я проверяю до остановки почты

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

На какую версию обновлять Zimbra 9 и какой путь выбрать

Я начинаю с паспорта установки: полная версия и патч, редакция, поставщик сборки, операционная система, роли узлов, действующая лицензия. В плане обновления корпоративной почты это исходные данные, а не формальность. Запись «у нас девятка» не показывает ни доступный маршрут, ни состав хранилищ. До выбора дистрибутива я выясняю, работает ли обычная Network Edition, сторонняя сборка OSE или установка с дополнительными модулями. Одинаковая цифра на странице входа ещё не означает одинаковую процедуру перехода.

На дату проверки, 25 октября 2026 года, я рассматриваю ветку 10.1 с актуальными исправлениями для выбранной редакции. Продлённая поддержка Zimbra 9 завершилась 30 июня 2025 года. Для 10.0 общая поддержка закончилась 30 июня 2025 года, этап Technical Guidance — 31 декабря 2025 года. Это разные этапы жизненного цикла. Наличие старой версии в инструкции или списке совместимости диагностического инструмента не возвращает ей поддержку. Само окончание поддержки не доказывает взлом, но оставляет сервер без обычного выпуска новых исправлений.

В базе есть официальные руководства перехода с 8.8.15 и 9 на Zimbra 10. Я выбираю документ под число узлов и наличие NG-модулей, затем сверяю требования с примечаниями к целевому выпуску. Например, руководство миграции NG требует исходную 9.0.0 с последним патчем. Это условие конкретного маршрута, а не повод придумывать обязательные промежуточные версии для любой установки. Если нужно менять ещё и ОС, я отдельно проверяю допустимую последовательность. Два обновления в одном окне усложняют поиск причины сбоя.

Для Network Edition 10.1 заранее нужен новый лицензионный ключ и работающий License Daemon Service, LDS. Старый лицензионный файл не заменяет новую активацию. На стенде я проверяю доступность лицензируемых функций, а в плане указываю способ активации. Для сторонней сборки OSE отдельно выясняю её происхождение, доступность исправлений и условия целевой сборки. Установщик для обновления OSE внутри старой ветки не доказывает возможность перехода на коммерческую редакцию 10.1. Бесплатный архив иногда обходится дорого: особенно когда его назначение выясняют уже после остановки почты. Лицензия, которую собираются получить после работ, действует пока только в протоколе совещания.

Какие Zimlets, интеграции и NG-модули проверить

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

Zimbra 10 сохраняет Classic и Modern Web App. Причина несовместимости не сводится к лозунгу «в десятке всё переписали»: Zimlet для Classic нельзя автоматически перенести в Modern. Пользовательские расширения проверяю до повторного включения; после обновления они могут оставаться отключёнными. Для проверки беру тот веб-клиент, которым пользуются сотрудники, и записываю его в протокол. Работает в соседнем интерфейсе — полезное наблюдение, но не выполненное требование. Совместимость по похожему номеру версии существует примерно так же, как запасной парашют на фотографии.

NG-модули я выделяю отдельно от Zimlets. В руководстве миграции Mobile заменяется Zimbra Mobile Sync; параметры мобильных устройств и общих папок требуют отдельной проверки. Для HSM, резервирования, делегирования и файлов заранее определяю, что экспортировать и как принимать результат импорта. Не переношу список команд из чужой инструкции целиком: состав действий зависит от используемых функций. Особое внимание отдаю данным, которые обычный почтовый клиент не показывает. Иначе после запуска сотрудник увидит письма, а отсутствие нужных полномочий обнаружит при первой попытке выполнить работу.

В условном «Точном тексте» для разбора принимаю три дополнительные интеграции: отправку из CRM, запись встреч и формирование отчёта. Две проходят сценарии проверки, третью в примере заранее согласуем отключить до доработки. Я не выдаю выдуманный предел совместимости вроде версии плагина за подтверждение производителя. Настройки фиксирую вместе с местом хранения: локальная конфигурация находится в /opt/zimbra/conf/localconfig.xml, а zmlocalconfig — утилита работы с ней. Защищённую копию держу отдельно; пароли из файла в рабочий чек-лист не вставляю. Копирование всех старых файлов поверх новой установки тоже не считается переносом настроек.

Какой бэкап нужен и что восстановить до обновления

Я сначала выбираю способ восстановления исходной системы, а уже потом задачу копирования. Штатный zmbackup относится к Network Edition; одноимённый сторонний проект не делает эту команду универсальной для OSE. Для установки с NG Backup проверяю её собственную процедуру, для другой редакции — поддерживаемый способ полного восстановления именно этой сборки. Нужны понятные зависимости между копиями, доступ к хранилищу и сохранённые средства восстановления. Успешный статус задания я принимаю как начало проверки. Архив, который некому и нечем открыть, — довольно убедительная имитация страховки.

У Zimbra Store есть база MariaDB, отдельное хранилище тел писем и вложений, а также поисковые индексы. Поэтому дамп базы не равен резервной копии всей почты; PostgreSQL не является штатной базой почтового хранилища Zimbra. Я проверяю охват каталога учётных записей, всех задействованных томов, конфигурации и сертификатов. Индексы оцениваю с учётом выбранной процедуры: возможность перестроить поиск не возвращает потерянные тела писем. Для файловой копии добиваюсь согласованного состояния по инструкции своей установки. Простое копирование меняющихся файлов не принимаю за доказательство восстанавливаемости.

Есть отдельная ловушка при уходе с NG: формат NG-бэкапов отличается от Daffodil. Штатный механизм Backup & Restore новой системы не восстанавливает их напрямую. Старый архив я сохраняю вместе с проверенным способом аварийного восстановления исходной версии; после перехода создаю и испытываю новую копию. Экспорт конфигурации резервирования не подменяет архив писем. На стенде проверяю оба назначения отдельно: могу ли вернуться к старой системе и могу ли восстановить данные новой. Это разные проверки, даже если каталог хранения называется одинаково.

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

Как рассчитать окно работ и не потерять письма при откате

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

Для расчётного примера «Точного текста» принимаю 15 ящиков и 90 ГБ данных. Пусть репетиция перехода с Zimbra 9.0.0 на выбранный выпуск 10.1 вместе с приёмкой заняла 110 минут, восстановление исходной копии — 80 минут, запас — 50 минут. Тогда окно составляет 240 минут, а решение нужно принять не позже 110-й минуты от начала. После этой точки остаются 130 минут: на возврат и резерв. Это условные результаты учебного прогона, а не обещание уложить любую компанию в четыре часа. В реальном плане я подставляю собственные замеры.

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

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

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

Что проверить после установки до возврата доступа

Я заранее составляю лист приёмки с исходными результатами и прохожу его после перехода. Проверяю вход обычного сотрудника, отправку наружу и входящее письмо с ответом, открытие вложений, перемещение между папками и поиск старой переписки. IMAP и SMTP проверяю в используемых программах; POP3 включаю в тест только при его реальном использовании. Для каждого действия сохраняю время и результат, чтобы отделить задержку доставки от ошибки клиента. Открытая страница входа подтверждает доступность страницы. Даже если логотип на ней выглядит совершенно здоровым.

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

При сбое смотрю журналы соответствующего компонента и сравниваю ошибку с исходным состоянием. Почтовые приложения Zimbra работают на Java и Jetty; случайное обновление PHP не является штатным способом ремонта веб-клиента. Не меняю окружение наугад во время приёмки. Также не объявляю старые 10.0.18, 10.1.13 или 10.1.19 достаточной конечной целью лишь потому, что они когда-то закрывали конкретные проблемы. Для выбора выпуска использую текущий каталог релизов и его ограничения. Исправление одной уязвимости не означает, что сервер получил все последующие исправления.

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

Нужен ли Carbonio после Zimbra 10 и когда закрывать работы

Carbonio я рассматриваю как отдельную платформу и отдельный проект миграции. Утверждение «Zimbra 10 — последний крупный релиз, дальше обязательно Carbonio» не даёт основания для плана. Официальная процедура Carbonio CE описывает импорт подготовленных данных из исходной системы и не устанавливает общего требования сначала обновить её до Zimbra 10. Выбор зависит от доступного экспорта и состава данных. Если задача — сохранить существующую среду Zimbra, я завершаю подготовленный переход на 10.1. Если задача — сменить платформу, отдельно проверяю маршрут миграции, не добавляя промежуточный апгрейд по привычке.

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

В учебном протоколе «Точного текста» итог выглядит так: 15 из 15 ящиков прошли согласованные проверки на стенде, две интеграции приняты, одна отключена по заранее принятому решению. Исходная система остаётся на Zimbra 9.0.0 до рабочего окна; целевая копия — на согласованном выпуске 10.1. Настройки локальной конфигурации и права общих папок сверены, маршрут восстановления уложился в расчётные 80 минут. Такой протокол разрешает переход к рабочему этапу, но не изображает уже выполненный переезд клиента. В настоящем проекте я закрываю акт только после той же проверки на рабочей системе. Ни удачная репетиция, ни наличие бэкапа не превращаются в безусловную гарантию сохранности.

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