Как рассчитать срок переноса большого почтового архива

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

Что посчитать до обещания «перенесём за ночь»

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

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

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

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

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

Как подготовить доступ, квоту и независимую копию

Перед замером я проверяю вход в исходный ящик и запись на целевой сервис. В справке Яндекса указаны сервер imap.yandex.ru, порт 993 и защищённое соединение SSL/TLS. Для корпоративного ящика логином служит полный адрес. В разделе «Почтовые программы» проверяю доступ по IMAP и настройку «Пароли приложений и OAuth-токены». При подключении по паролю создаю пароль приложения для нужной учётной записи. Статус администратора организации сам по себе не доказывает доступ к содержимому каждого ящика.

На принимающей стороне заранее создаю ящик и сверяю его квоту с согласованным составом архива. Дополнительно проверяю максимальный размер сообщения, ограничения числа элементов и доступное место. У собственного сервера учитываю ещё индексы, журналы и резервные копии; их размер выясняю на пробном переносе. Универсального правила «после 50 ГБ разделить ящик» нет. Например, опубликованные 500 000 элементов и 35 МБ на письмо относятся к штатной IMAP-миграции в Microsoft 365. Переносить эти пределы на любой другой сервис ошибочно.

Резервную копию я готовлю до основной загрузки. Официальная инструкция Яндекса предлагает скачать все письма через почтовую программу, затем экспортировать их средствами этой программы. PST относится к экспорту Outlook, MBOX доступен в поддерживающих его клиентах. Обещание универсальной кнопки в веб-почте, которая сразу выдаст любой нужный формат, здесь лишнее. Выбираю конкретный способ сохранения и заранее проверяю, чем буду читать копию и восстанавливать письма.

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

Как измерить скорость и рассчитать срок архива

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

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

Формула для первого приближения простая: оставшийся объём делю на измеренную скорость полезного копирования. Допустим, в пробе 1,5 ГБ заняли 30 минут. Получается 3 ГБ/ч, а для полного архива 195 ГБ при такой скорости нужно около 65 часов основной загрузки. Это расчётный сценарий, а не обещание поставщика. Если проба уже вошла в целевой архив и её не потребуется повторять, остаток считаю после вычитания загруженного объёма. Подготовку, докачку и проверку оцениваю отдельно.

Для проверки здравого смысла сравниваю прогноз с нижней границей передачи по каналу. При постоянных 100 Мбит/с отправка 195 ГБ в десятичных единицах заняла бы 4 часа 20 минут без накладных расходов. В этом расчёте гигабайт — миллиард байт. Реальная IMAP-загрузка включает запросы к серверу, запись, паузы и возможные ограничения сервиса, поэтому эту границу нельзя выдавать за рабочий срок. Норматив «столько-то минут на гигабайт» я заменяю измерением именно выбранного маршрута.

• Зафиксировать маршрут и реальные условия загрузки.
• Измерить переданные байты, число сообщений, время и ошибки.
• Рассчитать основную загрузку и отдельно оценить остальные этапы.

Как выглядит график для условной «Точки ремонта»

Разберу условный пример сервисной компании «Точка ремонта» в Москве: 21 рабочее место, как задано в исходных условиях. Для расчёта предположу, что у неё 21 ящик: 20 по 2 ГБ и один архивный на 195 ГБ. Получаем 40 ГБ обычной переписки и 235 ГБ всего. Это учебные исходные данные, а не измерения реального клиента. Длительность хранения и прежние простои к этому примеру не приписываю: они не нужны для расчёта и ничем не подтверждены.

Предположим, проба группы обычных ящиков дала суммарно 8 ГБ/ч, а отдельная проба большого архива — 3 ГБ/ч. Тогда для группы нужно около 5 часов, для архива — около 65 часов основной загрузки. Складывать эти скорости и объявлять результат параллельного запуска нельзя: оба замера сделаны отдельно. Я выделяю архиву собственное задание и начинаю его заранее, а для рабочих ящиков согласую свободную полосу и нагрузку. Затем проверяю совместную работу и пересчитываю график по полученным данным.

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

Итог этого условного разбора — ведомость на 235 ГБ, две управляемые группы и прогноз, который предстоит уточнить совместной пробой. Решение о переходе сотрудников принимаю после согласования того, какой объём истории должен быть доступен к этому моменту. Полный архив может быть условием переключения, а может загружаться по согласованному плану отдельно. Условия фиксирую заранее. Если появляются ошибки, сначала нахожу их причину; сам факт тайм-аута ещё не доказывает, что виноват размер ящика.

Как продолжать загрузку и контролировать остаток

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

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

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

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

• Хранить настройки задания и журнал каждого запуска.
• После пробы проверить докачку и появление дубликатов.
• Пересчитывать остаток после изменения нагрузки или устранения ошибок.

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

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

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

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

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

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

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