Veeam/Datto: emailovi datirani prema obnovi, ne slanju

Sutradan nakon obnove, tiketi počinju stizati

Upravo ste završili obnovu poštanskog sandučića putem Veeam Backup for Microsoft 365. Operacija je prošla glatko, podaci su tu, mape su netaknute. I onda, u ponedjeljak ujutro, korisnik Vam piše: "Svi moji emailovi imaju današnji datum. Ne mogu ništa pronaći."

Problem nije u tome što su emailovi nestali. Oni su tu. Ali prikazani datum odgovara točnom trenutku obnove, a ne datumu kada su bili poslani ili primljeni. Email iz siječnja 2021. pojavljuje se kao primljen sinoć u 23:47. Nit razgovora je prekinuta. Kronologija je nečitljiva.

Ovaj problem zahvaća Veeam Backup for Microsoft 365, Datto SaaS Protection, Synology Active Backup for Microsoft 365 i AvePoint Cloud Backup, između ostalih. Svaki na svoj način, ali rezultat je isti.

Što se tehnički događa

Da bismo razumjeli odakle dolazi pogrešan datum, moramo pogledati kako ovi alati vraćaju emailove u Exchange Online ili Google Workspace sandučić.

Kada alat za backup obnavlja poruku, ne može jednostavno "vratiti na mjesto" email kao što bismo premjestili datoteku na lokalnom disku. Piše novu kopiju poruke u sandučić, putem IMAP-a ili putem API-ja pružatelja usluge (EWS ili Microsoft Graph na Microsoftovoj strani, Gmail API na Googleovoj strani). Uz tu kopiju, mora sandučiću priopćiti koji datum poruka nosi.

I tu počinje problem. (Inače, ako ste ikada čitali neobrađene zaglavlja obnovljenog emaila, vjerojatno ste vidjeli dvadesetak redova Received: prije nego što ste pronašli korisni sadržaj.)

IMAP APPEND i zaglavlje Received:

IMAP protokol ima naredbu pod nazivom APPEND. Koristi se za umetanje poruke u poštanski sandučić. Točno to radi alat za obnovu: uzima sačuvanu poruku i ubacuje je u ciljni sandučić putem IMAP APPEND.

Ova naredba omogućuje alatu da uz poruku proslijedi i datum. Ako alat proslijedi izvorni datum poruke, sandučić ga zadržava: Microsoft 365, Outlook.com i Gmail to svi čine. Ako ne proslijedi ništa, ili proslijedi datum obnove, sandučić datira email danom obnove. A neki načini ponovnog upisa poruke dodaju još jedan red na vrh: zaglavlje Received: s datumom dana kopiranja. Gmailov API za uvoz upravo to čini.

Ovaj dodatni red izgleda otprilike ovako:

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

Rezultat: originalni email je netaknut iznutra, s originalnim zaglavljem Date: (recimo "3 Jan 2021 09:15:00"). Ali novo zaglavlje Received: zalijepljeno je na sam vrh, datirano trenutkom obnove.

Kako Outlook i Gmail čitaju datum

Klijenti za poštu poput Outlooka ili Gmail sučelja ne čitaju uvijek zaglavlje Date: kako bi odredili datum koji će prikazati u popisu poruka. Mnogi koriste INTERNALDATE IMAP protokola, odnosno datum kada je poruka dodana u sandučić, ili najnovije zaglavlje Received:.

Outlook za Windows, posebno od ažuriranja s kraja 2023. godine, posebno je osjetljiv na ovo. Kada vidi nedavno zaglavlje Received: na vrhu lanca, koristi ga kao datum prikaza. Originalni Date: premješten je u detalje poruke, vidljiv samo ako se otvore svojstva emaila.

Krajnji korisnik stoga vidi popis poruka koji su svi datirani na noć obnove. Za njega, trogodišnja povijest upravo se spljoštila u jednu jedinu noć.

Ovaj problem je drugačiji od migracije

Potrebno je napraviti razliku od klasičnog problema pogrešnih datuma nakon IMAP migracije. Kod migracije, alat premješta emailove s poslužitelja A na poslužitelj B, a hoće li email zadržati svoj datum ovisi o tome što alat javlja poslužitelju B dok ga upisuje. Ista je mehanika, ali kontekst je drugačiji.

Ovdje govorimo o obnovi iz sigurnosne kopije. Emailovi nikada nisu napustili organizaciju, samo su bili pohranjen na sigurnom negdje (Azure Blob Storage, AWS S3, Datto appliance...) i zatim vraćeni. Korisnik to još manje očekuje: za njega se vraćaju "njegovi" emailovi, a ne uvezeni emailovi.

Ali tehnički, mehanizam je isti. Vraćanje koje ne prenosi izvorni datum proizvodi iste artefakte. I ispravak slijedi istu logiku.

Kako svaki alat (ne) upravlja INTERNALDATEOM

Svi alati ne ponašaju se na točno isti način, i tu stvari postaju zanimljive.

Veeam Backup for Microsoft 365

Veeam koristi EWS (Exchange Web Services) API za obnovu prema Exchange Onlineu. EWS dozvoljava specificiranje datuma poruke putem polja DateTimeReceived, ali ta se vrijednost ne prenosi uvijek na INTERNALDATE na IMAP razini. Rezultat: datum sortiranja u Outlooku možda neće odgovarati originalnom datumu, posebno ako se obnova radi prema drugačijem sandučiću od originalnog (granularna obnova prema alternativnom sandučiću, na primjer).

Datto SaaS Protection

Datto obnavlja putem Microsoft Graph API-ja ili IMAP-a ovisno o konfiguraciji. U oba slučaja, datum koji sandučić prikazuje ovisi o tome prenosi li obnova izvorni datum svake poruke. MSP-ovi koji koriste Datto za svoje klijente susreću se s ovim problemom dosta redovito, posebno nakon ransomware incidenata gdje se hitno obnavlja nekoliko stotina sandučića odjednom. To nije trenutak za otkrivanje da su svi datumi pogrešni.

AvePoint i Synology Active Backup

AvePoint Cloud Backup i Synology Active Backup for Microsoft 365 prate slične mehanizme. AvePoint je dokumentirao ovo ponašanje u svojoj bazi znanja (poruka se obnavlja s datumom obnove kao vidljivim datumom primitka), ali bez nativnog ispravka. Synology Active Backup pokazuje isti problem, pojačan činjenicom da sučelje za obnovu ne razlikuje jasno "datum poruke" od "datuma obnove".

Dobra vijest: originalni datum je i dalje tu

Ono što situaciju čini rješivom jest da originalno zaglavlje Date: poruke nije bilo izmijenjeno. Ono je i dalje prisutno, netaknuto, u sadržaju svakog obnovljenog emaila. Obnova je promijenila datum koji je sandučić zabilježio, a ponekad je dodala i redak Received: povrh njega, ali nije dirala sam sadržaj poruke.

To je svojstvo MIME formata (RFC 2822): poruka je nepromjenjiva u svojoj unutarnjoj strukturi. Zaglavlja Received: nakupljaju se na vrhu kao slojevi, ali originalne informacije ostaju ispod.

Dakle, informacija nije izgubljena. Samo je skrivena artefaktom vraćanja.

Zašto ponovna obnova nije rješenje

Prva ideja koja pada na pamet: obrisati obnovljene emailove i pokrenuti obnovu iznova u nadi da će ovaj put datumi biti ispravni. To je loša ideja, iz više razloga.

Alati za obnovu neće se ponašati drugačije pri drugom pokušaju. Isti alat, iste postavke: emailovi se upisuju na isti način, bez svog izvornog datuma. Dobit ćete točno isti rezultat.

Osim toga, ponovna obnova na produkcijskim sandučićima znači vrijeme, propusnost mreže i rizik. Za 50 sandučića s 20.000 poruka svaki, govorimo o operaciji koja traje nekoliko sati, monopolizira API-je i može pokrenuti ograničenja brzine na strani Microsofta ili Googlea (čuveni 429 Too Many Requests u 2 ujutro tijekom batch operacije).

Ukratko. Obnova je funkcionirala. Podaci su tu. Ono što treba ispraviti jest artefakt datuma, a ne sama obnova.

Ručni ispravak: konkretni rizici

Razumjeti problem je jedna stvar. Ispraviti ga na 80.000 emailova bez gubitka ijednog, sasvim je druga.

Python skripta koja prolazi kroz IMAP poruke i ispravlja datume može se činiti izvedivom. Na 50 testnih emailova radit će savršeno. U produkciji, situacija je drugačija. Rubni slučajevi se gomilaju: S/MIME potpisani emailovi (izmjena zaglavlja poništava kriptografski potpis), PGP šifrirane poruke, multipart strukture s nestandardnim MIME granicama, zaglavlja kodirana prema RFC 2047 (ne-ASCII), privici od 40 MB koji ruše memoriju skripte. I emailovi s višestrukim dodanim zaglavljima Received: (ako je obnova bila djelomično ponavljana, što se dogodi), koji zahtijevaju finiju logiku detekcije.

Da budemo precizni, pravi rizik nije skripta koja se ruši: to je skripta koja se izvršava bez vidljive greške, ali proizvodi neispravne poruke. Prekinute niti razgovora. Duplikati. Odvojeni privici. Koje možda nećete otkriti tek nekoliko tjedana kasnije, kada korisnik pokuša pronaći važan email.

I kako verificirate da je svaki ispravljeni email zaista netaknut nakon izmjene? Kućna skripta to obično ne čini.

Što Redate.io radi drugačije

Redate.io analizira lanac zaglavlja svakog emaila kako bi identificirao artefakte vraćanja, bez obzira dolaze li od Veeam obnove, BitTitan migracije ili ručnog uvoza. Vlasnički motor za ispravak ne treba znati koji je alat uzrokovao problem: on traži emailove čiji prikazani datum ne odgovara njihovom izvornom datumu, tako da se otkrije i alat za koji nitko nije čuo.

Prije nego što se išta ispravi, Redate.io skenira cijeli sandučić i prikazuje izvještaj: koliko emailova je zahvaćeno, koji je neispravan datum, koji je originalni datum otkriven. Taj sken je besplatan. Vidite razmjere problema prije nego što odlučite djelovati.

Svaki email se individualno verificira nakon ispravka. Originali se čuvaju u vidljivoj mapi sigurnosne kopije sve dok ih sami ne izbrišete, što pruža potpunu sigurnosnu mrežu ako zatreba.

Redate.io se povezuje izravno kad se korisnik prijavi svojim Microsoftovim ili Google računom, bez da ikoji email prolazi kroz posredničke poslužitelje. Ispravak se vrši na licu mjesta, u sandučiću, bez izvoza ni uvoza.

Za MSP-ove koji upravljaju s više klijenata zahvaćenih istovremeno, pogledajte stranicu namijenjenu MSP-ovima: Redate.io omogućuje obradu više sandučića paralelno iz jednog sučelja.

Drugi scenariji koji proizvode isti artefakt

Obnova iz alata za backup nije jedini slučaj. Isti artefakt datuma pojavljuje se u drugim situacijama:

• IMAP uvoz iz Exchangea (arhivirani sandučići vraćeni u Exchange Online)
• Migracija prema Exchange Onlineu s alatima koji koriste IMAP na strani odredišta
• Granularna obnova iz izvezenog PST-a koji je zatim uvezen (pogledajte članak o PST uvozu)
• Dijeljeni poštanski sandučići rekonstruirani nakon incidenta (pogledajte ispravak dijeljenih sandučića)

U svim ovim slučajevima, temeljna mehanika je identična: vraćanje koje ne prenosi izvorni datum (ponekad uz novo zaglavlje Received: na vrhu), a mail klijent taj novi datum prikazuje kao referentni.

Emailovi su tu, originalni datum je sačuvan u svakoj poruci. Pokrenite besplatno skeniranje na Redate.io kako biste vidjeli točno koliko emailova je zahvaćeno u Vašem sandučiću, i tada odlučite želite li pokrenuti ispravak.