Что я считаю перед переносом почты с Яндекса
Перед переносом почты с Яндекса я составляю реестр ящиков, дополнительных адресов, объёмов и подключённых приложений. Затем согласую судьбу архивов и проверяю доступ на тестовой копии. На выходе нужен список объектов с владельцами и критериями приёмки. Ниже покажу состав таблицы и разберу условный офис на 12 рабочих мест.
С чего начать инвентаризацию почты с Яндекса
Я сначала назначаю ответственного за список и согласование спорных адресов. Когда мы готовим корпоративную почту для компании, одного списка сотрудников недостаточно: отдельно нужны личные ящики, общие ящики, алиасы, группы и архивы. Для каждого объекта я фиксирую владельца, назначение и решение о переносе. Если никто не может объяснить, кому нужен адрес, ставлю вопрос на согласование. До ответа объект остаётся в реестре. Пропавший из таблицы адрес никто автоматически не восстановит.
Основу списка беру из кабинета организации, затем сверяю её с теми, кто пользуется почтой. Спрашиваю про адреса на сайте и в документах, получение заявок, отправку счетов, уведомления и переписку бывших сотрудников. У каждого дополнительного адреса должно появиться объяснение: куда приходит письмо, кто его читает, кто отвечает. Запись «общая почта» я возвращаю на доработку: за ней может скрываться отдельный ящик, рассылка или алиас. Для миграции это разные объекты с разными действиями.
Я развожу две задачи. Общий аудит почтовой инфраструктуры оценивает устройство системы и её проблемы. Здесь результат уже: заполненная карта объектов, зависимостей и решений до начала копирования. Она отвечает на вопрос, какие данные и настройки включены в работу. Выбор новой платформы, схема доставки и настройка сервера потребуют своих проверок. Если смешать всё в одном документе, список адресов легко потеряется между обсуждением лицензий и спором о любимом почтовом клиенте.
Для каждой строки я оставляю дату проверки и способ подтверждения: кабинет организации, список папок, контрольное письмо, ответ владельца. Слова «вроде работает» статусом готовности не считаю. До теста отдельно согласую, кто имеет право читать содержимое и кто проверяет результат. На этапе сбора сведений обычно хватает настроек и статистики; открывать всю переписку ради подсчёта ящиков не требуется. В конце владелец списка подтверждает состав переноса, а спорные строки остаются видимыми. «У нас всего двенадцать человек» — хорошее начало разговора. Сметой оно пока не стало.
Какие поля нужны в реестре ящиков и адресов
Я веду связанные записи: объект хранения и адреса, которые к нему ведут. Яндекс описывает алиас как дополнительный адрес существующего ящика. Поэтому я не прибавляю объём одного ящика повторно за каждый его алиас. Для группы фиксирую участников и разрешения, для общего ящика — пользователей и права. Отдельно проверяю отправку с дополнительного адреса: успешное получение ещё не доказывает, что сотрудник сможет ответить от нужного имени. Эти сведения превращают перечень адресов в задание на настройку.
Минимальный набор полей я выдаю сразу. Таблица ниже — шаблон, её строки нужно заполнить для своей организации. Пароли в неё не попадают: достаточно ссылки на защищённое хранилище и статуса проверки доступа. В примерах адресов я использую только example.com. | Поле | Что я записываю | |---|---| | Адрес и тип | Основной ящик, алиас, группа, общий ящик | | Владелец | Кто подтверждает назначение и результат | | Объём и дата замера | Размер писем, число сообщений и папок | | Связанные адреса | Куда ведёт алиас, кто входит в группу | | Дополнительные данные | Контакты, календари, локальные архивы | | Подключения | Клиенты, приложения, способ авторизации | | Решение | Перенести, сохранить отдельно, уточнить | | Проверка | Доступ, пилот, замечания, согласование |
На дату замера я записываю объём, число сообщений, дерево папок и размер самого крупного письма, если выбранный инструмент позволяет его получить. Серверную почту сверяю с локальными архивами на рабочих компьютерах: они могут отсутствовать в веб-интерфейсе и не войти в копирование между серверами. Квоту принимающего ящика проверяю отдельно от его текущего размера. Если целевая квота меньше согласованного объёма, задача пока не готова к запуску. Разницу нельзя закрыть надеждой, что пользователь сам удалит лишнее.
Контакты, календари, фильтры, подписи и права я перечисляю отдельными объектами. Обычный перенос писем через IMAP, в том числе imapsync, не переносит контакты и календари; для них нужен отдельный способ и отдельный тест. Правила обработки и настройки веб-интерфейса тоже нельзя считать частью скопированных писем. Я заранее записываю, что будет восстановлено вручную, что поддерживает выбранный сервис и какое отличие согласовано. Конкретные действия для переноса алиасов и правил выношу в следующий этап. В реестре главное — не забыть эти объекты и назначить проверяющего.
Как сохранить архивы и проверить резервную копию
Я не начинаю инвентаризацию с массового удаления старых писем. Дата последнего входа показывает активность учётной записи, но сама по себе не определяет ценность переписки. Даже давно не открывавшийся ящик может получать документы или хранить нужную историю. Решение принимает ответственный за данные с учётом внутренних требований к хранению. Для каждого архива я записываю владельца, состав, место хранения и способ поиска. Статус «бывший сотрудник» не заменяет ни одного из этих полей.
После согласования я выбираю судьбу объекта: перенести в рабочую почту, сохранить отдельную проверяемую копию либо удалить по утверждённому списку. Режим доступа к архиву проверяю на выбранной платформе: обещание «только чтение» должно соответствовать её возможностям и выданным правам. Копии одинаковых писем в разных ящиках не удаляю автоматически. Для пользователей это могут быть разные рабочие экземпляры с собственными папками и отметками. Уборка допустима, когда понятны её границы и есть проверенная копия исходных данных.
В исходных рекомендациях встречается кнопка «Экспорт данных», якобы сохраняющая всю организацию. Я такой гарантии не даю. Документация Яндекс ID описывает заказ архива данных отдельного аккаунта через раздел «Данные на сервисах». Это не обещание готовой резервной копии всех корпоративных ящиков, адресов, прав и настроек. Я выбираю способ сохранения для каждого типа данных, проверяю состав выгрузки и возможность её прочитать. Для резервной копии почты нужна собственная проверка восстановления. Архив, который никто не открывал, пока доказывает только существование файла.
В реестре копий я указываю, какие ящики и папки охвачены, когда выполнена выгрузка, где она хранится и кто проверил чтение. Выборочно открываю старые письма с вложениями и проверяю нужную переписку по заранее согласованным примерам. Отдельно сохраняю описание адресов и настроек: письма не восстановят состав группы рассылки. Исходную почту оставляю доступной до сверки и завершения согласованного переходного периода. Его длительность записываю в план конкретного проекта. Универсального срока хранения, который подходит любому переезду, здесь нет.
Что выявит проверка офиса на 12 рабочих мест
Разберу условный пример: проектное бюро «Северный чертёж», Москва, 12 рабочих мест. Числа ниже заданы для расчёта, это не отчёт о реальном клиенте. На входе есть запрос перенести 12 личных ящиков на собственный сервер. В примере каждый занимает 3 ГБ, значит, личная переписка — 36 ГБ. При проверке я добавляю три самостоятельных общих ящика: info@example.com, tender@example.com и archive@example.com. Ещё отдельно учитываю архив бывшего сотрудника. Число рабочих мест осталось прежним, а объектов хранения стало больше.
Чтобы расчёт можно было проверить, я фиксирую размеры без диапазонов. Дополнительные адреса и группы считаются отдельно от хранилищ и не увеличивают эти суммы повторно. Гигабайты здесь условно взяты в одной единице измерения для всех строк. | Объекты в примере | Количество | Объём | |---|---|---| | Личные ящики | 12 | 36 ГБ | | Общие ящики | 3 | 20 ГБ | | Архив бывшего сотрудника | 1 | 40 ГБ | | Всего | 16 | 96 ГБ | Общие ящики занимают 2, 15 и 3 ГБ соответственно. Так получается 20 ГБ, а вместе с личной почтой и архивом — 96 ГБ. Эти же числа должны стоять на схеме. Красивый рисунок арифметику не отменяет.
В этом сценарии я отдельно задаю подключение системы учёта заявок к tender@example.com по IMAP. Для него нужны ответственный, параметры подключения и проверка получения нового письма после перенастройки. Если приложение также отправляет ответы, проверяю исходящее подключение отдельно. Документация почтовых интеграций CRM различает способы авторизации и параметры входящей и исходящей почты. Поэтому строка «интеграция есть» работу не закрывает. Мне нужен контрольный сценарий: новое обращение появляется там, где его обрабатывают, ответ уходит от согласованного адреса.
Следующий шаг в примере — пилот личного ящика и общего ящика с подключением приложения. Я сохраняю отдельную задачу для архива на 40 ГБ, но порядок его копирования определю после замера и согласования доступности истории. Называть два или три дня до пилота было бы выдумкой. Результат инвентаризации уже конкретен: 16 объектов хранения, 96 ГБ исходных данных, перечень дополнительных адресов и отдельный тест интеграции. Конкретную версию нового сервера и его конфигурацию запишу после выбора платформы; для этого расчёта они не заданы. Условный кейс не должен выдавать придуманный успешный переезд за доказательство метода.
Как проверить доступы и оценить срок переноса
Я проверяю доступ к каждому исходному ящику тем способом, которым пойдёт копирование. Для Яндекс Почты это включает раздел «Почтовые программы»: доступ по IMAP и опцию «Пароли приложений и OAuth-токены». При авторизации по паролю нужен пароль приложения, созданный в Яндекс ID; одно включение IMAP его не заменяет. Для Яндекс 360 для бизнеса логином служит полный адрес ящика. Вход в браузере показывает доступ к веб-интерфейсу, но не доказывает, что инструмент миграции сможет подключиться. Успешное чтение списка папок я отмечаю отдельно.
В параметры исходного подключения для работы из России записываю imap.yandex.ru, порт 993 и защищённое соединение SSL/TLS, как указано в документации Яндекса. Для каждого приложения сохраняю фактический способ авторизации и место, где предстоит изменить настройки. Проверяю почтовые клиенты, телефоны, CRM, 1С, устройства отправки сканов и задания с уведомлениями. Для отправки нужен отдельный тест: входящая почта и исходящие письма используют разные подключения. Пароли в реестре не храню. После завершения работ отзываю временные доступы миграции, предварительно убедившись, что рабочие приложения на них не завязаны.
Срок оцениваю по пилоту: фиксирую число скопированных сообщений, объём, продолжительность, ошибки и поведение при повторном запуске. Набор мелких писем и набор крупных вложений могут копироваться с разной скоростью при одинаковом объёме. Поэтому формулу «мегабайт равен минуте» убираю без сожаления. Проекция времени по измеренной скорости даёт только ориентир для похожих данных; проверка остальных папок и ограничения сервисов остаются в плане. До обещания даты я уточняю доступное окно работ, квоты, допустимую параллельность и время на проверку пользователями.
Память тоже оцениваю по измерениям. Общий объём ящика не означает, что его содержимое целиком окажется в оперативной памяти. В документации imapsync среди причин большого расхода памяти названы крупные сообщения и обработка больших папок. Я наблюдаю за процессом на пилоте, затем выбираю число одновременных задач. Копирование небольшими партиями упрощает контроль и повторную обработку ошибок, но не делает допустимой потерю данных одной партии. При обычном копировании imapsync по умолчанию не удаляет письма; отдельные режимы удаления требуют осознанной настройки. Сбой задачи означает необходимость разобраться и докопировать данные, а не согласие потерять часть почты.
Когда реестр готов к тестовому переносу
Я допускаю реестр к следующему этапу, когда у каждого объекта есть владелец, решение, проверенный доступ и адрес назначения. До переключения приёма почты проверяю создание нужных ящиков и маршрутов доставки на новой стороне. Пилот выполняю на копировании, сохраняя исходные данные. В imapsync повторный запуск при неизменных условиях сопоставления позволяет докопировать недостающее: по умолчанию сообщения сопоставляются с использованием заголовков Message-Id и Received. Это полезно проверить заранее на выбранной паре серверов. Менять правила сопоставления между прогонами без проверки я не предлагаю.
В приёмку пилота включаю дерево папок, сообщения за разные периоды, вложения, даты и поддерживаемые отметки состояния. По документации imapsync сохранение флагов зависит от возможностей принимающего сервера, поэтому обещания сохранить все метки в неизменном виде не даю. Совпадение общего числа гигабайт тоже не заменяет проверку: разные серверы могут сообщать разные размеры одних и тех же писем. Я сверяю журналы, согласованный набор папок и сообщений, разбираю пропуски. Затем владелец ящика проверяет свои рабочие примеры. Подробную сверку после переноса почты нужно заложить в план до старта.
Отдельно проверяю данные, которые не входили в копирование писем: контакты, календари, правила, подписи, права общих ящиков и состав рассылок. Для каждого исключения в реестре должно быть действие или явно согласованное ограничение. Сотруднику нужна памятка с новым подключением и способом сообщить о проблеме, а ответственному — список контрольных сценариев. В нём я оставляю отправку и получение снаружи, работу общего адреса и поступление заявки в приложение. Галочка «пилот завершён» появляется после этих проверок, а не после исчезновения окна программы.
На выходе я передаю согласованный реестр, перечень копий, результаты пилота и список нерешённых вопросов. В плане следующих работ отмечаю порядок копирования, переключение доставки, проверку новых писем и критерии завершения перехода. Дату отключения старой площадки согласовываю отдельно после проверки результата. До этого никто не должен считать оставшуюся там историю ненужной. Такой комплект даёт основание оценить трудоёмкость и назначить ответственных за запуск. Инвентаризация закончена, когда каждую строку можно выполнить и проверить. Таблица без решений — всего лишь красиво оформленная неизвестность.
Частые вопросы
Нужно ли останавливать почту для инвентаризации?
Для сбора списка и статистики я обычно не останавливаю работу. Тестовое копирование и нагрузку на сервис планирую отдельно, с учётом ограничений площадок.
Алиас нужно считать отдельным ящиком?
Нет. Алиас — дополнительный адрес существующего ящика. Я учитываю его настройку отдельно, а объём того же хранилища повторно не прибавляю.
Перенесёт ли IMAP контакты и календарь?
Обычное копирование писем через IMAP, включая imapsync, этого не делает. Я выделяю контакты и календари в отдельные задачи с собственным способом переноса и проверкой.
Можно удалить почту бывших сотрудников до переезда?
Я делаю это только по согласованному решению после проверки нужных данных и копии. Отсутствие входов в ящик не доказывает, что его переписка больше не нужна.
Почему недостаточно входа в почту через браузер?
Инструмент копирования использует отдельное подключение. Для Яндекса я проверяю доступ по IMAP и выбранный способ авторизации; при входе по паролю нужен пароль приложения.
Можно ли определить срок по количеству сотрудников?
Только очень приблизительно. Я сначала считаю ящики, сообщения и объёмы, проверяю ограничения, затем измеряю пилот и согласую время на перенос и приёмку.
Источники
- Яндекс Почта для бизнеса: другие почтовые программы — Проверены раздел «Почтовые программы», разрешение IMAP, опция «Пароли приложений и OAuth-токены», пароль приложения в Яндекс ID, полный адрес в логине и imap.yandex.ru:993 с защищённым соединением. https://yandex.ru/support/yandex-360/business/mail/ru/mail-clients/others
- Яндекс 360: адреса-синонимы — Алиас является дополнительным адресом существующего ящика; получение и отправка с алиаса требуют раздельной проверки. https://yandex.ru/support/yandex-360/business/admin/ru/mail/mailbox-management/aliases
- Яндекс ID: данные аккаунта — Документирован заказ архива отдельного аккаунта через «Данные на сервисах». Обещание одной кнопкой сохранить все корпоративные ящики и настройки не подтверждено. https://yandex.ru/support/id/ru/personal-data
- imapsync: сайт разработчика, руководство и флаги — Проверены отсутствие переноса контактов и календарей, повторные прогоны, сопоставление по Message-Id и Received, отсутствие удаления по умолчанию и ограничения сохранения флагов на принимающем сервере. Общие размеры на двух серверах могут различаться. https://imapsync.lamiral.info/ ; https://imapsync.lamiral.info/README ; https://imapsync.lamiral.info/FAQ.d/FAQ.Flags.txt
- imapsync: расход памяти — Расход памяти может быть связан с крупными сообщениями и обработкой больших папок; линейная зависимость от общего объёма ящика не заявлена. https://imapsync.lamiral.info/FAQ.d/FAQ.Memory.txt
- Битрикс24: способы подключения почтовых ящиков — Первичная документация почтовой интеграции CRM: разные способы авторизации, отдельные параметры IMAP и SMTP, настройка исходящей отправки. https://helpdesk.bitrix24.ru/open/19083990/



