Kodėl migracijos kontrolinis sąrašas yra būtinas
El. pašto migracija yra viena rizikingiausių IT operacijų, kurias organizacija gali atlikti. Perkeliami metų profesinės komunikacijos tarp platformų, ir vienas praleidimas gali sugadinti visų pašto dėžučių metaduomenis. Dažniausia auka? El. laiškų datos. Po migracijos kiekvienas el. laiškas rizikuoja rodyti migracijos datą vietoj originalios išsiuntimo ar gavimo datos.
Šis kontrolinis sąrašas apima kiekvieną migracijos proceso fazę. Sekite šiuos žingsnius, kad sumažintumėte datų sugadinimo ir kitų metaduomenų problemų riziką. O jei migracija jau atlikta ir datų problemos pasirodė - skaitykite toliau.
1 fazė: planavimas prieš migraciją
Inventorizuokite pašto dėžutes
Prieš liečiant bet kokį migracijos įrankį, dokumentuokite kiekvieną migruojamą dėžutę. Užfiksuokite bendrą dėžučių skaičių, apytikrį el. laiškų skaičių kiekvienoje, seniausių el. laiškų datų intervalą ir bendrimas dėžutes ar paskirstymo grupes. Ši inventorizacija nulemia, kokį migracijos įrankį naudoti, kiek užtruks migracija ir kokia kaina taikoma galimam taisymui po migracijos.
Pasirinkite tinkamą migracijos įrankį
Ne visi migracijos įrankiai tvarko datas vienodai. Išsiaiškinkite, kaip kiekvienas įrankis tvarko IMAP INTERNALDATE išsaugojimą ir ar jis prideda „Received" antraštes per APPEND procesą. Populiarūs įrankiai apima BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO ir vietinį „Exchange" administravimo centro importą. Kiekvienas iš šių įrankių gali sukelti datų problemas, nes pats IMAP protokolas reikalauja, kad paskirties serveris pridėtų „Received" antraštę per įterpimą. Tačiau kai kurie įrankiai geriau išsaugo INTERNALDATE nei kiti. Norėdami geriau suprasti INTERNALDATE veikimą, žr. IMAP INTERNALDATE: kodėl datos sugenda.
Viską atsargiai nukopijuokite
Sukurkite pilną kiekvienos pašto dėžutės atsarginę kopiją prieš migraciją. Ši kopija tarnauja ir kaip apsauginis tinklas, ir kaip atskaitos taškas datoms patikrinti vėliau. „Google Workspace" naudokite „Google Takeout" ar trečiosios šalies atsarginių kopijų įrankį. „Microsoft 365" naudokite „Exchange Online" atsarginę kopiją ar PST eksportą. IMAP serveriams naudokite imapsync vietinei kopijai sukurti.
Saugokite atsargines kopijas visiškai atskiroje vietoje nuo šaltinio ir paskirties serverių.
Dokumentuokite originalias datas
Pasirinkite 10-20 el. laiškų iš kiekvienos dėžutės, paskirstytų per skirtingus datų intervalus (seniausius, naujausius ir kelis tarpinius). Užfiksuokite kiekvieno el. laiško „Gavimo" datą, „Išsiuntimo" datą ir neapdorotas antraštes. Šie etaloniniai el. laiškai tampa jūsų patikrinimo baze po migracijos. Padarykite ekrano nuotrauką pašto dėžutės, surūšiuotos pagal datą, kad vizualiai dokumentuotumėte originalią chronologinę tvarką.
2 fazė: testinė migracija
Pirmiausia migruokite testinę pašto dėžutę
Niekada nepaleidinėkite visos migracijos be išankstinio testavimo.
Sukurkite testinę pašto dėžutę su reprezentatyviu el. laiškų pavyzdžiu (mažiausiai 100, apimant kelerius metus). Paleiskite migraciją tik šiai vienai dėžutei ir nuodugniai išnagrinėkite rezultatus prieš tęsdami. Šis testas atskleidžia datų problemas, kodavimo klaidas, priedų tvarkymo defektus ir aplankų struktūros neatitikimus prieš jiems paveikiant gamybines dėžutes.
Patikrinkite datas testinėje pašto dėžutėje
Migruoję testinę dėžutę, nedelsiant patikrinkite datas. Atidarykite dėžutę el. pašto kliente, kurį galutiniai naudotojai iš tikrųjų naudos („Outlook", „Apple Mail", „Thunderbird" ar žiniatinklio paštas). Palyginkite rodomas datas su 1 fazėje dokumentuotais etaloniniais el. laiškais. Patikrinkite tiek „Gavimo", tiek „Išsiuntimo" datas. Atidarykite kelių el. laiškų neapdorotas antraštes ir ieškokite naujai pridėtų „Received" antraščių su migracijos laiko žyma.
Jei datos klaidingos testinėje dėžutėje, jos bus klaidingos visose dėžutėse. Sustabdykite viską ir išspręskite problemą prieš tęsdami pilną migraciją.
Testuokite su keliais el. pašto klientais
Skirtingi el. pašto klientai rodo datas skirtingai. „Gmail" žiniatinklio sąsaja gali rodyti teisingas datas (naudoja „Date" antraštę), tuo tarpu „Outlook" rodo migracijos datą (teikia pirmenybę „Received" antraštei). Testuokite su kiekvienu klientu, kurį organizacijos naudotojai naudoja, ypač darbalaukio „Outlook", „Outlook" žiniatinklyje, „Apple Mail", „Thunderbird" ir mobiliomis el. pašto programomis.
3 fazė: migracijos vykdymas
Migracijos įrankio konfigūravimas
Konfigūruokite migracijos įrankį INTERNALDATE išsaugojimui, kiek įmanoma. imapsync atveju naudokite atitinkamas vėliavėles INTERNALDATE nustatymui paskirties vietoje. BitTitan MigrationWiz atveju patikrinkite išplėstinius nustatymus dėl datų tvarkymo parinkčių. Šie nustatymai nevisiškai užkirs kelią „Received" antraštės problemai, bet kai kurių klientų atveju sumažins datų problemų sunkumą. Dokumentuokite kiekvieną naudotą konfigūracijos nustatymą, kad galėtumėte atkurti migraciją, jei reikės.
Migruokite paketais
Nemigruokite visų dėžučių vienu metu. Migruokite paketais po 10-20 dėžučių, tikrindami datas po kiekvieno paketo. Jei pakete pasirodo datų problemos, jas aptiksite prieš paveikiant visą organizaciją. Beje, paketinė migracija taip pat sumažina apkrovą šaltinio ir paskirties serveriams, mažindama laiko limitų ar prisijungimo klaidų, galinčių sukelti dalines migracijas, riziką.
Stebėkite eigą
Sekite kiekvienos dėžutės migracijos eigą. Fiksuokite pradžios laiką, pabaigos laiką, migruotų el. laiškų skaičių ir galimas klaidas. Migracijos įrankiai paprastai pateikia žurnalus - saugokite juos kiekvienai dėžutei. Jei datų problemos aptinkamos vėliau, žurnalai padeda identifikuoti tiksliai, kuris migracijos paketas ir kokie nustatymai buvo naudoti.
4 fazė: patikrinimas po migracijos
Nedelsiant patikrinkite datas
Patikrinkite el. laiškų datas per 24 valandas po migracijos. Kiekvienam paketui atidarykite 5-10 dėžučių ir palyginkite datas su etaloniniais duomenimis prieš migraciją. Jei datos klaidingos, dokumentuokite problemos mastą (kiek dėžučių paveikta, kiek el. laiškų kiekvienoje), kol informacija šviežia.
Patikrinkite visų tipų aplankus
Datų problemos gali paveikti kai kuriuos aplankus skirtingai. Patikrinkite datas Gautuosiuose, Išsiųstuosiuose, Juodraščiuose ir bet kuriuose individualiuose aplankuose ar etiketėse. Kai kurie migracijos įrankiai apdoroja aplankus nuosekliai, ir klaidos viename aplanke nebūtinai rodo klaidas kituose.
Patikrinkite paiešką ir rūšiavimą
Atidarykite migruotą pašto dėžutę, surūšiuokite pagal datą ir patvirtinkite, kad chronologinė tvarka atitinka originalą. Ieškokite el. laiškų pagal datų intervalą ir patikrinkite, ar rezultatai tikslūs. Testuokite automatizuotas taisykles ar filtrus, priklausančius nuo gavimo datų. Jei organizacija naudoja atitikties ar eDiscovery įrankius, patikrinkite, ar datų pagrindu vykdomos užklausos grąžina teisingus rezultatus.
Dažnos klaidos, sukeliančios datų problemas
Testinės migracijos praleidimas
Dažniausia klaida - migruoti visas dėžutes be išankstinio testavimo. Kai datų problemos aptinkamos, visos dėžutės jau paveiktos ir šaltinio serveris galbūt jau išjungtas. 30 minučių testinė migracija gali išvengti savaičių taisymo. Kodėl to vengti?
„Received" antraščių pridėjimų ignoravimas
Administratoriai dažnai susitelkia ties INTERNALDATE išsaugojimu ir pamiršta „Received" antraštės problemą. Net kai INTERNALDATE teisingai nustatyta, migracijos „Received" antraštė priverčia „Outlook" ir kitus klientus rodyti klaidingą datą. Tai dažniausia skundų po migracijos priežastis. Skaitykite kodėl el. laiškai rodo klaidingas datas po migracijos techniniam paaiškinimui.
Per ankstyvas šaltinio serverio išjungimas
Jei datų problemos aptinkamos po šaltinio serverio išjungimo, pakartotinės migracijos galimybė dingsta. Palikite šaltinio serverį pasiekiamą (bent skaitymo režimu) mažiausiai 30 dienų po migracijos. Tai suteikia atsarginį variantą, jei rimtų problemų pasirodys vėliau.
Ką daryti, jei datos jau sugadintos
Jei migracija jau atlikta ir datos neteisingos, problema yra pataisoma. Originali „Date" antraštė išsaugota kiekviename el. laiške, o tai reiškia, kad teisinga datos informacija vis dar egzistuoja. El. laiškų datos gali būti pataisytos po migracijos, net praėjus mėnesiams ar metams.
Redate.io nuosavybinis taisymo variklis prisijungia prie pašto dėžutės ir ieško el. 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, daugiadales struktūras ir ne ASCII antraštes) ir atlieka vientisumo patikrą kiekvienam pataisytam el. laiškui. Analizė nemokama ir parodo tiksliai, kiek el. laiškų paveikta. Originalai saugomi matomame atsarginės kopijos aplanke 30 dienų.
Bandyti šį taisymą rankiniu būdu ar individualiu scenarijumi yra viliojanti, bet rizikinga. Specialūs atvejai kaip PGP šifruoti pranešimai, sugadintos MIME ribos, įdėtos daugiadlės struktūros ir Content-Transfer-Encoding neatitikimai gali tyliai sugadinti el. laiškus, to net nesuvokiant, kol nebūna per vėlu. O kaip patikrinti, kad 10 000 pataisytų el. laiškų visi yra nepažeisti?
Pasirengę patikrinti, ar jūsų pašto dėžutė turi datų problemų? Paleiskite nemokamą analizę su Redate.io - jokio mokėjimo nereikia, kad sužinotumėte, kiek el. laiškų paveikta.