Veeam/Datto: e-pošta datirana z obnovo, ne z pošiljanjem

Naslednji dan po obnovi začnejo prihajati prijave

Ravnokar ste dokončali obnovo poštnega predala z orodjem Veeam Backup for Microsoft 365. Operacija je potekla brez težav, podatki so na mestu, mape so nedotaknjene. In potem, v ponedeljek zjutraj, vam uporabnik napiše: "Vsi moji e-poštni sporočili imajo današnji datum. Ničesar ne najdem."

Težava ni, da bi e-poštna sporočila izginila. Tam so. Toda prikazani datum ustreza točnemu času obnove, ne datumu, ko so bila poslana ali prejeta. E-poštno sporočilo iz januarja 2021 se prikaže kot prejeto včeraj zvečer ob 23:47. Pogovorni niz je prekinjen. Kronologija je neberljiva.

Ta vedenje se pojavlja pri Veeam Backup for Microsoft 365, Datto SaaS Protection, Synology Active Backup for Microsoft 365 in AvePoint Cloud Backup, med drugimi. Vsak na svoj način, rezultat pa je enak.

Kaj se dogaja tehnično

Da bi razumeli, od kod izhaja napačen datum, je treba pogledati, kako ta orodja znova vbrizgajo e-poštna sporočila v Exchange Online ali Google Workspace.

Ko orodje za varnostno kopiranje obnovi sporočilo, ga ne more preprosto "vrniti na mesto", kot bi premikali datoteko na lokalnem disku. Orodje v poštni predal zapiše novo kopijo sporočila, prek protokola IMAP ali prek ponudnikovega API-ja (EWS ali Microsoft Graph na strani Microsoft, API Gmail na strani Google). Skupaj s to kopijo mora poštnemu predalu sporočiti tudi, kateri datum sporočilo nosi.

In tu se težava začne. (Mimogrede, če ste kdaj prebrali surove glave obnovljenega e-poštnega sporočila, ste verjetno videli dvajset vrstic Received:, preden ste našli koristno vsebino.)

IMAP APPEND in glava Received:

Protokol IMAP ima ukaz APPEND. Služi za vstavljanje sporočila v poštni predal. To je natanko tisto, kar uporablja orodje za obnovo: vzame shranjeno sporočilo in ga vbrizga v ciljni predal prek IMAP APPEND.

Ta ukaz orodju omogoča, da skupaj s sporočilom posreduje datum. Če orodje posreduje prvotni datum sporočila, ga poštni predal ohrani, tako ravnajo Microsoft 365, Outlook.com in Gmail. Če ne posreduje nič, ali posreduje datum obnove, poštni predal e-poštno sporočilo razvrsti pod dan obnove. Nekateri načini zapisa sporočila nazaj dodajo še eno vrstico na vrh: glavo Received:, datirano z dnem kopije. Prav to počne Gmailov lastni API za uvoz.

Ta dodatna vrstica je videti nekako takole:

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

Rezultat: prvotno e-poštno sporočilo je v notranjosti nedotaknjeno, z izvirno glavo Date: (recimo "3 Jan 2021 09:15:00"). Toda na vrhu je bila prilepljena nova glava Received:, datirana s trenutkom obnove.

Kako Outlook in Gmail bereta datum

Odjemalci e-pošte, kot sta Outlook ali spletni vmesnik Gmail, ne berejo vedno glave Date:, da bi odločili, kateri datum prikazati v seznamu sporočil. Mnogi uporabljajo INTERNALDATE protokola IMAP, torej datum, ko je bilo sporočilo dodano v predal, ali najnovejšo glavo Received:.

Outlook za Windows, zlasti po posodobitvi konec leta 2023, je na to posebej občutljiv. Ko vidi nedavno glavo Received: na vrhu verige, jo uporabi kot prikazni datum. Izvirni Date: je potisnjen v podrobnosti sporočila, viden samo če odpremo lastnosti e-pošte.

Končni uporabnik tako vidi seznam sporočil, ki so vsa datirana na noč obnove. Za njega se je triletna zgodovina stisnila v eno samo noč.

Ta težava se razlikuje od migracije

Razlikovati je treba od klasične težave napačnih datumov po IMAP migraciji. Pri migraciji orodje premakne e-pošto s strežnika A na strežnik B, in ali sporočilo ohrani svoj datum, je odvisno od tega, kaj orodje strežniku B sporoči, ko ga zapiše. Mehanika je enaka, toda kontekst je drugačen.

Tu govorimo o obnovi iz varnostne kopije. E-poštna sporočila nikoli niso zapustila organizacije, bila so le varno shranjena nekje (Azure Blob Storage, AWS S3, Datto appliance...) in nato znova vbrizgana. Uporabnik tega toliko manj pričakuje: zanj se vračajo "njegovi" e-poštni sporočili, ne uvoženi.

Toda tehnično je mehanizem enak. Ponovno vbrizgavanje, ki ne prenese prvotnega datuma, povzroči enake artefakte. In popravek sledi isti logiki.

Kako vsako orodje obravnava (ali ne obravnava) INTERNALDATE

Vsa orodja se ne obnašajo povsem enako, in tu postane stvar zanimiva.

Veeam Backup for Microsoft 365

Veeam uporablja API EWS (Exchange Web Services) za obnovo v Exchange Online. EWS omogoča določitev datuma sporočila prek polja DateTimeReceived, toda ta vrednost ni vedno prenesena na INTERNALDATE na ravni IMAP. Rezultat: datum razvrščanja v Outlooku morda ne ustreza izvirnemu datumu, zlasti če se obnova izvede v drug predal (granularna obnova v nadomestni predal, na primer).

Datto SaaS Protection

Datto obnovi prek Microsoft Graph API ali IMAP, odvisno od konfiguracije. V obeh primerih je datum, ki ga prikaže poštni predal, odvisen od tega, ali obnova za vsako sporočilo posreduje njegov prvotni datum. MSP-ji, ki za svoje stranke uporabljajo Datto, se s to težavo srečujejo precej redno, zlasti po incidentih z izsiljevalsko programsko opremo, ko se v sili obnovi več sto predalov hkrati. To ni pravi trenutek, da odkrijete, da so vsi datumi napačni.

AvePoint in Synology Active Backup

AvePoint Cloud Backup in Synology Active Backup for Microsoft 365 sledita podobnim mehanizmom. AvePoint je to vedenje dokumentiral v svoji bazi znanja (sporočilo je obnovljeno z datumom obnove kot vidnim datumom prejema), ne da bi ponudil izvorni popravek. Synology Active Backup kaže enako težavo, ki jo še poudarja dejstvo, da vmesnik za obnovo ne razlikuje jasno med "datumom sporočila" in "datumom obnove".

Dobra novica: izvirni datum je še vedno tam

Kar situacijo naredi rešljivo, je to, da izvirna glava Date: sporočila ni bila spremenjena. Še vedno je prisotna, nedotaknjena, v vsakem obnovljenem e-poštnem sporočilu. Obnova je spremenila datum, ki ga je zapisal poštni predal, včasih pa je čez njo dodala tudi vrstico Received:, toda vsebine sporočila samega ni dotaknila.

To je lastnost formata MIME (RFC 2822): sporočilo je v svoji notranji strukturi nespremenljivo. Glave Received: se nalagajo na vrhu kot plasti, toda izvirne informacije ostanejo spodaj.

Torej ne, podatkov niste izgubili. Samo skrite so za artefaktom ponovne vbrizge.

Zakaj ponovitev obnove ni rešitev

Prva misel, ki pride na misel: zbrisati obnovljena e-poštna sporočila in znova zagnati obnovo v upanju, da bodo tokrat datumi pravilni. To je slaba ideja, iz več razlogov.

Prvič, orodja za obnovo se pri drugem prehodu ne bodo obnašala drugače. Isto orodje, iste nastavitve: e-poštna sporočila se zapišejo nazaj na enak način, brez svojega prvotnega datuma. Dobili boste natanko enak rezultat.

Drugič, ponovna obnova v produkcijskih predalih pomeni čas, pasovno širino in tveganje. Pri 50 predalih z 20.000 sporočili vsak govorimo o operaciji, ki traja več ur, monopolizira API-je in lahko sproži omejitve hitrosti na strani Microsofta ali Googla (tisti slavni 429 Too Many Requests ob 2. zjutraj med serijo).

Skratka. Obnova je delovala. Podatki so tam. Kar je treba popraviti, je artefakt datuma, ne obnova sama.

Popravek po lastnih močeh: konkretna tveganja

Razumeti težavo je eno. Popraviti jo na 80.000 e-poštnih sporočilih brez izgube enega samega pa je povsem druga stvar.

Python skripta, ki pregleduje IMAP sporočila in popravlja datume, se morda zdi izvedljiva. Na 50 testnih e-poštnih sporočilih bo delovala odlično. V produkciji je drugače. Robni primeri se kopičijo: e-poštna sporočila s podpisom S/MIME (sprememba glave razveljavi kriptografski podpis), PGP šifrirana sporočila, multipart strukture z nestandardnimi mejami MIME, glave kodirane po RFC 2047 (ne-ASCII), 40 MB priloge, ki razstrelijo pomnilnik skripte. In e-poštna sporočila z več dodanimi glavami Received: (če je bila obnova delno ponovljena, kar se zgodi), ki zahtevajo bolj natančno logiko zaznavanja.

Natančno povedano, resnično tveganje ni skripta, ki se sesuje: to je skripta, ki deluje brez vidnih napak, a ustvarja okvarjena sporočila. Prekinjene pogovorne niti. Dvojniki. Ločene priloge. Tega morda ne boste odkrili še več tednov, ko bo uporabnik skušal poiskati pomembno e-pošto.

In kako preverite, da je vsako popravljeno e-poštno sporočilo resnično nedotaknjeno po spremembi? Domača skripta tega navadno ne počne.

Kaj Redate.io naredi drugače

Redate.io analizira verigo glav vsakega e-poštnega sporočila, da identificira artefakte ponovne vbrizge, pa naj prihajajo iz obnove Veeam, migracije BitTitan ali ročnega uvoza. Lastniški popravljalni mehanizem ne potrebuje podatka, katero orodje je povzročilo napako: išče e-poštna sporočila, katerih prikazani datum se ne ujema z njihovim prvotnim datumom, tako da se odkrije tudi orodje, o katerem še nihče ni slišal.

Preden Redate.io kar koli popravi, skenira celoten poštni predal in prikaže poročilo: koliko e-poštnih sporočil je prizadetih, kakšen je napačni datum, kakšen je zaznan izvirni datum. To skeniranje je brezplačno. Obseg težave vidite, preden se odločite za ukrepanje.

Vsako e-poštno sporočilo je po popravku individualno preverjeno. Izvirniki so shranjeni v vidni varnostni mapi, dokler jih ne izbrišete sami, kar zagotavlja popolno varnostno mrežo, če bi bilo treba.

Redate.io se poveže z vsakim poštnim predalom prek prijave posameznega uporabnika, ne prek osrednjega dostopa do celotne domene, brez da bi katero koli e-poštno sporočilo potovalo prek posrednih strežnikov. Popravek se izvede na mestu, v predalu, brez izvoza ali ponovnega uvoza.

Za MSP-je, ki sočasno upravljajo več prizadetih strank, glejte stran namenjeno MSP-jem: Redate.io omogoča vzporedno obdelavo več predalov iz enega vmesnika.

Drugi scenariji, ki povzročajo enak artefakt

Obnova iz orodja za varnostno kopiranje ni edini primer. Enak artefakt datuma se pojavi v drugih situacijah:

• Uvoz IMAP iz Exchange (arhivirani predali, znova vbrizgani v Exchange Online)
• Migracija v Exchange Online z orodji, ki na ciljni strani uporabljajo IMAP
• Granularna obnova iz izvožene datoteke PST, nato znova uvožene (glejte članek o uvozu PST)
• Skupni poštni predali, obnovljeni po incidentu (glejte popravek skupnih poštnih predalov)

V vseh teh primerih je osnovna mehanika enaka: ponovno vbrizgavanje ne prenese prvotnega datuma (včasih z novo glavo Received: na vrhu), poštni odjemalec pa ta nov datum prikaže kot referenčni.

E-poštna sporočila so tam, izvirni datum je ohranjen v vsakem sporočilu. Zaženite brezplačno skeniranje na Redate.io, da vidite natanko, koliko e-poštnih sporočil je prizadetih v vašem predalu, in se nato odločite, ali želite sprožiti popravek.