Как я проверяю переход с Zimbra на Carbonio до смены MX

Переход с Zimbra на Carbonio я начинаю с проверки способа переноса: письма, календари, контакты и права доступа требуют отдельных проверок. Коммерческая лицензия нужна не для любого переезда. Ниже покажу, как выбрать процедуру для своей редакции, проверить пилот и разрешить смену MX только после приемки.

Что я включаю в опись перед переносом

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

Я разделяю наличие функции в Carbonio и возможность перенести ее выбранным инструментом. Сходство с Zimbra не доказывает ни полной совместимости хранилищ, ни их полной несовместимости. Поэтому не переношу рабочую систему поверх старой и не подменяю процедуру миграции копированием каталога. В официальном руководстве Carbonio CE отдельно описаны подготовка доменов и учетных записей, перенос писем через IMAP, импорт календарей из ICS и контактов из CSV. Для задач, заметок и дополнительных модулей нужен отдельный подтвержденный способ: обещать их перенос заодно нельзя.

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

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

• Объект: тип, владелец, объем и доступ других сотрудников.
• Перенос: инструмент, формат выгрузки и известные ограничения.
• Приемка: проверяемое действие, ответственный и результат.
• Исключения: согласованный архив или отдельная ручная работа.

Нужна ли лицензия и что умеет инструмент

Тезис «из Zimbra можно переехать только в платный Carbonio» неверен. В документации есть самостоятельная процедура Migration to Carbonio CE. У коммерческих модулей и сценариев восстановления собственные требования к лицензии; переносить их на все способы миграции нельзя. Сначала я выбираю редакцию по нужным рабочим функциям, затем способ доставки данных. Если бизнесу подходит CE, лицензия на коммерческий продукт не становится обязательной только потому, что исходный сервер называется Zimbra.

Для почтового содержимого официальный маршрут CE рекомендует imapsync. Я рассматриваю его именно как перенос писем и почтовых папок: календари и адресные книги проверяю по отдельным выгрузкам и импортам. Ни права делегирования, ни доменные политики не считаю перенесенными лишь потому, что IMAP завершился успешно. Учетные записи и адреса назначения подготавливаю до загрузки содержимого. Если в проекте выбран другой инструмент, в описи должны измениться и способ переноса, и критерий проверки — название утилиты само по себе ничего не гарантирует.

У Z2C есть важное ограничение: описанная ниже реализация не рассчитана на миграцию между установками из нескольких серверов. Оно подтверждается README конкретного репозитория alsyundawy/Z2C: описанная реализация ограничена одним сервером. Это сторонний проект, а не универсальная штатная команда Carbonio. Перед применением я фиксирую его ревизию, читаю ограничения и проверяю выгрузку на стенде. Объявлять бесплатные скрипты опасными только из-за цены бессмысленно. Стоимость лицензии не заменяет чтение журнала ошибок.

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

Как я принимаю пилот: письма, встречи и клиенты

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

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

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

Синхронизацию проверяю в конкретной связке: редакция Carbonio, версия клиента, способ подключения и ожидаемое действие. Подключение Outlook или Thunderbird по IMAP подтверждает работу почты, но не синхронизацию календаря и контактов. ActiveSync относится к лицензируемым возможностям Carbonio; для CE нельзя обещать его наличие по умолчанию. В официальном сравнении редакций расширенная синхронизация сторонних клиентов вынесена отдельно. Если сотрудникам нужен именно этот сценарий, проверяю доступный модуль и условия подписки до выбора редакции.

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

Условный разбор: 25 ящиков «Формы дерева»

Покажу порядок на условном производстве мебели «Форма дерева» из Подмосковья, где 25 рабочих мест. Это расчетный сценарий, а не отчет о реальном заказчике. Для примера беру 25 ящиков и 120 ГБ почтовых данных; пилот — три ящика объемом 6, 12 и 18 ГБ, всего 36 ГБ. Добавляю общий календарь производства и папку с чертежами, которой пользуются несколько сотрудников. Эти числа задают нагрузку стенда, а не обещают срок переноса любой компании такого размера.

В паспорте такого стенда можно указать исходную Zimbra OSE 8.8.15 и целевую Carbonio CE 26.9.0. Существование релизов подтверждается официальными страницами; совместимость конкретной выгрузки этим не доказана, ее устанавливает пилот. В рабочем проекте я дописываю точный уровень обновлений, ОС и ревизию инструмента. В примере использую раздельные маршруты: почтовые сообщения через IMAP, календарь через ICS, контакты через CSV. До копирования составляю соответствие владельцев и получателей доступа, чтобы не принять чужую папку за отдельный экземпляр данных.

Сценарий проверки конфигурации задаю явно: папка принадлежит конструктору, сотрудник производства может ее читать, а изменять доступ может владелец. Для календаря проверяю отдельно просмотр и редактирование. Предположим, письма уже доступны, но общий календарь открывается только у владельца. Это незакрытая приемка прав, а не доказательство, что Carbonio вообще не умеет общие календари. Я восстанавливаю согласованный доступ и повторяю проверку под обеими учетными записями. Изменение должно пройти весь сценарий, включая отмену встречи.

Для учебного плана отвожу первый рабочий день на опись и выгрузки, второй — на пилот, третий — на исправления и повторную приемку. Переключение ставлю отдельным согласованным окном после этих этапов; его длительность определяю по замеру стенда. Если проверка доступа провалилась, окно переношу. Итог этого разбора — опись всех 25 ящиков, протокол трех пилотных учетных записей и проверенные роли общего ресурса. Успешные контрольные действия дают основание продолжать; красивая дата в календаре такого основания не дает.

Что проверить в доступе, подписях и доставке

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

Не смешиваю вход сотрудника и аутентификацию сервера при отправке через внешний почтовый шлюз. Политика SASL исходящего SMTP-клиента управляет его аутентификацией на следующем сервере; включить ею вход сотрудников в веб-почту нельзя. В документации Postfix эти роли разделены семействами smtp_sasl_* и smtpd_sasl_*. При проблеме входа проверяю нужный сервис, учетную запись и журнал соответствующей попытки. Ослаблять ограничения аутентификации ради устранения любой ошибки отправки нельзя; сначала нужно установить причину и проверить защищенное соединение.

Пользовательскую подпись и доменный disclaimer принимаю отдельно. Первая относится к настройкам отправителя, второй добавляется сервером по заданной политике. Наличие подписи не означает, что обязательная приписка включена, и наоборот. В панели Carbonio CE для disclaimer есть глобальное включение и доменный текст; применение изменений зависит от ОС и версии, поэтому рецепта «одна команда для всех» здесь нет. Я отправляю контрольное письмо снаружи и внутри, в простом тексте и HTML, и смотрю фактически полученный результат. Само наличие приписки не доказывает юридическую значимость письма.

SPF проверяет право отправляющего узла использовать домен в SMTP, а не принадлежность процесса системному пользователю Zimbra. Сверяю DNS и реальный маршрут исходящего письма: при отправке через шлюз получатель видит именно шлюз. Отдельно проверяю результат DKIM и применение DMARC по контрольной доставке, не обещая автоматического попадания во входящие. На время сосуществования серверов учитываю оба разрешенных маршрута. Для проверки почтовой аутентификации есть отдельный разбор SPF, DKIM и DMARC.

Когда менять MX и как сохранить возможность возврата

TTL снижаю заранее с учетом прежнего значения. Правило «ровно за 24 часа» не универсально: уже закешированный ответ живет по старому TTL, новое значение его задним числом не сокращает. Если меняется имя почтового узла или его адрес, учитываю также связанные адресные записи. В плане фиксирую время изменения и результат проверки DNS. Низкий TTL помогает управлять обновлением ответов, но не обнуляет очереди отправителей и не доказывает, что старый сервер больше не получает письма.

Перед переключением выполняю согласованный финальный перенос изменений. На переходный период определяю, где пользователи работают, кто принимает новые письма и как сообщения, попавшие на старую сторону, попадут на новую. Старый прием не выключаю только потому, что новый MX уже виден с моего компьютера. После смены маршрута проверяю входящую почту, исходящую доставку и состояние очередей на обеих сторонах. Последнюю сверку провожу по данным и журналам, пока все обнаруженные расхождения не получили объяснение.

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

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

• Пилот принят: письма, контакты, встречи, права и выбранные клиенты проверены.
• DNS подготовлен: прежний TTL учтен, оба маршрута доставки описаны.
• Финальный перенос изменений выполнен, расхождения разобраны.
• Восстановление проверено, условия возврата и сохранения новых данных записаны.

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