Чекліст міграції пошти: уникнути проблем з датами

Чому чекліст міграції такий важливий

Міграція пошти - одна з найризикованіших ІТ-операцій, які може провести організація. Ви переносите роки ділового листування між платформами, і одне упущення здатне зіпсувати метадані всіх поштових скриньок. Найчастіша жертва? Дати листів. Після міграції кожен лист ризикує показувати дату міграції замість оригінальної дати відправлення чи отримання.

Цей чекліст охоплює кожну фазу процесу міграції. Дотримуйтесь цих кроків, щоб мінімізувати ризик пошкодження дат та інших проблем з метаданими. А якщо міграція вже завершена і проблеми з датами вже з'явилися - читайте далі.

Фаза 1: планування до міграції

Інвентаризація поштових скриньок

Перш ніж торкатися будь-якого інструмента міграції, задокументуйте кожну скриньку, яку буде перенесено. Запишіть загальну кількість скриньок, приблизну кількість листів у кожній, діапазон дат найстаріших листів, а також спільні скриньки та групи розсилки. Ця інвентаризація визначає, який інструмент міграції використовувати, скільки часу займе процес і яка тарифікація застосовуватиметься для можливих виправлень після міграції.

Вибір правильного інструмента міграції

Не всі інструменти міграції однаково обробляють дати. Дізнайтеся, як кожен інструмент зберігає IMAP INTERNALDATE і чи додає він заголовки "Received" під час процесу APPEND. Популярні інструменти - BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO та нативний імпорт Центру адміністрування Exchange. Кожен із них може спричиняти проблеми з датами, оскільки сам протокол IMAP вимагає від цільового сервера додавати заголовок "Received" при вставці. Але деякі інструменти краще зберігають INTERNALDATE, ніж інші. Детальніше про роботу INTERNALDATE читайте у статті IMAP INTERNALDATE: чому дати ламаються.

Резервне копіювання всього

Створіть повну резервну копію кожної поштової скриньки до міграції. Ця копія слугує і страховою сіткою, і точкою відліку для перевірки дат після завершення. Для Google Workspace використовуйте Google Takeout або сторонній інструмент резервного копіювання. Для Microsoft 365 - резервне копіювання Exchange Online або експорт у PST. Для IMAP-серверів - imapsync для створення локальної копії.

Зберігайте резервні копії у місці, повністю відокремленому від вихідних і цільових серверів.

Документування оригінальних дат

Відберіть 10-20 листів з кожної скриньки, рівномірно розподілених за різними діапазонами дат (найстаріші, найновіші та кілька проміжних). Запишіть дату "Отримання", дату "Відправлення" та необроблені заголовки кожного листа. Ці референсні листи стають вашою базою для перевірки після міграції. Зробіть знімок екрана скриньки, відсортованої за датою, щоб візуально задокументувати оригінальний хронологічний порядок.

Фаза 2: тестова міграція

Спочатку перенесіть тестову скриньку

Ніколи не запускайте повну міграцію без попереднього тестування.

Створіть тестову скриньку з репрезентативною вибіркою листів (щонайменше 100, що охоплюють кілька років). Запустіть міграцію лише для цієї скриньки і детально вивчіть результати перед тим, як рухатися далі. Такий тест виявляє проблеми з датами, помилки кодування, баги обробки вкладень і розбіжності в структурі папок - ще до того, як вони вплинуть на виробничі скриньки.

Перевірка дат на тестовій скриньці

Після міграції тестової скриньки одразу перевірте дати. Відкрийте скриньку в поштовому клієнті, яким реально користуватимуться кінцеві користувачі (Outlook, Apple Mail, Thunderbird або веб-інтерфейс). Порівняйте відображувані дати з референсними листами, задокументованими у Фазі 1. Перевірте як дати "Отримання", так і дати "Відправлення". Відкрийте необроблені заголовки кількох листів і знайдіть нещодавно додані заголовки "Received" з міткою часу міграції.

Якщо дати неправильні на тестовій скриньці, вони будуть неправильними на всіх скриньках. Зупиніться і виправте проблему, перш ніж переходити до повної міграції.

Тестування з різними поштовими клієнтами

Різні поштові клієнти відображають дати по-різному. Веб-інтерфейс Gmail може показувати правильні дати (він використовує заголовок "Date"), тоді як Outlook показує дату міграції (він надає пріоритет заголовку "Received"). Тестуйте з кожним клієнтом, яким користуються співробітники організації, зокрема Outlook для ПК, Outlook в браузері, Apple Mail, Thunderbird та будь-якими мобільними поштовими застосунками.

Фаза 3: виконання міграції

Налаштування інструмента міграції

Налаштуйте інструмент міграції так, щоб якнайкраще зберегти INTERNALDATE. В imapsync використовуйте відповідні прапорці для встановлення INTERNALDATE на цільовому сервері. В BitTitan MigrationWiz перевірте розширені параметри щодо опцій управління датами. Ці налаштування не усунуть повністю проблеми з заголовком "Received", але зменшать серйозність проблем з датами в деяких клієнтах. Документуйте кожен використаний параметр конфігурації - це дозволить відтворити міграцію при потребі.

Міграція партіями

Не переносьте всі скриньки одночасно. Мігруйте партіями по 10-20 скриньок, перевіряючи дати після кожної партії. Якщо в якійсь партії виявляться проблеми з датами, Ви їх помітите до того, як постраждає вся організація. До речі, міграція партіями також знижує навантаження на вихідний і цільовий сервери, зменшуючи ризик таймаутів або помилок з'єднання, які можуть призвести до часткових міграцій.

Моніторинг прогресу

Відстежуйте хід міграції для кожної скриньки. Записуйте час початку, час завершення, кількість перенесених листів та всі виявлені помилки. Інструменти міграції зазвичай надають журнали - зберігайте їх для кожної скриньки. Якщо пізніше виявляться проблеми з датами, журнали допоможуть точно встановити, яка партія і які параметри використовувалися.

Фаза 4: перевірка після міграції

Негайна перевірка дат

Перевіряйте дати листів протягом 24 годин після міграції. Для кожної партії відкрийте 5-10 скриньок і порівняйте дати з еталонами до міграції. Якщо дати неправильні, задокументуйте масштаб проблеми (скільки скриньок постраждало, скільки листів у кожній) поки інформація ще свіжа.

Перевірка всіх типів папок

Проблеми з датами можуть по-різному зачіпати певні папки. Перевіряйте дати у Вхідних, Надісланих, Чернетках та будь-яких користувацьких папках або мітках. Деякі інструменти міграції обробляють папки послідовно, і помилки в одній папці не обов'язково означають помилки в інших.

Перевірка пошуку та сортування

Відкрийте перенесену скриньку, відсортуйте за датою і переконайтеся, що хронологічний порядок відповідає оригінальному. Шукайте листи за діапазоном дат і перевіряйте точність результатів. Протестуйте всі автоматизовані правила або фільтри, які залежать від дат отримання. Якщо організація використовує інструменти відповідності або eDiscovery, перевірте, що запити за датами повертають правильні результати.

Типові помилки, які спричиняють проблеми з датами

Пропуск тестової міграції

Найпоширеніша помилка - перенести всі скриньки без попереднього тестування. Коли проблеми з датами виявляються, постраждали вже всі скриньки, а вихідний сервер, можливо, вже вимкнено. Тридцятихвилинна тестова міграція здатна заощадити тижні усунення наслідків. Навіщо ж її пропускати?

Ігнорування додавання заголовків "Received"

Адміністратори часто зосереджуються на збереженні INTERNALDATE і не звертають уваги на проблему заголовка "Received". Навіть коли INTERNALDATE правильно встановлено, заголовок "Received" міграції змушує Outlook та інші клієнти показувати неправильну дату. Це найчастіше джерело скарг після міграції. Читайте чому листи показують неправильні дати після міграції для повного технічного пояснення.

Передчасне відключення вихідного сервера

Якщо проблеми з датами виявлено після зупинки вихідного сервера, варіант повторної міграції зникає. Залишайте вихідний сервер доступним (хоча б у режимі лише для читання) щонайменше 30 днів після міграції. Це забезпечить запасний варіант, якщо пізніше з'являться серйозні проблеми.

Що робити, якщо дати вже зламані

Якщо міграція вже виконана і дати неправильні - проблема виправна. Оригінальний заголовок "Date" збережено в кожному листі, тобто правильна інформація про дату завжди присутня. Дати листів можна виправити після міграції, навіть через місяці чи роки.

Власний двигун корекції Redate.io підключається до скриньки і шукає листи з пошкодженими метаданими дат. Багатоетапний конвеєр аналізу ідентифікує сигнатури міграції, застосовує цільові виправлення зі збереженням цілісності повідомлень (включаючи підписи S/MIME, структури multipart та заголовки не-ASCII) і виконує перевірку цілісності кожного виправленого листа. Аналіз безкоштовний і показує точно, скільки листів зачеплено. Оригінали зберігаються у видимій резервній папці протягом 30 днів.

Спробувати виконати таке виправлення вручну або за допомогою власного скрипта - спокусливо, але ризиковано. Граничні випадки на кшталт PGP-зашифрованих повідомлень, пошкоджених меж MIME, вкладених структур multipart і зміщень Content-Transfer-Encoding можуть непомітно пошкодити листи - і Ви не дізнаєтесь про це, поки не стане надто пізно. А як перевірити, що 10 000 виправлених листів усі цілі?

Готові перевірити, чи є у Вашій скриньці проблеми з датами? Запустіть безкоштовний аналіз з Redate.io - жодних платежів не потрібно, щоб побачити, скільки листів зачеплено.