imapsync: практическое руководство по безопасной миграции почты (2026)

Перед вами проект миграции, который заставляет нервничать. Нужно перенести почту с сервера A на сервер B, не потеряв ни одного сообщения, не разрушив структуру папок и не заплатив стороннему поставщику $15 за пользователя за «лицензию на миграцию» только ради перемещения уже принадлежащих вам данных.

Вам нужен imapsync. В этом руководстве подробно объясняется, как воспользоваться им и не повредить почтовые ящики пользователей.

Что такое imapsync и чем он не является

imapsync представляет собой утилиту командной строки для синхронизации почтовых ящиков между двумя IMAP-серверами. Она работает как посредник: одновременно подключается к обоим серверам, читает сообщения на исходном сервере и добавляет их на целевой. Утилита отслеживает состояние, справляется с прерываниями и сохраняет структуру папок, флаги и содержимое сообщений.

Это не средство резервного копирования и не SMTP-релей. imapsync не работает с Google Календарем, контактами Outlook или правилами транспорта Exchange. Он поддерживает только IMAP. Если исходный сервер изолирован межсетевым экраном или отключен, imapsync не сможет к нему подключиться. Без вариантов.

Стандартным отраслевым инструментом для переноса данных между ящиками его делает механизм сохранения состояния. Успешная миграция означает не просто перенос текста, а сохранение трех составляющих:

• Содержимое: тело сообщения в формате RFC 822, вложения, кодировка MIME и все, что находится внутри конверта.
• Метаданные: флаги. \Seen (прочитано), \Answered (есть ответ), \Flagged (помечено). Если их не перенести, в первый день каждый пользователь увидит 4,000 якобы новых непрочитанных писем.
• Структура: иерархия папок. На новом сервере INBOX/Clients/ProjectA должна выглядеть точно так же, а не превращаться в одну плоскую папку с буквальным именем INBOX.Clients.ProjectA и точками внутри.

imapsync сохраняет все три составляющие, если правильно его настроить. Именно в настройке заключается основная сложность, и разобраться с ней поможет это руководство.

Жесткие ограничения: imapsync сам по себе не знает об ограничениях скорости Gmail или лимитах API Microsoft. Запустите его на полной скорости, и ваш IP-адрес могут заблокировать. Кроме того, он не отправляет данные по собственной инициативе: чтобы перенести их в другое место, их нужно забирать с источника. По умолчанию imapsync также ничего не удаляет на целевом сервере. Это мера безопасности, которая может создать проблемы при невнимательном использовании, о чем рассказано на этапе 6.

Подробнее о самом протоколе читайте в нашем руководстве по настройке почты на своем домене.

Этап 1: тщательное обследование. Не пропускайте его

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

1. Найдите самые крупные ящики

У одного из пользователей ящик размером 45GB. Возможно, это генеральный директор. А может быть, сотрудник, которому с 2011 года принадлежит псевдоним sales@. Если попытаться перенести такой ящик в одной группе с ящиками по 500MB, весь процесс застопорится, а вы будете смотреть на замерший терминал, не понимая, сколько уже сделано.

Сначала выполните предварительное сканирование:

imapsync \
  --host1 imap.source.com --user1 user@source.com --passfile1 /secret/pass1 \
  --host2 imap.dest.com --user2 user@dest.com --passfile2 /secret/pass2 \
  --dry --justfoldersizes

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

2. Проблема скрытых данных

В любой компании есть заброшенные учетные записи: ящики бывших сотрудников, почта которых до сих пор куда-то пересылается, и «служебные учетные записи», на деле являющиеся общими ящиками для принтера или устаревшей интеграции с CRM. Если не учесть их при инвентаризации, после переключения DNS эти данные останутся на старом сервере.

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

3. Правду показывает количество элементов

Никогда не доверяйте объему в гигабайтах. Исходный сервер A может показывать размер ящика 10GB, а целевой сервер B оценит точно те же данные в 11GB. Это не ошибка: разные серверы по-разному рассчитывают занятый объем. Exchange учитывает папку Recoverable Items, также называемую «Dumpster», а Gmail устраняет дубликаты сообщений между ярлыками.

Важный показатель здесь один: количество элементов. Если на исходном сервере 14,200 сообщений и на целевом сервере 14,200 сообщений, перенос завершен. Расхождение в объеме менее 10% нормально и ожидаемо. Если оно превышает 10%, разберитесь в причине до окончательного подтверждения.

Этап 2: безопасный процесс миграции

Крупнейшая ошибка при любой миграции заключается в подходе «Big Bang»: перенести все в пятницу вечером и надеяться, что процесс завершится к утру понедельника. Если у вас 50GB почты и ограничение в 500KB/s, такой расчет не сходится. В понедельник сервис не заработает, а вам придется объяснять генеральному директору, почему его входящие пусты.

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

Шаг 1: пробный запуск

Прежде чем переносить хотя бы один байт, проверьте возможность подключения. Используйте --dry вместе с --justfolders. Такая команда имитирует выполнение и показывает структуру папок, ничего не копируя.

imapsync \
  --host1 imap.gmail.com --user1 user@source.com --passfile1 /secret/pass1 \
  --host2 imap.trekmail.net --user2 user@dest.com --passfile2 /secret/pass2 \
  --dry --justfolders

Проверьте две вещи: прошла ли аутентификация и как выглядят имена папок. Если на исходном сервере есть [Gmail]/Sent Mail, ее нужно сопоставить с Sent Items на целевом. Не дожидайтесь рабочего переключения, чтобы это выяснить.

Шаг 2: основная предварительная синхронизация

Запустите ее за 1-2 недели до переключения, пока пользователи еще работают в старой системе. Цель состоит в том, чтобы заранее убрать с критического пути 90-95% данных.

imapsync \
  --host1 imap.source.com --user1 user@source.com --passfile1 /secret/pass1 \
  --host2 imap.dest.com --user2 user@dest.com --passfile2 /secret/pass2 \
  --usecache --skipsize --maxsize 25000000

--usecache является обязательным параметром. Он сохраняет состояние миграции локально. Каждый последующий запуск сверяется с этим кэшем и обрабатывает только изменения, не просматривая все сообщения заново. Без него при каждом запуске выполняется полное сканирование.

--maxsize 25000000 пропускает на первом проходе сообщения размером более 25MB. Большие вложения чаще всего приводят к тайм-аутам и разрывам соединения. Их можно перенести отдельным запуском с увеличенными тайм-аутами.

Шаг 3: дельта-синхронизация

За несколько дней до переключения снова запустите imapsync. Утилита прочитает кэш, увидит, что 10,000 писем уже находятся на целевом сервере, пропустит их и скопирует только 50-100 новых сообщений, поступивших после основной синхронизации. Такой запуск должен занять минуты, а не часы.

Шаг 4: переключение

Настал решающий момент. Действуйте последовательно:

1. Уменьшите TTL DNS: за 48 часов до переключения установите для MX-записи TTL в 300 секунд. Если ждать до последней минуты, некоторые резолверы будут кешировать старую MX-запись до 24 часов, и письма продолжат поступать на старый сервер уже после переключения.
2. Измените MX-записи: направьте их на нового поставщика.
3. Подождите 60 минут, пока распространение изменений стабилизируется на основных резолверах.
4. Выполните финальную дельту: последний проход imapsync перенесет сообщения, попавшие на старый сервер во время распространения изменений.

Подробное описание окна изменения DNS и наблюдения за распространением приведено в нашем руководстве по настройке почты на своем домене.

Этап 3: флаги, папки и ловушка с отправленными сообщениями

IMAP-серверы говорят на разных диалектах. Если не переводить между ними, утром пользователи обнаружат ящик со сломанной структурой и вполне обоснованно обвинят вас.

Проблема с разделителем

Это самый распространенный технический сбой, о котором никто не говорит, пока не столкнется с ним сам.

Разные IMAP-серверы используют разные символы для разделения уровней в иерархии папок:

• Dovecot обычно использует точку: INBOX.Clients.ProjectA
• Exchange/Outlook использует косую черту: INBOX/Clients/ProjectA
• Некоторые серверы обходятся без разделителя и полагаются на команду IMAP NAMESPACE

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

Решить проблему позволяет --regextrans2: этот параметр на лету переписывает пути к папкам при помощи регулярных выражений. Перед пакетной миграцией 100 пользователей всегда проверяйте создание папок с параметром --dry на одной тестовой учетной записи.

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

На каждом сервере папка отправленных сообщений называется по-своему. Это не мелкое неудобство: если его проигнорировать, пользователи столкнутся с серьезной проблемой.

Без сопоставления пользователь получит две папки отправленных сообщений: активную Sent Items и новую папку-призрак Sent Mail со всей историей. Пользователь это заметит и будет недоволен.

Укажите сопоставление явно:

--regextrans2 's/^\[Gmail\]\/Sent Mail/Sent Items/'

Эта команда сообщает imapsync: «Если имя исходной папки начинается с [Gmail]/Sent Mail, назови ее Sent Items на целевом сервере». Сначала выполните полный набор сопоставлений с параметром --dry, чтобы до рабочего запуска убедиться в правильном срабатывании каждого правила.

Ловушка All Mail в Gmail

В Gmail есть папка [Gmail]/All Mail. Она содержит копию каждого письма независимо от ярлыка. Это внутреннее представление всех сообщений Gmail, доступное как папка IMAP.

Если перенести All Mail вместе с Inbox и Sent Mail, каждое письмо появится на целевом сервере в двух или трех экземплярах. Ящик размером 10GB превратится в ящик на 30GB, а все сообщения будут повторяться. Это катастрофа.

Всегда исключайте эту папку:

--exclude "All Mail"

Также исключите [Gmail]/Spam и [Gmail]/Trash, если только у вас нет конкретной причины переносить их. Старый спам не нужен никому.

Этап 4: настройка производительности и ограничение скорости

Нельзя отправлять данные в Google или Microsoft на полной скорости. Их инфраструктура воспринимает высокоинтенсивное соединение IMAP точно так же, как атаку типа «отказ в обслуживании», поскольку с ее точки зрения они выглядят одинаково.

Штрафная зона

Если превысить лимиты, обычно около 1 сообщения в секунду или 500MB в час для Gmail, сервер начнет возвращать HTTP 429, NO [OVERQUOTA] или просто ошибки BAD. Если продолжить, учетная запись будет заблокирована на 24 часа. Такого обращения в поддержку лучше избежать.

Параметры настройки

--maxmessagespersecond 1     # Hard speed limit: 1 email per second
--maxbytespersecond 500000   # Bandwidth cap: 500KB/s
--timeout 120                # Network timeout in seconds (default is often too short for big attachments)
--reconnectretry1 3          # Retry on source connection drops
--reconnectretry2 3          # Retry on destination connection drops

1 сообщение в секунду кажется мучительно низкой скоростью. Так и есть. Но стабильный процесс в итоге завершается. Агрессивный запуск, заблокированный на 3-м часу, не завершится никогда.

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

Если вы выполняете миграцию в TrekMail, наша система приема по IMAP хорошо справляется с большим количеством параллельных подключений. Целевой сервер можно нагружать сильнее, чем исходный сервер Google или Microsoft.

Этап 5: аутентификация. Проблема современных методов входа

Времена, когда password123 можно было положить в обычный текстовый файл, прошли. Google и Microsoft отказались от базовой аутентификации для IMAP. При попытке использовать стандартные учетные данные вы получите ошибку аутентификации и потратите час, пытаясь понять, что сделали не так.

Пароли приложений (вариант для малого и среднего бизнеса)

Для большинства миграций одного домена самым быстрым решением будут пароли приложений. Это строки из 16 символов, которые обходят 2FA и работают с устаревшими клиентами IMAP:

1. Войдите в исходную учетную запись (Gmail, Workspace и т. д.)
2. Включите 2-факторную аутентификацию, если она еще не включена: без нее создать пароль приложения нельзя
3. Перейдите в настройки безопасности → Пароли приложений
4. Создайте пароль для приложения «Почта» на «Другом устройстве»
5. Используйте полученную строку как пароль в файле, переданном imapsync через --passfile

Храните его в файле с правами chmod 600, а не в командной строке. Учетные данные в истории Bash рано или поздно приведут к проблеме.

OAuth2 (вариант для MSP и крупных организаций)

Если MSP переносит 500 пользователей, вручную создать 500 паролей приложений невозможно. Потребуется OAuth2. Этот путь сложнее, но только он реалистичен в таком масштабе:

1. Зарегистрируйте приложение в исходном тенанте (в Azure AD для Microsoft или Google Cloud Console для Google)
2. Предоставьте ему полный доступ к почтовым ящикам всего тенанта, для чего потребуется одобрение глобального администратора
3. Создайте Refresh Token для каждого пользователя или используйте доступ от имени сервисного аккаунта
4. Передайте токен imapsync с помощью --oauthaccesstoken1

Если неправильно настроить разрешения приложения в Azure AD или GCP, доступ будет запрещен ко всем ящикам или, что еще хуже, приложение случайно получит более широкие права, чем предполагалось. Внимательно изучите области разрешений, прежде чем нажимать «Предоставить согласие администратора».

Практический подход к крупномасштабной миграции описан в нашем руководстве по управлению почтой клиентов.

Этап 6: типичные сбои и восстановление

Даже идеальный план сталкивается с проблемами. Разберем, как понять причину сбоя и исправить его, не начиная все заново.

1. Проблема UIDVALIDITY (худший сценарий)

У каждой папки IMAP есть уникальный идентификатор UIDVALIDITY. По нему imapsync определяет, какие сообщения уже скопированы. Если папку на исходном сервере удалить и создать заново или индекс сервера повредится и будет перестроен, этот идентификатор изменится.

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

Решение: удалите локальные файлы кеша из временного каталога и запустите процесс повторно с параметром --useheader:

--useheader

Этот параметр заставляет imapsync сравнивать неизменяемый уникальный заголовок Message-ID каждого письма вместо UID папки. Процесс замедлится, но дубликаты не появятся. Используйте параметр всякий раз, когда подозреваете, что индекс исходного сервера изменялся.

2. Поврежденные сообщения и сообщения нулевого размера

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

Признак: imapsync пытается получить сообщение, сервер зависает на 120 секунд, а затем разрывает соединение. Цикл бесконечно повторяется на одном и том же сообщении.

Решение:

--minbytes 10

Параметр указывает imapsync пропускать сообщения размером менее 10 байт. Настоящее письмо не может быть короче 10 байт. Фактически это безопасный для любой миграции фильтр, пропускающий пустые файлы.

3. Проблема с возвращающимися удаленными сообщениями

В понедельник вы выполнили основную синхронизацию. Во вторник пользователь удалил 50 писем на исходном сервере. В среду вы запускаете дельту.

По умолчанию imapsync только добавляет почту и не удаляет на целевом сервере то, что было удалено на исходном. Для большинства случаев это намеренное и правильное поведение. Однако 50 удаленных писем снова появятся в новом ящике. Пользователи опишут их как «письма-призраки» или «удаленные письма, которые вернулись».

Решить проблему позволяет --delete2, но применять этот параметр нужно крайне осторожно:

--delete2

Этот параметр сообщает imapsync: если сообщения нет на исходном сервере, удали его на целевом.

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

4. Разрывы соединения на крупных вложениях

PDF-вложение размером 40MB иногда приводит к зависанию IMAP-соединений с коротким тайм-аутом. Сервер отправляет сообщение, в сети возникает краткий сбой, соединение обрывается на 95%, а imapsync регистрирует ошибку и переходит дальше. На целевом сервере остается неполное сообщение.

Решение: увеличьте --timeout до 300 секунд для проходов с крупными вложениями. Можно также использовать --maxsize 25000000, чтобы пропустить их во время основной синхронизации, а затем выполнить отдельный проход с менее строгими ограничениями скорости и увеличенными тайм-аутами.

Проверка: как убедиться, что миграция прошла успешно

Скрипт завершился. В терминале написано, что все готово. Но как узнать, что письма генерального директора не исчезли где-то в нулевом маршруте?

1. Изучите итоговый блок

В конце каждого запуска imapsync выводит сводку. Важны три показателя:

• Transferred: при финальном запуске дельты должно быть указано 0. Ненулевое значение означает, что какие-то сообщения все еще не были перенесены.
• Skipped: значение должно совпадать с общим количеством исходных сообщений или превышать его. Это сообщения, уже присутствующие на целевом сервере.
• Errors: должно быть указано 0. Любое ненулевое количество ошибок нужно исследовать, прежде чем считать работу выполненной.

2. Выборочная проверка

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

• Sent Items: присутствуют ли отправленные письма за все годы и правильно ли они расположены?
• Глубоко вложенная подпапка: верно ли выглядит иерархия?
• Самое недавнее письмо: совпадает ли оно с письмом на исходном сервере?
• Помеченное сообщение: сохранился ли атрибут \Flagged?

3. Поиск по журналу

Пользователь сообщает о пропавшем письме. Прежде чем отвечать, что оно наверняка потерялось, проверьте журнал:

grep -i "bob@sender.com" /var/log/imapsync/user@source.com.log

В журнале зафиксирована судьба каждого сообщения: Transferred, Skipped (уже находилось на целевом сервере) или Error с конкретным кодом ошибки. При наличии Error вы точно узнаете, какое сообщение, какая папка и какой код ошибки стали причиной. Восстановление следует начинать с этих данных, а не с догадок.

4. Сверка количества элементов

Для окончательной проверки напрямую запросите сведения на обоих серверах:

# On source (example for Dovecot)
doveadm mailbox status -u user@source.com messages '*'

# Or use imapsync's own count
imapsync ... --dry --justfoldersizes 2>&1 | grep "Messages"

Сравните количество элементов на исходном и целевом серверах. Расхождение должно находиться в пределах 1-2% с учетом исключенных папок со спамом и устранения дубликатов Gmail All Mail. При большем расхождении изучите журнал ошибок до окончательного подтверждения.

Альтернатива: обойтись без терминала

Мы написали это руководство, потому что ценим прозрачность. imapsync подходит администраторам, которым нужен полный контроль и которых не пугают зависимости Perl, регистрация приложений OAuth2 и анализ журналов.

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

Встроенный инструмент миграции TrekMail работает на стороне сервера: не нужно три часа перетаскивать папки в Outlook или разбираться с зависимостями Perl. Укажите источник (Gmail, cPanel или любой стандартный IMAP-сервер), введите учетные данные, и сервер выполнит перенос. За ходом процесса можно следить в панели управления.

Модель оплаты тоже отличается от привычной. Платы за каждого пользователя нет. Тарифы с фиксированной стоимостью начинаются от $3.50 в месяц и охватывают до 100 пользователей в 50 доменах с общим хранилищем. Один руководитель с 40GB вложений не заставит повышать тариф для всех, поскольку хранилище распределяется на уровне учетной записи.

Сравнить состав тарифов можно на странице цен TrekMail. Пошаговый процесс работы самого инструмента описан в руководстве «Запуск миграции» в нашей документации.

Независимо от того, пишете ли вы собственные скрипты для imapsync или используете нашу платформу, цель одна: перенести почту без потери данных, лишних проблем и платы за каждое рабочее место.

Если вы готовы отказаться от платы за пользователя и хотите поручить миграцию нам, попробуйте TrekMail бесплатно: 14 дней без банковской карты.