Чому чеклист міграції є необхідним
Міграція електронної пошти - одна з найризикованіших ІТ-операцій, які може здійснити організація. Роки ділової кореспонденції переносяться між платформами, і один недогляд може пошкодити метадані всіх поштових скриньок. Найчастіша жертва? Дати листів. Після міграції кожний лист ризикує показувати дату міграції замість оригінальної дати відправлення або отримання.
Цей чеклист охоплює кожну фазу процесу міграції. Дотримуйтесь цих кроків, щоб мінімізувати ризик пошкодження дат та інших проблем з метаданими. А якщо міграція вже завершена і проблеми з датами виникли - читайте далі.
Фаза 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 Desktop, Outlook on the web, Apple Mail, Thunderbird та будь-яким мобільним поштовим застосунком.
Фаза 3: виконання міграції
Налаштування інструмента міграції
Налаштуйте інструмент міграції для максимально можливого збереження INTERNALDATE. В imapsync використовуйте відповідні прапорці для встановлення INTERNALDATE на сервері призначення. У BitTitan MigrationWiz перевірте розширені налаштування для опцій керування датами. Ці налаштування не повністю запобіжать проблемам з заголовком "Received", але зменшують серйозність проблем з датами в деяких клієнтах. Задокументуйте кожний використаний параметр конфігурації, щоб мати можливість відтворити міграцію за потреби.
Мігрувати порціями
Не мігруйте всі скриньки одночасно. Мігруйте порціями по 10-20 скриньок, перевіряючи дати після кожної порції. Якщо порція показує проблеми з датами, Ви виявляєте це до того, як уся організація буде уражена. До речі, міграція порціями також зменшує навантаження на сервери джерела та призначення, знижуючи ризик тайм-аутів або помилок з'єднання, що можуть спричинити неповні міграції.
Моніторити прогрес
Відстежуйте прогрес міграції для кожної скриньки. Фіксуйте час початку, час завершення, кількість перенесених листів та можливі помилки. Інструменти міграції зазвичай надають журнали - зберігайте їх для кожної скриньки. Якщо проблеми з датами виявляться пізніше, журнали допоможуть визначити, яка саме порція міграції та які налаштування були використані.
Фаза 4: перевірка після міграції
Негайно перевірити дати
Перевірте дати листів протягом 24 годин після міграції. Для кожної порції відкрийте 5-10 скриньок та порівняйте дати з контрольними даними, зафіксованими до міграції. Якщо дати хибні, задокументуйте масштаб проблеми (скільки скриньок уражено, скільки листів у кожній), поки інформація свіжа.
Перевірити всі типи тек
Проблеми з датами можуть по-різному зачіпати різні теки. Перевірте дати у Вхідних, Надісланих, Чернетках та будь-яких користувацьких теках чи мітках. Деякі інструменти міграції обробляють теки послідовно, і помилки в одній теці не обов'язково означають помилки в інших.
Перевірити пошук та сортування
Відкрийте перенесену скриньку, відсортуйте за датою та підтвердіть, що хронологічний порядок відповідає оригінальному. Знайдіть листи за діапазоном дат та перевірте точність результатів. Протестуйте будь-яке автоматизоване правило чи фільтр, що залежить від дат отримання. Якщо організація використовує інструменти відповідності або eDiscovery, перевірте, що запити за датами повертають коректні результати.
Типові помилки, що спричиняють проблеми з датами
Пропуск тестової міграції
Найпоширеніша помилка - мігрувати всі скриньки без попереднього тестування. Коли проблеми з датами виявляються, всі скриньки вже уражені, а сервер-джерело, можливо, вже вимкнено. Тестова міграція тривалістю 30 хвилин може запобігти тижням усунення наслідків. Навіщо від неї відмовлятися?
Ігнорування додавання заголовків "Received"
Адміністратори часто зосереджуються на збереженні INTERNALDATE і нехтують проблемою заголовка "Received". Навіть коли INTERNALDATE правильно встановлено, заголовок "Received" від міграції змушує Outlook та інші клієнти показувати хибну дату. Це найчастіше джерело скарг після міграції. Прочитайте статтю чому листи показують хибні дати після міграції для повного технічного пояснення.
Занадто раннє вимкнення сервера-джерела
Якщо проблеми з датами виявлено після зупинки сервера-джерела, можливість повторної міграції зникає. Тримайте сервер-джерело доступним (хоча б у режимі читання) протягом щонайменше 30 днів після міграції. Це забезпечує запасний варіант, якщо серйозні проблеми виникнуть пізніше.
Що робити, якщо дати вже зламані
Якщо міграція вже виконана і дати некоректні, проблему можна виправити. Оригінальний заголовок "Date" збережено у кожному листі, а отже, правильна інформація про дату все ще існує. Дати листів можна виправити після міграції, навіть через місяці чи роки.
Пропрієтарний рушій корекції Redate.io підключається до скриньки та шукає листи з пошкодженими метаданими дат. Багатоступеневий процес аналізу ідентифікує сигнатури міграції, застосовує точкові виправлення зі збереженням цілісності повідомлень (включаючи підписи S/MIME, структури multipart та заголовки non-ASCII) та виконує перевірку цілісності кожного виправленого листа. Аналіз безкоштовний і показує точну кількість уражених листів. Оригінали зберігаються у видимій теці резервного копіювання протягом 30 днів.
Спроба виправити це вручну або власним скриптом - спокуслива, але ризикована. Складні випадки, як-от повідомлення з шифруванням PGP, пошкоджені межі MIME, вкладені структури multipart та зсуви Content-Transfer-Encoding можуть непомітно пошкодити листи, і Ви дізнаєтесь про це лише коли буде запізно. А як перевірити, що 10 000 виправлених листів усі залишились цілими?
Готові перевірити, чи є у Вашій скриньці проблеми з датами? Запустіть безкоштовний аналіз з Redate.io - оплата не потрібна, щоб побачити кількість уражених листів.