Veeam/Datto: emailovi datovani datumom restauracije

Sutradan posle restauracije, tiketi pristižu

Upravo ste završili restauraciju poštanskog sandučića pomoću Veeam Backup for Microsoft 365. Operacija je protekla bez problema, podaci su tu, fascikle su netaknute. I onda, u ponedeljak ujutru, korisnik Vam piše: "Svi moji emailovi imaju današnji datum. Ne mogu ništa da pronađem."

Problem nije u tome što su emailovi nestali. Oni su tu. Ali njihov prikazani datum odgovara tačnom trenutku restauracije, a ne datumu kada su poslati ili primljeni. Email iz januara 2021. izgleda kao da je primljen sinoć u 23:47. Nit razgovora je prekinuta. Hronologija je nečitljiva.

Ovaj problem pogađ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 identičan.

Šta se tehnički dešava

Da bismo razumeli odakle dolazi pogrešan datum, treba pogledati kako ovi alati ubacuju emailove nazad u Exchange Online ili Google Workspace sandučić.

Kada alat za bekap restaurira poruku, ne može jednostavno da je "vrati na mesto" kao što bismo pomerili fajl na lokalnom disku. Alat upisuje novu kopiju poruke u sandučić, putem IMAP protokola ili API-ja provajdera (EWS ili Microsoft Graph na Microsoft strani, Gmail API na Google strani). I zajedno sa tom kopijom, mora da kaže sandučiću koji datum poruka nosi.

I tu počinje problem. (Inače, ako ste ikad pregledali sirove zaglavlja restauriranog emaila, verovatno ste videli dvadesetak linija Received: pre nego što ste pronašli korisni sadržaj.)

IMAP APPEND i zaglavlje Received:

IMAP protokol ima komandu pod nazivom APPEND. Služi za umetanje poruke u poštanski sandučić. To je tačno ono što koristi alat za restauraciju: uzima sačuvanu poruku i ubacuje je u ciljni sandučić putem IMAP APPEND.

Ova komanda omogućava alatu da uz poruku prosledi datum. Ako alat prosledi originalni datum poruke, sandučić ga čuva: to važi za Microsoft 365, Outlook.com i Gmail. Ako ne prosledi ništa, ili prosledi datum restauracije, sandučić svrstava email pod dan restauracije. A neki načini upisivanja poruke dodaju još jednu liniju na vrh: zaglavlje Received: datirano danom kopiranja. Gmail-ov sopstveni API za uvoz radi baš to.

Ova dodatna linija izgleda otprilike ovako:

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

Rezultat: originalni email je netaknut iznutra, sa svojim originalnim zaglavljem Date: (recimo "3 Jan 2021 09:15:00"). Ali novo zaglavlje Received: zalepljeno je na samom vrhu, datirano trenutkom restauracije.

Kako Outlook i Gmail čitaju datum

Klijenti poput Outlooka ili Gmail veb interfejsa ne čitaju uvek zaglavlje Date: da bi odlučili koji datum prikazati u listi poruka. Mnogi koriste INTERNALDATE IMAP protokola, tj. datum kada je poruka dodata u sandučić, ili najskorije zaglavlje Received:.

Outlook za Windows, posebno od ažuriranja krajem 2023, posebno je osetljiv na ovo. Kada vidi skorašnje zaglavlje Received: na vrhu lanca, koristi ga kao datum za prikaz. Originalni Date: prebačen je u detalje poruke, vidljiv samo ako otvorite svojstva emaila.

Krajnji korisnik zato vidi listu poruka koje su sve datirane noću restauracije. Za njega, trogodišnja istorija se saplela u jednu jedinu noć.

Ovaj problem se razlikuje od migracije

Treba napraviti razliku u odnosu na klasičan problem pogrešnih datuma posle IMAP migracije. Kod migracije, alat premešta emailove sa servera A na server B, i da li email zadržava svoj datum zavisi od toga šta alat javlja serveru B dok ga upisuje. Mehanizam je isti, ali kontekst je drugačiji.

Ovde govorimo o restauraciji iz bekapa. Emailovi nikada nisu napustili organizaciju, samo su privremeno čuvani negde (Azure Blob Storage, AWS S3, Datto uređaj...) i potom ponovo ubačeni. Korisnik to još manje očekuje: za njega se radi o "njegovim" emailovima koji se vraćaju, ne o uvezenim porukama.

Ali tehnički, mehanizam je isti. Ponovna injekcija koja ne prenosi originalni datum proizvodi iste artefakte. I popravka, takođe, sledi istu logiku.

Kako svaki alat (ne) obrađuje INTERNALDATE

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

Veeam Backup for Microsoft 365

Veeam koristi EWS (Exchange Web Services) API za restauraciju u Exchange Online. EWS omogućava navođenje datuma poruke putem polja DateTimeReceived, ali ova vrednost nije uvek preneta na INTERNALDATE na IMAP nivou. Rezultat: datum sortiranja u Outlooku možda neće odgovarati originalnom datumu, posebno ako se restauracija vrši u sandučić koji se razlikuje od originalnog (granularna restauracija u alternativni sandučić, na primer).

Datto SaaS Protection

Datto restaurira putem Microsoft Graph API ili IMAP-a zavisno od konfiguracije. U oba slučaja, datum koji sandučić prikazuje zavisi od toga da li restauracija prenosi originalni datum svake poruke. MSP-ovi koji koriste Datto za svoje klijente nailaze na ovaj problem dosta redovno, posebno posle ransomware incidenata gde se hitno restaurira nekoliko stotina sandučića odjednom. To nije pravi trenutak da otkrijete da su svi datumi pogrešni.

AvePoint i Synology Active Backup

AvePoint Cloud Backup i Synology Active Backup for Microsoft 365 slede slične mehanizme. AvePoint je dokumentovao ovo ponašanje u svojoj bazi znanja (poruka se restaurira sa datumom restauracije kao vidljivim datumom prijema), bez predlaganja nativnog rešenja. Synology Active Backup ima isti problem, pojačan činjenicom da interfejs za restauraciju ne pravi jasnu razliku između "datuma poruke" i "datuma restauracije".

Dobra vest: originalni datum je i dalje tu

Ono što situaciju čini popravljenom jeste to što originalno zaglavlje Date: poruke nije izmenjeno. I dalje je prisutno, netaknuto, u svakom restauriranom emailu. Restauracija je promenila datum koji je sandučić zabeležio, i ponekad je dodala liniju Received: povrh njega, ali nije dirala sam sadržaj poruke.

To je osobina MIME formata (RFC 2822): poruka je nepromenljiva u svojoj unutrašnjoj strukturi. Zaglavlja Received: gomilaju se na vrhu kao slojevi, ali originalne informacije ostaju ispod.

Dakle, niste izgubili tu informaciju. Samo je zakopana artefaktom ponovne injekcije.

Zašto ponovna restauracija nije rešenje

Prva ideja koja pada na pamet: obrisati restaurirane emailove i pokrenuti restauraciju iznova u nadi da će ovoga puta datumi biti ispravni. To je loša ideja, iz nekoliko razloga.

Pre svega, alati za restauraciju neće se ponašati drugačije pri drugom pokušaju. Isti alat, ista podešavanja: emailovi se upisuju nazad na isti način, bez svog originalnog datuma. Dobićete tačno isti rezultat.

Zatim, pokretanje restauracije na produkcijskim sandučićima košta vremena, propusnog opsega i nosi rizik. Na 50 sandučića sa po 20.000 poruka, radi se o operaciji od nekoliko sati koja zauzima API-je i može pokrenuti ograničenja brzine na strani Microsofta ili Googlea (poznati 429 Too Many Requests u 2 ujutru tokom batch obrade).

Ukratko. Restauracija je prošla. Podaci su tu. Ono što treba ispraviti je artefakt datuma, ne sama restauracija.

Ručno ispravljanje: konkretni rizici

Razumeti problem je jedno. Ispraviti ga na 80.000 emailova bez gubitka ijednog, to je sasvim druga stvar.

Python skript koji prolazi kroz IMAP poruke i ispravlja datume može izgledati izvodljivo. I na 50 testnih emailova radiće odlično. U produkciji, drugačija je priča. Granični slučajevi se gomilaju: emailovi potpisani S/MIME (izmena zaglavlja poništava kriptografski potpis), PGP šifrovane poruke, multipart strukture sa nestandardnim MIME granicama, zaglavlja kodirana po RFC 2047 (ne-ASCII), prilozi od 40 MB koji troše svu memoriju skripta. I emailovi sa više dodatih zaglavlja Received: (ako je restauracija delimično ponavljana, što se dešava), koji zahtevaju finiju logiku detekcije.

Da budemo precizni, pravi rizik nije skript koji pada: to je skript koji radi bez vidljive greške ali proizvodi poruke sa greškama. Prekinute niti razgovora. Duplikate. Odvojene priloge. Koje možda nećete otkriti do nekoliko nedelja kasnije, kada korisnik pokuša da pronađe važan email.

I kako proveravate da je svaki ispravljeni email zaista netaknut nakon izmene? Kućni skript to obično ne radi.

Šta Redate.io radi drugačije

Redate.io analizira lanac zaglavlja svakog emaila kako bi identifikovao artefakte ponovne injekcije, bilo da potiču iz Veeam restauracije, BitTitan migracije ili ručnog uvoza. Vlasnički mehanizam korekcije ne mora da zna koji alat je izazvao problem: traži emailove čiji prikazani datum ne odgovara njihovom originalnom datumu, tako da se otkrije i alat za koji niko nikad nije čuo.

Pre nego što ispravi bilo šta, Redate.io skenira ceo sandučić i prikazuje izveštaj: koliko emailova je pogođeno, koji je netačni datum, koji je detektovani originalni datum. Ovaj sken je besplatan. Vidite obim problema pre nego što odlučite da delujete.

Svaki email se pojedinačno verifikuje posle korekcije. Originali su sačuvani u vidljivoj backup fascikli sve dok ih sami ne obrišete, što pruža potpunu sigurnosnu mrežu u slučaju potrebe.

Redate.io se povezuje direktno sa poštanskim sandučićem, korisnik se prijavljuje sopstvenim nalogom, bez ijednog emaila koji prolazi kroz posredne servere. Korekcija se vrši na licu mesta, u sandučiću, bez izvoza ili ponovnog uvoza.

Za MSP-ove koji upravljaju više istovremeno pogođenih klijenata, pogledajte stranicu posvećenu MSP-ovima: Redate.io omogućava obradu više sandučića paralelno iz jednog interfejsa.

Drugi scenariji koji proizvode isti artefakt

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

• IMAP uvoz iz Exchangea (arhivirani sandučići ponovo ubačeni u Exchange Online)
• Migracija ka Exchange Online sa alatima koji koriste IMAP na strani odredišta
• Granularna restauracija iz PST-a izvezenog pa ponovo uvezenog (videti članak o PST uvozu)
• Deljeni sandučići rekonstruisani posle incidenta (videti ispravljanje deljenih sandučića)

U svim ovim slučajevima, osnovni mehanizam je identičan: ponovna injekcija koja ne prenosi originalni datum (ponekad sa novim zaglavljem Received: povrh), i mejl klijent koji taj novi datum prikazuje kao referentni.

Emailovi su tu, originalni datum je sačuvan u svakoj poruci. Pokrenite besplatni sken na Redate.io da vidite tačno koliko emailova je pogođeno u Vašem sandučiću, i potom odlučite da li želite da pokrenete korekciju.