Перенос почты с сервера на сервер в больших объёмах: ящики по 50+ ГБ и сотни пользователей без простоя

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

Большая компания — большая цена чужой аварии

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

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

Масштаб превращает аварию в катастрофу

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

Крупной компании своя почта нужна больше всех, и именно крупные компании чаще всего боятся переезда: «сотни ящиков, терабайты, это невозможно без простоя». Возможно. Мы переносили 617 ящиков за три дня. Ниже — как это делается: волнами, параллельно, со сверкой, без единого дня простоя.

Шаг 1. Оценка: сколько, у кого и в чём

Начните с цифр. imapsync с опцией --justfoldersizes подключается к ящику и выводит число писем и объём по каждой папке, ничего не перенося. На стенде оценка ящика из 755 писем заняла 4 секунды. Прогоните её по всем ящикам и сведите результат в таблицу.

docker run --rm -v "$PWD":/var/tmp gilleslamiral/imapsync imapsync \
  --host1 imap.yandex.ru --ssl1 --user1 director@company.ru --passfile1 /var/tmp/pass_y \
  --host2 mail.company.ru --ssl2 --user2 director@company.ru --passfile2 /var/tmp/pass_n \
  --justfoldersizes

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

Шаг 2. Приёмник должен быть готов к объёму

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

• квоты ящиков выставлены с запасом или временно сняты на время переноса
• антиспам и антивирус не проверяют письма, загружаемые по IMAP — обычно так и есть, но убедитесь
• индексация полнотекстового поиска не мешает: её можно отложить и запустить после переноса
• лимиты одновременных IMAP-подключений на приёмнике выше числа потоков
• мониторинг диска и нагрузки включён до начала

Шаг 3. Волны вместо «всех сразу»

Сотни ящиков не переносят одновременно. Мы делим их на волны по 30–80 ящиков: первая — ИТ-отдел и добровольцы, они найдут проблемы на себе; затем отделы по очереди; последними — руководство и бухгалтерия с самыми большими ящиками и самой высокой ценой ошибки. Каждая волна проходит полный цикл: перенос, повторный проход, сверка, разбор ошибок.

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

Шаг 4. Параллельные потоки

Один процесс imapsync переносит один ящик. Чтобы перенести сотни, запускают несколько процессов параллельно. Простой способ — xargs с ключом -P: он держит заданное число одновременных запусков и берёт следующий ящик из списка, как только освобождается поток.

# users.txt: одна строка — один адрес; пароли в pass/<адрес>.y и pass/<адрес>.n
cat users.txt | xargs -P 4 -I{} docker run --rm -v "$PWD":/var/tmp gilleslamiral/imapsync imapsync \
  --host1 imap.yandex.ru --ssl1 --user1 {} --passfile1 /var/tmp/pass/{}.y \
  --host2 mail.company.ru --ssl2 --user2 {} --passfile2 /var/tmp/pass/{}.n \
  --automap --nofoldersizes --logdir /var/tmp/logs --logfile {}.log

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

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

Шаг 5. Крупные письма — отдельным проходом

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

# первый проход: всё, кроме писем больше 50 МБ
... --automap --nofoldersizes --maxsize 52428800
# отдельный проход: только крупные письма, с увеличенным таймаутом
... --automap --nofoldersizes --minsize 52428800 --timeout1 600 --timeout2 600

Проверьте и лимит приёмника: некоторые серверы ограничивают размер письма, загружаемого по IMAP. Такие письма imapsync пропустит с ошибкой в журнале — их видно и их можно обработать отдельно. Обычно это единицы писем на компанию.

Шаг 6. Обрывы и докачка

При переносе ящика на десятки гигабайт обрыв почти неизбежен: перезагрузка, сбой сети, ограничение источника. Это не страшно. imapsync не начинает заново, а сравнивает папки и дописывает недостающее. На нашем стенде перенос большого ящика — 900 писем, из них 700 по 2 МБ, около 1,4 ГБ — прервали через 90 секунд на 602 письмах. Повторный запуск дописал 298, пропустил 602, итог 900 из 900 без ошибок и без дублей.

Поэтому стратегия для больших ящиков простая: запустили, при обрыве — запустили снова тем же скриптом. Для ящиков с сотнями тысяч писем ускоряет повторные проходы кэш UID — опции --useuid и --usecache: imapsync запоминает, какие письма уже перенесены, и не сравнивает заголовки заново.

Шаг 7. Журналы и разбор ошибок

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

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

Шаг 8. Сверка сотен ящиков

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

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

Локальные архивы: письма, которых нет на сервере

В больших компаниях всегда находятся сотрудники, у которых часть почты вообще не лежит на сервере. Outlook годами складывал старые письма в локальные файлы PST, почтовая программа на компьютере бухгалтера хранит архив прошлых лет в локальных папках. imapsync их не увидит: он работает только с тем, что есть на IMAP-сервере.

Выясните это на этапе оценки — короткий опрос и проверка компьютеров руководства и бухгалтерии. Есть два пути. Первый — после переезда подключить файл PST в Outlook к новому ящику и перетащить папки на сервер: письма уйдут на новый сервер по IMAP и окажутся в копиях. Второй — оставить архив локальным, но тогда он не защищён ни копией сервера, ни архивом. Мы всегда рекомендуем первый: локальный архив на одном ноутбуке — та же единая точка отказа, что и облако.

Общие и служебные ящики

Общие ящики — info@, zakaz@, buh@ — часто самые большие и самые важные: в них годами копится переписка с клиентами, и их одновременно читают несколько человек. Переносите их в той же волне, что и отдел-владелец, и сразу настраивайте доступ на новом сервере, чтобы в день переключения сотрудники открыли общий ящик без звонков администратору.

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

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

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

Шаг 9. Переключение и финальный проход

Когда все волны перенесены и сверены, в выходной меняется MX. Сразу после — финальный проход по всем ящикам с --maxage 2: только письма за последние двое суток, по несколько секунд на ящик. На стенде дозаливка пяти новых писем заняла 4 секунды. Для сотен ящиков с параллельными потоками финальный проход укладывается в час-два.

Порядок переключения домена и проверки записей разобраны в статье о смене MX, SPF, DKIM и DMARC, а работа в переходный период, когда почта доставляется в оба места, — в статье о переносе без простоя.

Шаг 10. Безопасность паролей при массовом переносе

Сотни паролей приложений — это сотни ключей от ящиков. Храните их в файлах с правами только для владельца на сервере переноса, не пересылайте почтой и мессенджерами, не передавайте в командной строке — imapsync читает их из --passfile1 и --passfile2, и в списке процессов они не видны. После переезда файлы удаляются, а пароли приложений отзываются в Яндекс 360.

Если сотрудники создают пароли приложений сами, дайте им защищённый способ передать пароль — форму во внутренней системе или менеджер паролей. Подготовка источника по шагам — в статье о подготовке Яндекс 360 к выгрузке.

Что даёт свой сервер после такого переезда

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

Пример переезда сотен ящиков — 617 ящиков гостиничной группы за три дня. Опыт меньших компаний — в кейсах бухгалтерской фирмы на mailcow и юридической фирмы на Carbonio CE. Базовые команды imapsync — в статье «Перенос почты через imapsync».

Типичные ошибки массового переноса

Ошибки больших переездов почти всегда организационные.

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

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