Как я принимаю Carbonio после миграции с Zimbra

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

Что я требую перед окончательной приёмкой Carbonio

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

Сначала фиксирую установленную редакцию, фактическую версию и способ переноса. Carbonio CE и коммерческий Carbonio нельзя смешивать в одной инструкции. В официальном руководстве CE описан импорт почты через IMAP, календарей из ICS и контактов из CSV. Значит, утверждение «для любого переноса обязательно нужна коммерческая лицензия» слишком широкое. Но наличие инструкции для CE не даёт ей функций коммерческих модулей. Я сверяю возможности выбранного инструмента, а лицензирование конкретного модуля проверяю отдельно.

Подготовку исходной системы и пилот до переключения я уже разбираю в статье про проверки перехода с Zimbra. Здесь другая точка контроля: сотрудники работают в Carbonio, появляются новые письма, а проект ещё нельзя закрыть. Я составляю список того, что обещали перенести, что исключили по договорённости и что требует отдельной настройки. Старую систему сохраняю как источник для сверки с ограниченным доступом, а не оставляю сотрудникам две равноправные почты.

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

Как подтвердить доставку и доступность старых писем

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

В полученном снаружи письме я изучаю полные заголовки и результаты проверки подлинности. SPF, DKIM и DMARC связаны с доменом и настройками отправки; копирование ящиков само по себе их не настраивает. Ошибка способна привести к спаму или отказу, но результат зависит от политики получателя. Успешная аутентификация тоже не обещает попадания во «Входящие». Подробную проверку DNS при смене почты провожу отдельно, здесь сохраняю итог конкретного тестового письма.

Если сообщение задержалось, я сопоставляю отправку с журналами MTA и состоянием очереди. В документации Carbonio для восстановления пути сообщения по логам указан zmmsgtrace. Начинаю со справки на сервере под служебной учётной записью zextras, на узле с доступными журналами доставки:

/opt/zextras/libexec/zmmsgtrace --help

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

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

• Внутренняя отправка, внешний адресат и ответ обратно
• Общий адрес, псевдонимы и нужные списки рассылки
• Заголовки получателя и сопоставление с журналом доставки
• Старые письма, вложения, черновики и общие папки
• Объяснение каждого расхождения в согласованной выборке

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

Если старое письмо не находится, я сначала открываю его в нужной папке. Затем проверяю область поиска, отправителя, диапазон дат и включение общих папок. Только после этого разбираю индекс и ошибки импорта. В Carbonio есть механизм переиндексации, но запускать его для всех ящиков после любого переноса оснований нет. Когда данные присутствуют, а поиск их не видит, исправление индекса может помочь. Когда письмо не было импортировано, переиндексация его не вернёт. Лупа не работает машиной времени.

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

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

Фильтры принимаю живым письмом: оно должно попасть в ожидаемую папку, получить метку или пересылку, если так настроено правило. Смотрю порядок правил и их активность, а не только список названий. Перенос сообщений через IMAP не означает переноса всех пользовательских настроек. Экспорт и импорт правил зависят от выбранного метода, поэтому я сохраняю исходные настройки и сравниваю поведение. Если правила требуется создать заново, фиксирую это как отдельную работу, после которой нужен повторный тест.

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

Как проверить восстановление и не перепутать редакции

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

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

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

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

• Названы механизм копирования и состав восстанавливаемых данных
• Копия доступна при отказе основного хранилища
• Восстановление выполнено в изолированном окружении
• Измерены возраст данных и время восстановления
• Проверены настройки и ограничения выбранного метода

Условный разбор: приёмка для «Чистого этажа»

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

В примере закладываю 30 дней наблюдения после запуска; это мой рабочий план для такого разбора, а не обязательный срок вендора. В первый рабочий день проверяю заявку снаружи, ответ с общего адреса, открытие старого вложения и изменение выезда. Представим, что письмо открывается в папке, но не находится из-за выбранного диапазона дат. Я исправляю условия поиска и повторяю тест. Не приписываю этот случай повреждённому индексу: симптом сам по себе не устанавливает причину.

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

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

Когда закрывать проект и что делать при сбое

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

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

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

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

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