El. pašto migracijos kontrolinis sąrašas: kaip išvengti datų problemų

Kodėl migracijos kontrolinis sąrašas yra būtinas

El. pašto migracija yra viena rizikingiausių IT operacijų, kurią gali atlikti bet kuri organizacija. Perkeliate kelerių metų profesionalią korespondenciją tarp platformų, ir vienas pražiūrėtas dalykas gali sugadinti metaduomenis visose pašto dėžutėse. Dažniausia auka? El. laiškų datos. Po migracijos kiekvienas laiškas gali rodyti migracijos datą vietoj originalios išsiuntimo ar gavimo datos.

Šis kontrolinis sąrašas apima kiekvieną migracijos proceso etapą. Laikykitės šių žingsnių, kad sumažintumėte datų sugadinimo ir kitų metaduomenų problemų riziką. O jei migracija jau baigta ir datų problemos atsirado, skaitykite toliau.

1 etapas: planavimas prieš migraciją

Inventorizuokite pašto dėžutes

Prieš paleidžiant bet kokį migracijos įrankį, dokumentuokite kiekvieną perkeltiną dėžutę. Užfiksuokite bendrą dėžučių skaičių, apytikslį laiškų kiekį kiekvienoje dėžutėje, seniausių laiškų datų intervalą ir bendrai naudojamas dėžutes ar paskirstymo grupes. Šis inventorius lemia, kurį migracijos įrankį pasirinkti, kiek laiko truks migracija ir kokia kainodara gali būti taikoma galimiems koregavimams po migracijos.

Pasirinkite tinkamą migracijos įrankį

Ne visi migracijos įrankiai vienodai tvarko datas. Išsiaiškinkite, kaip kiekvienas įrankis valdo IMAP INTERNALDATE išsaugojimą ir ar jis prideda „Received" antraštės įrašus APPEND proceso metu. Populiarūs įrankiai apima BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO ir Exchange administravimo centro vietinį importą. Kiekvienas šių įrankių gali sukelti datų problemų, nes pats IMAP protokolas reikalauja, kad paskirties serveris pridėtų „Received" antraštę įterpimo metu. Tačiau kai kurie įrankiai geriau išsaugo INTERNALDATE nei kiti. Norėdami geriau suprasti INTERNALDATE veikimą, žr. IMAP INTERNALDATE: kodėl datos sugadinamos.

Sukurkite atsargines visų duomenų kopijas

Prieš migraciją sukurkite išsamią kiekvienos pašto dėžutės atsarginę kopiją. Ši kopija yra tiek saugumo tinklas, tiek atskaitos taškas datų patikrinimui po migracijos. „Google Workspace" atveju naudokite „Google Takeout" arba trečiųjų šalių atsarginio kopijavimo įrankį. „Microsoft 365" atveju naudokite „Exchange Online" atsarginę kopiją arba eksportą į PST. IMAP serveriams naudokite imapsync vietinei kopijai sukurti.

Saugokite atsargines kopijas vietoje, visiškai atskiroje nuo šaltinio ir paskirties serverių.

Dokumentuokite originalias datas

Iš kiekvienos dėžutės pasirinkite 10-20 laiškų, apimančių skirtingus datų intervalus (seniausius, naujausius ir kelis tarpinius). Užfiksuokite „Gavimo" datą, „Išsiuntimo" datą ir kiekvieno laiško žaliąsias antraštės. Šie etaloniniai laiškai taps jūsų patikrinimo baze po migracijos. Padarykite ekrano kopijas dėžutės, surikiuotos pagal datą, kad vizualiai dokumentuotumėte originalią chronologinę tvarką.

2 etapas: bandomoji migracija

Pirmiausia migruokite bandomąją dėžutę

Niekada nepradėkite visos migracijos be išankstinio testavimo.

Sukurkite bandomąją dėžutę su reprezentatyviu laiškų pavyzdžiu (bent 100 laiškų, apimančių kelis metus). Paleiskite migraciją tik šiai dėžutei ir nuodugniai išnagrinėkite rezultatus prieš tęsdami. Šis testas atskleidžia datų problemas, kodavimo klaidas, priedų tvarkymo triktis ir aplankų struktūros neatitikimus dar prieš tai, kai jos paveikia gamybos dėžutes.

Patikrinkite datas bandomojoje dėžutėje

Perkėlę bandomąją dėžutę, nedelsdami patikrinkite datas. Atidarykite dėžutę el. pašto kliente, kurį iš tikrųjų naudos galutiniai vartotojai (Outlook, Apple Mail, Thunderbird ar žiniatinklio sąsaja). Palyginkite rodomas datas su etaloniniais laiškais, dokumentuotais 1 etape. Patikrinkite tiek „Gavimo", tiek „Išsiuntimo" datas. Atidarykite kelių laiškų žaliąsias antraštės ir ieškokite naujai pridėtų „Received" antraščių su migracijos laiko žyme.

Jei bandomojoje dėžutėje datos klaidingos, jos bus klaidingos visose dėžutėse. Sustabdykite viską ir išspręskite problemą prieš tęsdami visą migraciją.

Testuokite su keliais el. pašto klientais

Skirtingi el. pašto klientai rodo datas skirtingai. Gmail žiniatinklio sąsaja gali rodyti teisingas datas (ji naudoja „Date" antraštę), tuo tarpu Outlook rodo migracijos datą (jis teikia pirmenybę „Received" antraštei). Testuokite su kiekvienu klientu, kurį naudoja organizacijos vartotojai, įskaitant Outlook darbalaukio versiją, Outlook žiniatinklyje, Apple Mail, Thunderbird ir visas mobilias el. pašto programas.

3 etapas: migracijos vykdymas

Migracijos įrankio konfigūracija

Sukonfigūruokite migracijos įrankį taip, kad kiek įmanoma geriau išsaugotų INTERNALDATE. Imapsync atveju naudokite tinkamas žymes INTERNALDATE nustatymui paskirties serveryje. BitTitan MigrationWiz atveju patikrinkite išplėstinius nustatymus, skirtus datų tvarkymo parametrams. Šie nustatymai neužkirs kelio „Received" antraštės problemoms, tačiau sumažins datų problemų rimtumą kai kuriuose klientuose. Dokumentuokite kiekvieną naudotą konfigūracijos parametrą, kad prireikus galėtumėte atkartoti migraciją.

Migruokite partijomis

Nemigruokite visų dėžučių vienu metu. Migruokite partijomis po 10-20 dėžučių, po kiekvienos partijos patikrindami datas. Jei partija rodo datų problemas, jas aptiksite dar prieš tai, kai visa organizacija bus paveikta. Beje, migracija partijomis taip pat sumažina apkrovą šaltinio ir paskirties serveriams, mažindama skirtojo laiko pabaigos ar ryšio klaidų, galinčių sukelti dalines migrацijas, riziką.

Stebėkite eigą

Sekite migracijos eigą kiekvienai dėžutei. Užfiksuokite pradžios laiką, pabaigos laiką, perkeltų laiškų skaičių ir galimas klaidas. Migracijos įrankiai paprastai teikia žurnalus - išsaugokite juos kiekvienai dėžutei. Jei datų problemos bus aptiktos vėliau, žurnalai padės tiksliai nustatyti, kuri migracijos partija ir kokie parametrai buvo naudoti.

4 etapas: patikrinimas po migracijos

Nedelsdami patikrinkite datas

Patikrinkite el. laiškų datas per 24 valandas nuo migracijos. Kiekvienai partijai atidarykite 5-10 dėžučių ir palyginkite datas su ikimigracijos etalonais. Jei datos klaidingos, dokumentuokite problemos mastą (kiek paveiktų dėžučių, kiek laiškų kiekvienoje dėžutėje), kol informacija dar šviežia.

Patikrinkite visų tipų aplankus

Datų problemos gali skirtingai paveikti skirtingus aplankus. Patikrinkite datas Gautuosiuose, Išsiųstuose, Juodraščiuose ir visuose pasirinktiniuose aplankuose ar žymėse. Kai kurie migracijos įrankiai aplankus tvarko nuosekliai, ir klaidos viename aplanke nebūtinai rodo klaidas kituose.

Patikrinkite paiešką ir rikiavimą

Atidarykite perkeltą dėžutę, surikiuokite pagal datą ir patvirtinkite, kad chronologinė tvarka atitinka originalą. Ieškokite laiškų pagal datų intervalą ir patikrinkite, ar rezultatai tikslūs. Išbandykite visas automatizuotas taisykles ar filtrus, kurie priklauso nuo gavimo datų. Jei organizacija naudoja atitikties ar eDiscovery įrankius, patikrinkite, ar datų pagrindu atliekamos užklausos grąžina teisingus rezultatus.

Dažniausios klaidos, sukeliančios datų problemas

Bandomosios migracijos praleidimas

Dažniausia klaida - migruoti visas dėžutes be išankstinio testavimo. Kai datų problemos aptinkamos, visos dėžutės jau paveiktos, o šaltinio serveris galbūt jau išjungtas. 30 minučių bandomoji migracija gali išgelbėti nuo savaičių taisomojo darbo. Kodėl to nedaryti?

„Received" antraščių papildymų ignoravimas

Administratoriai dažnai koncentruojasi į INTERNALDATE išsaugojimą ir nepaiso „Received" antraštės problemos. Net kai INTERNALDATE teisingai nustatytas, migracijos „Received" antraštė lemia tai, kad Outlook ir kiti klientai rodo neteisingą datą. Tai dažniausia pomigracinio nepasitenkinimo priežastis. Skaitykite kodėl el. laiškai rodo klaidingas datas po migracijos - čia rasite išsamų techninį paaiškinimą.

Per ankstyvas šaltinio serverio išjungimas

Jei datų problemos aptinkamos po šaltinio serverio išjungimo, pakartotinės migracijos galimybė išnyksta. Palikite šaltinio serverį prieinamą (bent tik skaitymui) ne mažiau kaip 30 dienų po migracijos. Tai suteikia atsarginę išeitį, jei vėliau iškiltų rimtų problemų.

Ką daryti, jei datos jau klaidingos

Jei migracija jau atlikta ir datos neteisingos, problema yra ištaisoma. Originali „Date" antraštė išsaugoma kiekviename laiške, o tai reiškia, kad teisinga datos informacija visada egzistuoja. El. laiškų datas galima pataisyti po migracijos, net praėjus mėnesiams ar metams.

Redate.io patentuotas taisymo variklis prisijungia prie dėžutės ir ieško laiškų su sugadintais datų metaduomenimis. Daugiapakopis analizės konvejeris identifikuoja migracijos parašus, taiko tikslines korekcijas išsaugodamas pranešimų vientisumą (įskaitant S/MIME parašus, multipart struktūras ir ne-ASCII antraštės), ir atlieka vientisumo patikrinimą kiekvienam pataisytam laiškui. Analizė yra nemokama ir parodo tiksliai, kiek laiškų paveikta. Originalai saugomi matomame atsarginės kopijos aplanke 30 dienų.

Mėginti tokį taisymą rankiniu būdu ar su pasirinktiniais skriptais vilioja, tačiau tai rizikinga. Ypatingi atvejai, tokie kaip PGP užšifruoti pranešimai, sugadintos MIME ribos, įdėtos multipart struktūros ir Content-Transfer-Encoding nesutapimai, gali tyliai sugadinti laiškus - ir to nepastebėsite, kol nebus per vėlu. Ir kaip patikrinti, kad visi 10 000 pataisytų laiškų yra sveiki?

Pasiruošę patikrinti, ar jūsų dėžutėje yra datų problemų? Paleiskite nemokamą analizę su Redate.io - jokio mokėjimo nereikia, kad pamatytumėte, kiek laiškų paveikta.