Сколько длится перенос почты с Яндекса и какое окно заложить

Перенос почты с Яндекса может занять дни: 450 ГБ при суммарной скорости 5 Мбит/с требуют минимум 200 часов передачи. Но сотрудники не обязаны ждать всё это время без почты. Я отдельно считаю копирование истории, окно переключения и последующую проверку доставки. Покажу расчёт на условном офисе с 17 рабочими местами.

Как посчитать срок по объёму и реальной скорости

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

Нижнюю границу передачи я считаю так: время в часах = объём в ГБ × 8000 / скорость в Мбит/с / 3600. Здесь ГБ — десятичные, один гигабайт равен миллиарду байт, а скорость — суммарная полезная скорость копирования. Для 450 ГБ при 5 Мбит/с получается 200 часов, при 4 Мбит/с — 250 часов. Для 100 ГБ при 5 Мбит/с — примерно 44,4 часа. Если скорость взята из сетевого счётчика вместе со служебным трафиком, полезная будет ниже. Если интерфейс показывает двоичные единицы объёма, сначала привожу их к тем же единицам. Ошибка между битами и байтами выходные не продлевает.

Формула не учитывает всё время обхода папок, поиска уже перенесённых сообщений, повторных попыток и остановок задания. Я замеряю пилот от запуска до отчёта об окончании, отдельно записываю скопированный объём и число писем. Беру крупный ящик и ящик с множеством мелких сообщений: одинаковый размер не означает одинаковую длительность. Если проверяю параллельный перенос, считаю общий результат всех заданий за один интервал. Скорость одного ящика нельзя просто умножить на количество сотрудников. На основании пилота я даю диапазон и записываю допущения, при изменении которых дату придётся пересчитать.

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

• Объём беру по папкам, включённым в перенос, и отдельно отмечаю исключения.
• Скорость измеряю на машине переноса, без смешения Мбит/с и МБ/с.
• В календарный план добавляю подготовку, повторные проходы и проверку результата.

Условный расчёт: 17 рабочих мест и 450 ГБ

Разберу условный учебный центр «Грамотный офис» в Москве: 17 рабочих мест, переход с Яндекс 360 на mailcow. Для расчёта принимаю 17 ящиков и 450 ГБ почты. Это учебные исходные данные, а не отчёт о выполненном заказе. Допустим, пилот показал устойчивую суммарную полезную скорость 4–5 Мбит/с. Тогда только передача истории требует 200–250 часов непрерывной работы: примерно от восьми суток с третью до десяти с половиной. Обещать при таких вводных закончить копирование за одну ночь нельзя. Даже идеально пустой понедельник эту арифметику не исправит.

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

Для окна переключения я использую другой расчёт. Допустим, перед ним осталось докопировать 1 ГБ новых писем: при 5 Мбит/с одна передача займёт минимум около 27 минут. Но ещё потребуются поиск отличий, проверка папок, смена настроек клиентов и контроль доставки. Поэтому 27 минут не становятся обещанным простоем. Если согласованный резерв не вмещает повторный проход и проверки, я переношу переключение, а сотрудники продолжают работать на старой площадке. Итог этого примера — обоснованный план: история копируется заранее, точное окно определяется репетицией. В рабочем плане рядом с каждым сроком должны стоять замер и условие, при котором этот срок достижим.

Что проверить до запуска: доступ, копию и состав данных

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

Параметры источника для такого подключения: imap.yandex.ru, порт 993, шифрование SSL/TLS. Они приведены в официальной инструкции Яндекса, а не подобраны по памяти. В mailcow есть встроенные задания синхронизации с внешнего IMAP-сервера; я указываю источник, целевой ящик и проверенные учётные данные. Названия полей сверяю с установленным интерфейсом. Начинаю с небольшого объёма и проверяю папки на приёмнике. Не объявляю любой обрыв «блокировкой Яндекса»: сначала смотрю журнал задания, доступность сети и авторизацию. Универсального правила «сессия обрывается через десять минут» для этой миграции у меня нет.

До массового копирования я делаю отдельную резервную копию согласованных данных и проверяю восстановление выбранных писем с вложениями. Способ выбираю под доступные средства и проверяю его на пилоте; обещать всем одинаковую кнопку «Экспорт данных» и готовый архив за сутки нельзя. Также составляю список того, что вообще входит в работу. IMAP переносит письма, но не контакты и календари. Адресные книги, встречи, общие адреса и правила обработки проверяю отдельно, с собственными критериями готовности. Обычная синхронизация не заменяет независимую копию: она может повторить нежелательные изменения. Бэкап без проверки восстановления — пока только уверенная интонация.

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

• Подтвердить вход во все исходные ящики и доступ к ящикам назначения.
• Зафиксировать папки, исключения и отдельный план для контактов и календарей.
• Проверить восстановление резервной копии и наличие места для полного переноса.

Как связать первичное копирование, дельту и смену MX

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

Перед переключением я согласую момент прекращения работы сотрудников со старой системой и выполняю повторный проход. Его длительность измеряю заранее: маленький объём новых сообщений ещё не гарантирует короткое сканирование большого ящика. Затем меняю MX домена на подготовленный приёмник и перевожу клиентов на новую систему по согласованному плану. TXT-запись сама по себе не меняет адрес входящей доставки. IMAP копирует содержимое ящиков, MX определяет маршрут новой входящей почты. Одно действие не выполняет работу другого. Время ожидания DNS также не означает, что весь офис обязательно должен сидеть без доступа к почте.

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

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

Сколько ждать DNS и почему откат не мгновенный

Для срока обновления DNS я смотрю TTL конкретной записи — время её хранения в кэше. Заранее снижаю TTL MX, если это позволяет провайдер DNS, и жду истечения прежнего значения до переключения. Изменение TTL не очищает уже существующие кэши у отправителей. Универсальные обещания «обычно два часа» или «точно не дольше трёх суток» здесь не заменяют проверки. Сначала смотрю ответ авторитетных серверов домена, затем независимых резолверов. Это подтверждает видимость записи из проверенных точек, но не доказывает, что каждый отправитель уже обновил кэш. Поэтому готовность старого приёмника сохраняю и после изменения MX.

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

Откат я тоже описываю до начала работ: кто принимает решение, какие записи возвращаем, куда входят сотрудники и как сохраняем письма, уже принятые новой системой. Вернуть значение в панели DNS можно быстро, заставить все внешние кэши забыть прежний ответ — нельзя. Возвращение MX также не переносит новые сообщения обратно. При временной недоступности SMTP отправитель может поставить письмо в очередь и повторить доставку; это задержка, а не автоматически потерянная корреспонденция. Но на такое поведение нельзя списывать постоянные ошибки адресации или отказ приёмника. Я проверяю реальную доставку и ответы серверов, а не назначаю любой проблеме универсальные «20–60 секунд».

Как назначить окно и понять, что перенос закончен

Я разрешаю переключение по результатам репетиции и проверки приёмника. Должны работать нужные адреса, внешняя отправка и получение, вход сотрудников и доступ к перенесённым папкам. В отчёте не должно оставаться необъяснённых ошибок копирования; отдельно фиксирую согласованные исключения. Процент готовности по гигабайтам здесь слабый критерий: оставшийся маленький ящик может быть главным рабочим адресом офиса. Мои условия — завершённые задания по всем нужным ящикам, измеренный повторный проход и ответственный за решение об откате. Число «99 %» хорошо смотрится в презентации. Одно неперенесённое письмо в процентах не утешается.

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

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

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

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

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