Veeam/Datto: el. laiškai datuoti atkūrimo, ne siuntimo laiku

Kitą rytą po atkūrimo pradeda plūsti užklausos

Ką tik baigėte pašto dėžutės atkūrimą naudodami Veeam Backup for Microsoft 365. Operacija pavyko, duomenys yra, aplankai nepažeisti. Ir tada, pirmadienio rytą, vartotojas rašo: "Visi mano el. laiškai turi šiandienos datą. Negaliu nieko rasti."

Problema ne ta, kad el. laiškai dingo. Jie yra. Tačiau rodoma data atitinka tikslų atkūrimo momentą, o ne datą, kada jie buvo išsiųsti ar gauti. 2021 m. sausio mėnesio el. laiškas atrodo lyg gautas vakar naktį 23:47. Pokalbių gija sulaužyta. Chronologija neįskaitoma.

Šis elgesys pasireiškia naudojant Veeam Backup for Microsoft 365, Datto SaaS Protection, Synology Active Backup for Microsoft 365 ir AvePoint Cloud Backup, be kitų. Kiekvienas veikia šiek tiek skirtingai, bet rezultatas identiškas.

Kas nutinka techniniu požiūriu

Norint suprasti, iš kur atsiranda neteisinga data, reikia pažvelgti, kaip šie įrankiai el. laiškus vėl įterpia į Exchange Online ar Google Workspace dėžutę.

Kai atsarginių kopijų įrankis atkuria pranešimą, jis negali tiesiog "grąžinti" el. laiško taip, kaip perkeltumėte failą vietiniame diske. Jis įrašo naują pranešimo kopiją į dėžutę per IMAP arba per teikėjo API (Microsoft pusėje - EWS arba Microsoft Graph, Google pusėje - Gmail API). Ir kartu su šia kopija jis turi nurodyti dėžutei, kokią datą pranešimas turi.

Ir čia prasideda problema. (Beje, jei kada nors skaitėte neapdorotus atkurto el. laiško antraštes, tikriausiai matėte keliolika Received: eilučių, kol pasiekėte naudingą turinį.)

IMAP APPEND ir Received: antraštė

IMAP protokole yra komanda APPEND. Ji skirta pranešimui įterpti į pašto dėžutę. Tai tiksliai tai, ką naudoja atkūrimo įrankis: paima išsaugotą pranešimą ir jį įterpia į tikslinę dėžutę per IMAP APPEND.

Ši komanda leidžia įrankiui perduoti datą kartu su pranešimu. Jei įrankis perduoda pradinę pranešimo datą, dėžutė ją išsaugo: taip veikia Microsoft 365, Outlook.com ir Gmail. Jei jis nieko neperduoda arba perduoda atkūrimo datą, el. laiškas dėžutėje atsiduria pagal atkūrimo dieną. Kai kurie pranešimo įrašymo būdai papildomai prideda vieną eilutę viršuje: Received: antraštę su kopijavimo dienos data. Tiksliai taip veikia paties Gmail importo API.

Ši papildoma eilutė atrodo maždaug taip:

Received: by gmailapi.google.com
  with HTTPREST; Mon, 14 Apr 2025 23:47:12 +0000

Rezultatas: pradinis el. laiškas viduje lieka nepažeistas su pradiniu Date: antraštės lauku (tarkime, "3 Jan 2021 09:15:00"). Tačiau nauja Received: antraštė, datuota atkūrimo momentu, buvo priklijuota pačiame viršuje.

Kaip Outlook ir Gmail skaito datą

El. pašto klientai, tokie kaip Outlook ar Gmail žiniatinklio sąsaja, ne visada skaito Date: antraštę spręsdami, kokią datą rodyti pranešimų sąraše. Daugelis naudoja IMAP protokolo INTERNALDATE, tai yra datą, kada pranešimas buvo įtrauktas į dėžutę, arba naujausią Received: antraštę.

Outlook, skirtas Windows, ypač nuo 2023 m. pabaigos atnaujinimo, yra ypač jautrus šiam reiškiniui. Kai jis mato naują Received: antraštę grandinės viršuje, ją naudoja kaip rodymui skirtą datą. Pradinis Date: laukas lieka pranešimo detalėse, matomas tik atidarius el. laiško ypatybes.

Galutinis vartotojas mato pranešimų sąrašą, kuriame visi laiškai datuoti atkūrimo nakties metu. Jo trejų metų istorija lyg sulipo į vieną naktį.

Ši problema skiriasi nuo migracijos

Reikia atskirti nuo klasikinės klaidingų datų problemos po IMAP migracijos. Migracijos atveju įrankis perkelia el. laiškus iš serverio A į serverį B, ir tai, ar kiekvienas el. laiškas išsaugo savo datą, priklauso nuo to, ką įrankis nurodo serveriui B, jį įrašydamas. Mechanizmas tas pats, bet kontekstas skirtingas.

Čia kalbame apie atkūrimą iš atsarginės kopijos. El. laiškai niekada nepaliko organizacijos, tiesiog buvo saugiai laikomi kažkur (Azure Blob Storage, AWS S3, Datto prietaisas...) ir vėl įterpti. Vartotojas to tikisi dar mažiau: jam tai „jo" el. laiškai, kurie grįžta, ne importuoti pranešimai.

Bet techniniu požiūriu mechanizmas identiškas. Reinjektavimas, kuris neperduoda pradinės datos, sukuria tuos pačius artefaktus. Ir taisymas taip pat eina ta pačia logika.

Kaip kiekvienas įrankis tvarko (arba netvarko) INTERNALDATE

Ne visi įrankiai elgiasi visiškai vienodai, ir čia viskas tampa įdomu.

Veeam Backup for Microsoft 365

Veeam naudoja EWS (Exchange Web Services) API atkūrimui į Exchange Online. EWS leidžia nurodyti pranešimo datą per DateTimeReceived lauką, tačiau ši reikšmė ne visada atsispindi IMAP lygio INTERNALDATE. Rezultatas: rikiavimo data Outlook gali neatitikti pradinės datos, ypač jei atkūrimas vykdomas į kitą dėžutę, o ne pradinę (granulinis atkūrimas į alternatyvią dėžutę).

Datto SaaS Protection

Datto atkuria per Microsoft Graph API arba IMAP, priklausomai nuo konfigūracijos. Abiem atvejais dėžutėje rodoma data priklauso nuo to, ar atkūrimas perduoda kiekvieno pranešimo pradinę datą. MSP, naudojantys Datto savo klientams, su šia problema susiduria gana reguliariai, ypač po išpirkos reikalaujančių programų (angl. ransomware) incidentų, kai skubiai atkuriami keli šimtai dėžučių vienu metu. Tai ne pats geriausias momentas atrasti, kad visos datos yra neteisingos.

AvePoint ir Synology Active Backup

AvePoint Cloud Backup ir Synology Active Backup for Microsoft 365 naudoja panašius mechanizmus. AvePoint savo žinių bazėje yra dokumentavęs šį elgesį (pranešimas atkuriamas su atkūrimo data kaip matoma gavimo data), tačiau nesiiūlo vietinio pataisymo. Synology Active Backup pateikia tą pačią problemą, dar sustiprinto to, kad atkūrimo sąsaja aiškiai neatskiria „pranešimo datos" nuo „atkūrimo datos".

Gera žinia: pradinė data vis dar yra

Tai, kas situaciją daro pataisomą, yra tai, kad pradinis pranešimo Date: laukas nebuvo pakeistas. Jis vis dar yra, nepažeistas, kiekvieno atkurto el. laiško viduje. Atkūrimas pakeitė datą, kurią užregistravo dėžutė, ir kartais viršuje papildomai pridėjo Received: eilutę, bet nepalietė paties pranešimo turinio.

Tai MIME formato (RFC 2822) savybė: pranešimas yra nekintamas savo vidinėje struktūroje. Received: antraštės kaupiasi viršuje kaip sluoksniai, bet pradinės informacijos apačioje lieka nepažeistos.

Taigi ne, informacijos nepraradote. Ji tiesiog paslėpta po reinjektavimo artefaktu.

Kodėl pakartotinis atkūrimas nėra sprendimas

Pirmoji mintis, kuri ateina į galvą: ištrinti atkurtus el. laiškus ir paleisti atkūrimą iš naujo tikintis, kad šį kartą datos bus teisingos. Tai bloga idėja, ir štai kodėl.

Pirma, atkūrimo įrankiai antro karto elgsis lygiai taip pat. Tas pats įrankis, tie patys nustatymai: el. laiškai bus įrašyti tuo pačiu būdu, be pradinės datos. Gausite tiksliai tą patį rezultatą.

Antra, pakartotinis atkūrimas gamybinėse dėžutėse reikalauja laiko, pralaidumo ir kelia riziką. Su 50 dėžučių po 20 000 pranešimų kiekvienoje, kalbame apie kelių valandų operaciją, kuri monopolizuoja API ir gali suaktyvinti greičio ribojimą iš Microsoft ar Google pusės (tas garsus 429 Too Many Requests ankstyvo ryto 2 val. paketo metu).

Trumpai tariant. Atkūrimas pavyko. Duomenys yra. Tai, ką reikia pataisyti, yra datų artefaktas, ne pats atkūrimas.

Taisymas rankomis: konkretus pavojus

Suprasti problemą yra vienas dalykas. Pataisyti ją 80 000 el. laiškų neprarandant nė vieno - tai visai kas kita.

Python skriptas, kuris perranda IMAP pranešimus ir taiso datas, gali atrodyti įvykdomas. Ir su 50 bandomųjų el. laiškų jis veiks puikiai. Gamyboje viskas kitaip. Kraštutiniai atvejai kaupiasi: S/MIME pasirašyti el. laiškai (antraštės modifikavimas anuliuoja kriptografinį parašą), PGP užšifruoti pranešimai, multipart struktūros su nestandartinėmis MIME ribomis, RFC 2047 koduotos antraštės (ne ASCII), 40 MB priedai, kurie susprogdina skripto atmintį. O el. laiškai su keliais pridėtais Received: antraštėmis (jei atkūrimas buvo iš dalies paleistas pakartotinai, kas nutinka), reikalaujantys subtilesnės aptikimo logikos.

Tiksliau sakant, tikras pavojus nėra skriptas, kuris nulūžta: tai skriptas, kuris veikia be jokių matomo klaidos, bet sukuria sugadintus pranešimus. Sulaužytos pokalbių gijos. Dublikatai. Atsieti priedai. Kuriuos pastebėsite galbūt tik po kelių savaičių, kai vartotojas bandys surasti svarbų el. laišką.

Ir kaip patikrintumėte, kad kiekvienas pataisytas el. laiškas po modifikacijos tikrai yra nepažeistas? Naminis skriptas to paprastai nedaro.

Ką Redate.io daro kitaip

Redate.io analizuoja kiekvieno el. laiško antraščių grandinę, siekdamas identifikuoti reinjektavimo artefaktus, ar jie kilę iš Veeam atkūrimo, BitTitan migracijos ar rankinio importo. Redate.io sukurtas taisymo variklis neturi žinoti, kuris įrankis lėmė klaidą: jis ieško el. laiškų, kurių rodoma data neatitinka jų pradinės datos, todėl aptinkamas net ir anksčiau nežinomas įrankis.

Prieš taisydamas bet ką, Redate.io nuskaito visą dėžutę ir pateikia ataskaitą: kiek el. laiškų yra paveikta, kokia neteisinga data, kokia aptikta pradinė data. Šis nuskaitymas yra nemokamas. Matote problemos mastą prieš nuspręsdami veikti.

Kiekvienas el. laiškas tikrinamas individualiai po taisymo. Pradiniai laiškai saugomi matomame atsarginių kopijų aplanke tol, kol juos ištrinsite patys, todėl saugos tinklas visada išlieka.

Redate.io prisijungia prie kiekvieno vartotojo pašto dėžutės per jo paskyros prisijungimą, ir nė vienas el. laiškas nekeliauja per tarpinius serverius. Taisymas vyksta vietoje, dėžutėje, be eksporto ir reimporto.

MSP, valdantiems kelis vienu metu paveiktus klientus, žiūrėkite MSP skirtą puslapį: Redate.io leidžia apdoroti kelias dėžutes lygiagrečiai iš vienos sąsajos.

Kiti scenarijai, sukeliantys tą patį artefaktą

Atkūrimas iš atsarginių kopijų įrankio nėra vienintelis atvejis. Tas pats datų artefaktas atsiranda ir kitose situacijose:

• IMAP importas iš Exchange (archyvuotos dėžutės reinjektuotos į Exchange Online)
• Migracija į Exchange Online su įrankiais, naudojančiais IMAP tikslo pusėje
• Granulinis atkūrimas iš eksportuoto ir vėl importuoto PST (žiūrėkite straipsnį apie PST importą)
• Bendrų pašto dėžučių, atkurtų po incidento, datos (žiūrėkite bendrų dėžučių datų taisymą)

Visais šiais atvejais pagrindinė mechanika identiška: reinjektavimas, kuris neperduoda pradinės datos (kartais su nauja Received: antrašte viršuje), ir el. pašto klientas, kuris šią naują datą rodo kaip etaloninę.

El. laiškai yra, pradinė data išsaugota kiekviename pranešime. Paleiskite nemokamą nuskaitymą Redate.io ir pamatykite tiksliai, kiek el. laiškų paveikta jūsų dėžutėje, o tada nuspręskite, ar norite paleisti taisymą.