Почему большой почтовый ящик не переносится через IMAP

У IMAP нет общего потолка в 50 ГБ: перенос останавливают квота целевого сервиса, предел размера письма или числа элементов, лимит соединений и ошибки авторизации. Я сначала проверяю ограничения обеих платформ и журнал переноса, а уже потом меняю настройки. Ниже — план проверки и разбор условного сценария.

Почему перенос останавливается: ищем границу сбоя

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

Я начинаю с журнала обеих сторон и сопоставляю время сбоя: есть ли ответ сервера, на какой папке и письме остановилась обработка, осталась ли сессия открытой. В RFC для команды IMAP IDLE описан возможный таймаут бездействия, но это не универсальный предел времени передачи письма и не одно число для всех серверов. Если ошибка указывает на разрыв, сравниваю время в журнале клиента, источника и цели: так видно, кто первым закрыл сессию, а кто только записал следствие. Затем проверяю сеть и политику соединений; если на отказ записи — квоту и ограничения получателя; если на вход — учётную запись и разрешения. Для планирования такого переноса мы предлагаем корпоративную почту: сначала фиксируем ограничения, затем согласуем порядок работ.

• Ошибка входа — проверить доступ и пароль.
• Разрыв сессии — сверить логи сервера и сети.
• Отказ записи — проверить квоту и лимиты цели.
• Остановка на письме — проверить его размер и папку.

Почему 50 ГБ — не универсальный предел IMAP

Число 50 ГБ часто всплывает в описаниях почтовых планов, но это не ограничение протокола IMAP и не универсальная квота Microsoft 365. Доступный объём зависит от лицензии, типа ящика и настроек организации. В актуальной таблице Microsoft для пользовательских ящиков Exchange Online указаны разные значения: например, для некоторых планов — 50 ГБ, для других — 100 ГБ; отдельные ограничения действуют для общих и архивных ящиков. Поэтому сравнивайте фактическую квоту конкретного целевого ящика с объёмом данных, а не с цифрой из чужой инструкции. Ящик больше 50 ГБ не означает автоматически, что миграция невозможна; он может просто не помещаться в выбранную квоту или требовать другого сценария переноса.

Есть и другая путаница: общий объём ящика смешивают с ограничением на одно письмо. Для IMAP-миграции в Exchange Online Microsoft указывает максимум 35 МБ для отдельного сообщения и до 500 000 элементов из одного пользовательского ящика; элементы переносятся от новых к старым. Если писем больше, старые могут не попасть в такой перенос. Это ограничения конкретного механизма миграции, а не нормы всего IMAP и не пределы любого почтового сервиса. Число 1,5 ТБ в документации Microsoft относится к максимальной ёмкости авторасширяемого архивного ящика при определённых условиях, а не к общему правилу «ящик такого размера нельзя перенести». Если превышен лимит письма, его не надо молча удалять: согласуйте отдельный способ сохранения. Если превышена квота, сначала подтвердите доступный план и маршрут миграции.

• Квота ящика зависит от сервиса и плана.
• Лимит сообщения относится к каждому письму.
• Число элементов — отдельное ограничение миграции.
• Сверяйте каждую цифру с документацией цели.

Условный сценарий: большой ящик и отказ на последнем этапе

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

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

• Зафиксировать квоту источника и цели.
• Найти первое сообщение с ошибкой.
• Проверить доступ к обеим сторонам.
• Повторить перенос на небольшой выборке.

Когда помогает imapsync и чего он не делает

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

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

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

Подготовка: квоты, доступ и пробная партия

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

Первый запуск делаю на небольшой партии. Так можно проверить авторизацию, структуру папок, журнал ошибок и реальную скорость, а также подобрать число одновременных подключений под конкретный сервер и канал. Универсальное «переносить по 10–20 ящиков» здесь не работает: у источников разные пределы, и чрезмерный параллелизм может только замедлить работу. Microsoft советует проводить тестовые партии и определять подходящее число одновременных соединений по результатам. Для миграции Exchange Online через IMAP файл CSV содержит одну строку на пользователя и допускает до 50 000 строк и размер до 10 МБ; это предел файла, а не совет запускать всех разом. Большой список разумно делить на партии и проверять каждую до следующей. Перед стартом полезен отдельный стенд для проверки переноса почты.

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

Как завершить перенос и убедиться в результате

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

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

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

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