Veeam/Datto: emailuri cu data restaurării, nu a trimiterii

A doua zi după restaurare, ticketele încep să apară

Tocmai ați terminat o restaurare de căsuță email prin Veeam Backup for Microsoft 365. Operațiunea a mers bine, datele sunt acolo, folderele sunt intacte. Și apoi, luni dimineața, un utilizator vă scrie: "Toate emailurile mele au data de astăzi. Nu mai găsesc nimic."

Problema nu este că emailurile au dispărut. Sunt acolo. Dar data afișată corespunde momentului exact al restaurării, nu datei la care au fost trimise sau primite. Un email din ianuarie 2021 apare ca primit aseară la 23:47. Firul conversației este rupt. Cronologia este ilizibilă.

Acest comportament afectează Veeam Backup for Microsoft 365, Datto SaaS Protection, Synology Active Backup for Microsoft 365 și AvePoint Cloud Backup, printre altele. Fiecare în felul său, dar rezultatul este identic.

Ce se întâmplă din punct de vedere tehnic

Pentru a înțelege de unde vine data greșită, trebuie să vedem cum reinjectează aceste instrumente emailurile într-o căsuță Exchange Online sau Google Workspace.

Când un instrument de backup restaurează un mesaj, nu poate pur și simplu să "repună la loc" emailul cum ai muta un fișier pe un disc local. Instrumentul scrie o copie nouă a mesajului în căsuța poștală, prin IMAP sau prin API-ul furnizorului (EWS sau Microsoft Graph pe partea Microsoft, API-ul Gmail pe partea Google). Odată cu copia, trebuie să comunice căsuței poștale ce dată are mesajul.

Și aici începe problema. (De altfel, dacă ați citit vreodată headerele brute ale unui email restaurat, probabil ați văzut derulând vreo douăzeci de linii Received: înainte să găsiți conținutul util.)

IMAP APPEND și headerul Received:

Protocolul IMAP dispune de o comandă numită APPEND. Aceasta servește la inserarea unui mesaj într-o căsuță email. Exact asta folosește un instrument de restaurare: ia mesajul salvat și îl injectează în căsuța destinație prin IMAP APPEND.

Această comandă permite instrumentului să transmită o dată odată cu mesajul. Dacă instrumentul transmite data originală a mesajului, căsuța poștală o păstrează: Microsoft 365, Outlook.com și Gmail o fac toate. Dacă nu transmite nimic, sau transmite data restaurării, căsuța poștală înregistrează emailul la data restaurării. Iar unele moduri de a scrie mesajul înapoi adaugă încă o linie în partea de sus: un header Received: datat cu ziua copierii. API-ul de import al Gmail face exact acest lucru.

Această linie suplimentară arată cam așa:

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

Rezultat: emailul original este intact în interior, cu headerul Date: original (să zicem "3 Jan 2021 09:15:00"). Dar un nou header Received: a fost lipit în partea de sus, datat cu momentul restaurării.

Cum citesc Outlook și Gmail data

Clienții de email precum Outlook sau interfața web Gmail nu citesc întotdeauna headerul Date: pentru a decide ce dată să afișeze în lista de mesaje. Mulți folosesc INTERNALDATE din protocolul IMAP, adică data la care mesajul a fost adăugat în căsuță, sau cel mai recent header Received:.

Outlook pentru Windows, mai ales după actualizarea din finalul anului 2023, este deosebit de sensibil la asta. Când vede un header Received: recent în partea de sus a lanțului, îl folosește ca dată de afișare. Date:-ul original ajunge în detaliile mesajului, vizibil doar dacă deschizi proprietățile emailului.

Utilizatorul final vede deci o listă de mesaje toate datate din noaptea restaurării. Pentru el, istoricul de trei ani tocmai s-a comprimat într-o singură noapte.

Această problemă este diferită de o migrare

Trebuie să facem distincția față de problema clasică a datelor greșite după migrare IMAP. La o migrare, instrumentul mută emailurile de pe un server A pe un server B, iar dacă fiecare email își păstrează data depinde de ce îi transmite instrumentul serverului B atunci când îl scrie. Este același mecanism, dar contextul este diferit.

Aici vorbim despre o restaurare dintr-un backup. Emailurile nu au părăsit niciodată organizația, au fost pur și simplu puse la siguranță undeva (Azure Blob Storage, AWS S3, aplianță Datto...) și apoi reinjectate. Utilizatorul se așteaptă cu atât mai puțin la asta: pentru el, sunt "ale lui" emailuri care se întorc, nu emailuri importate.

Dar din punct de vedere tehnic, mecanismul este același. O reinjectare care nu transmite data originală produce aceleași artefacte. Iar corecția urmează aceeași logică.

Cum gestionează (sau nu gestionează) fiecare instrument INTERNALDATE

Nu toate instrumentele se comportă exact la fel, și aici lucrurile devin interesante.

Veeam Backup for Microsoft 365

Veeam folosește API-ul EWS (Exchange Web Services) pentru a restaura în Exchange Online. EWS permite specificarea datei mesajului prin câmpul DateTimeReceived, dar această valoare nu se reflectă întotdeauna în INTERNALDATE la nivel IMAP. Rezultat: data de sortare în Outlook poate să nu corespundă datei originale, mai ales dacă restaurarea se face spre o căsuță diferită de cea originală (restaurare granulară spre o căsuță alternativă, de exemplu).

Datto SaaS Protection

Datto restaurează prin Microsoft Graph API sau IMAP în funcție de configurație. În ambele cazuri, data afișată de căsuța poștală depinde de faptul că restaurarea transmite sau nu data originală a fiecărui mesaj. MSP-urile care folosesc Datto pentru clienții lor întâlnesc această problemă destul de regulat, mai ales după incidente ransomware în care se restaurează de urgență câteva sute de căsuțe simultan. Nu e momentul să descoperi că toate datele sunt greșite.

AvePoint și Synology Active Backup

AvePoint Cloud Backup și Synology Active Backup for Microsoft 365 urmează mecanisme similare. AvePoint a documentat acest comportament în baza sa de cunoștințe (mesajul este restaurat cu data restaurării ca dată de primire vizibilă), fără să propună un remediu nativ. Synology Active Backup prezintă aceeași problemă, amplificată de faptul că interfața de restaurare nu distinge clar "data mesajului" de "data restaurării".

Vestea bună: data originală este încă acolo

Ceea ce face situația recuperabilă este că headerul Date: original al mesajului nu a fost modificat. El este în continuare prezent, intact, în corpul fiecărui email restaurat. Restaurarea a modificat data înregistrată de căsuța poștală, și, uneori, a adăugat o linie Received: deasupra, dar nu a atins conținutul mesajului în sine.

Este o proprietate a formatului MIME (RFC 2822): un mesaj este imuabil în structura sa internă. Headerele Received: se acumulează în partea de sus ca niște straturi, dar informațiile originale rămân dedesubt.

Deci nu, nu ați pierdut informația. Este doar ascunsă de un artefact de reinjec ție.

De ce relansarea restaurării nu este soluția

Prima idee care vine în minte: șterge emailurile restaurate și relansează restaurarea, sperând că de data asta datele vor fi corecte. Este o idee proastă, din mai multe motive.

În primul rând, instrumentele de restaurare nu se vor comporta diferit la a doua trecere. Același instrument, aceleași setări: emailurile sunt scrise înapoi în același mod, fără data lor originală. Veți obține exact același rezultat.

Apoi, relansarea unei restaurări pe căsuțe în producție înseamnă timp, lățime de bandă și risc. Pe 50 de căsuțe cu câte 20.000 de mesaje fiecare, vorbim de o operațiune de câteva ore care monopolizează API-urile și poate declanșa limite de rată din partea Microsoft sau Google (faimosul 429 Too Many Requests la 2 dimineața în timpul batch-ului).

Pe scurt: restaurarea a funcționat. Datele sunt acolo. Ceea ce trebuie corectat este artefactul de dată, nu restaurarea în sine.

Corectarea pe cont propriu: riscurile concrete

A înțelege problema este una. A o corecta pe 80.000 de emailuri fără să pierzi niciunul este cu totul altceva.

Un script Python care parcurge mesajele IMAP și corectează datele poate părea fezabil. Și pe 50 de emailuri de test va funcționa perfect. În producție, e diferit. Cazurile limită se acumulează: emailuri semnate S/MIME (modificarea headerului invalidează semnătura criptografică), mesaje PGP criptate, structuri multipart cu granițe MIME non-standard, headere encodate în RFC 2047 (non-ASCII), atașamente de 40 MB care fac să explodeze memoria scriptului. Și emailurile cu mai multe headere Received: adăugate (dacă restaurarea a fost relansată parțial, ceea ce se întâmplă), care necesită o logică de detectare mai fină.

Ca să fim preciși, riscul real nu este scriptul care se blochează: este scriptul care rulează fără erori aparente dar produce mesaje corupte. Fire de discuție rupte. Duplicate. Atașamente detașate. Pe care le veți descoperi poate doar câteva săptămâni mai târziu, când un utilizator încearcă să regăsească un email important.

Și cum verificați că fiecare email corectat este cu adevărat intact după modificare? Un script improvizat nu face asta de obicei.

Ce face Redate.io diferit

Redate.io analizează lanțul de headere al fiecărui email pentru a identifica artefactele de reinjectare, fie că provin dintr-o restaurare Veeam, o migrare BitTitan sau un import manual. Motorul de corecție proprietar nu are nevoie să știe care instrument a provocat problema: el caută emailurile a căror dată afișată nu corespunde datei lor originale, astfel încât este detectat și un instrument de care nimeni n-a auzit.

Înainte de a corecta orice, Redate.io scanează întreaga căsuță și prezintă un raport: câte emailuri sunt afectate, care este data incorectă, care este data originală detectată. Această scanare este gratuită. Vedeți amploarea problemei înainte de a decide să acționați.

Fiecare email este verificat individual după corecție. Originalele sunt păstrate într-un folder de backup vizibil și nu sunt șterse niciodată de Redate.io; rămân acolo până le ștergeți dumneavoastră, oferind o plasă de siguranță completă dacă este nevoie.

Redate.io se conectează la cutia poștală prin autentificarea proprie a fiecărui utilizator, fără portal, fără aplicație de înregistrat, fără ca vreun e-mail să tranziteze servere intermediare. Corecția se face pe loc, în căsuță, fără export sau reimport.

Pentru MSP-urile care gestionează mai mulți clienți afectați simultan, consultați pagina dedicată MSP-urilor: Redate.io permite tratarea mai multor căsuțe în paralel dintr-o singură interfață.

Alte scenarii care produc același artefact

Restaurarea dintr-un instrument de backup nu este singurul caz. Același artefact de dată apare și în alte situații:

• Import IMAP din Exchange (căsuțe arhivate reinjectate în Exchange Online)
• Migrare spre Exchange Online cu instrumente care folosesc IMAP pe partea de destinație
• Restaurare granulară dintr-un PST exportat și reimportat (vezi articolul despre importul PST)
• Căsuțe email partajate reconstituite după un incident (vezi corectarea căsuțelor partajate)

În toate aceste cazuri, mecanismul de bază este identic: o reinjectare care nu transmite data originală (uneori cu un nou header Received: adăugat), și un client de email care arată acea dată nouă ca dată de referință.

Emailurile sunt acolo, data originală este păstrată în fiecare mesaj. Lansați o scanare gratuită pe Redate.io pentru a vedea exact câte emailuri sunt afectate în căsuța dumneavoastră și decideți apoi dacă doriți să lansați corecția.