Veeam/Datto: emaily s dátumom obnovy, nie odoslania

Na druhý deň po obnove prichádzajú tikety

Práve ste dokončili obnovu poštovej schránky cez Veeam Backup for Microsoft 365. Operácia prebehla bez problémov, dáta sú na mieste, priečinky sú neporušené. A potom, v pondelok ráno, vám používateľ napíše: "Všetky moje emaily majú dnešný dátum. Nič nemôžem nájsť."

Problém nie je v tom, že emaily zmizli. Sú tam. Ale ich zobrazený dátum zodpovedá presnému času obnovy, nie dátumu, kedy boli odoslané alebo prijaté. Email z januára 2021 vyzerá, akoby bol prijatý včera večer o 23:47. Vlákno konverzácie je rozbitý. Chronológia je nečitateľná.

Toto správanie sa týka Veeam Backup for Microsoft 365, Datto SaaS Protection, Synology Active Backup for Microsoft 365 a AvePoint Cloud Backup, okrem iných. Každý po svojom, ale výsledok je rovnaký.

Čo sa deje technicky

Aby sme pochopili, odkiaľ pochádza nesprávny dátum, treba sa pozrieť na to, ako tieto nástroje vracajú emaily späť do schránky Exchange Online alebo Google Workspace.

Keď zálohovací nástroj obnoví správu, nemôže jednoducho email "vrátiť na miesto" tak, ako by ste presunuli súbor na lokálnom disku. Zapíše novú kópiu správy do schránky, cez protokol IMAP alebo cez rozhranie API poskytovateľa (EWS alebo Microsoft Graph na strane Microsoftu, Gmail API na strane Googlu). A spolu s touto kópiou musí schránke oznámiť, aký dátum správa nesie.

A tu začína problém. (Mimochodom, ak ste niekedy čítali surové hlavičky obnoveného emailu, pravdepodobne ste pred samotným obsahom videli dvadsať riadkov Received:.)

IMAP APPEND a hlavička Received:

Protokol IMAP má príkaz nazvaný APPEND. Slúži na vloženie správy do poštovej schránky. Presne to používa nástroj na obnovu: vezme záložnú správu a vloží ju do cieľovej schránky cez IMAP APPEND.

Tento príkaz umožňuje nástroju odovzdať spolu so správou aj dátum. Ak nástroj odovzdá pôvodný dátum správy, schránka si ho ponechá: platí to pre Microsoft 365, Outlook.com aj Gmail. Ak neodovzdá nič, alebo odovzdá dátum obnovy, schránka email zaradí pod deň obnovy. A niektoré spôsoby zápisu správy naspäť pridajú na začiatok ešte jeden riadok: hlavičku Received: datovanú dňom kópie. Presne to robí importné API Gmailu.

Tento nový riadok vyzerá asi takto:

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

Výsledok: pôvodný email je vo vnútri neporušený so svojou pôvodnou hlavičkou Date: (povedzme "3 Jan 2021 09:15:00"). Ale na úplný začiatok bola prilepená nová hlavička Received: s dátumom obnovy.

Ako Outlook a Gmail čítajú dátum

Poštové klienty ako Outlook alebo webové rozhranie Gmailu nie vždy čítajú hlavičku Date: pri rozhodovaní o tom, ktorý dátum zobraziť v zozname správ. Mnohé používajú INTERNALDATE protokolu IMAP, čiže dátum, kedy bola správa pridaná do schránky, alebo najnovšiu hlavičku Received:.

Outlook pre Windows, najmä od svojej aktualizácie koncom roka 2023, je na toto mimoriadne citlivý. Keď vidí nedávnu hlavičku Received: na začiatku reťazca, použije ju ako dátum zobrazenia. Pôvodný Date: je odsunutý do detailov správy, viditeľný len po otvorení vlastností emailu.

Koncový používateľ teda vidí zoznam správ, kde všetky majú dátum z noci obnovy. Pre neho sa trojročná história splynula do jednej noci.

Tento problém sa líši od migrácie

Treba rozlíšiť klasický problém nesprávnych dátumov po migrácii IMAP. Pri migrácii nástroj presúva emaily zo servera A na server B, pričom to, či si email dátum zachová, závisí od toho, čo nástroj serveru B pri zápise oznámi. Ide o rovnaký mechanizmus, ale kontext je iný.

Tu hovoríme o obnove zo zálohy. Emaily nikdy neopustili organizáciu, boli len uložené niekde v bezpečí (Azure Blob Storage, AWS S3, Datto appliance...) a potom vrátené. Používateľ to ešte menej očakáva: pre neho sa vracajú "jeho" emaily, nie nejaké importované správy.

Technicky je ale mechanizmus rovnaký. Reinzercia, ktorá neprenáša pôvodný dátum, produkuje rovnaké artefakty. A náprava sa riadi rovnakou logikou.

Ako každý nástroj (ne)spracúva INTERNALDATE

Nie všetky nástroje sa správajú úplne rovnako, a práve tu sa veci stávajú zaujímavými.

Veeam Backup for Microsoft 365

Veeam používa na obnovu do Exchange Online API EWS (Exchange Web Services). EWS umožňuje zadať dátum správy cez pole DateTimeReceived, ale táto hodnota sa nie vždy premietne do INTERNALDATE na úrovni IMAP. Výsledok: dátum triedenia v Outlooku nemusí zodpovedať pôvodnému dátumu, najmä pri obnove do inej schránky (granulárna obnova do alternatívnej schránky, napríklad).

Datto SaaS Protection

Datto obnovuje cez Microsoft Graph API alebo IMAP podľa konfigurácie. V oboch prípadoch závisí zobrazený dátum v schránke od toho, či obnova pri každej správe odovzdá jej pôvodný dátum. MSP, ktorí používajú Datto pre svojich klientov, narážajú na tento problém pomerne pravidelne, najmä po ransomwarových incidentoch, kde sa súrne obnovujú niekoľko stoviek schránok naraz. To nie je ten správny moment na zistenie, že všetky dátumy sú nesprávne.

AvePoint a Synology Active Backup

AvePoint Cloud Backup a Synology Active Backup for Microsoft 365 fungujú na podobných mechanizmoch. AvePoint toto správanie zdokumentoval vo svojej znalostnej báze (správa sa obnoví s dátumom obnovy ako viditeľným dátumom prijatia), bez ponúknutia natívnej opravy. Synology Active Backup má rovnaký problém, umocnený tým, že obnovovacie rozhranie jasne nerozlišuje medzi "dátumom správy" a "dátumom obnovy".

Dobrá správa: pôvodný dátum je stále tam

To, čo situáciu robí napraviteľnou, je skutočnosť, že pôvodná hlavička Date: správy nebola zmenená. Je stále prítomná, neporušená, v tele každého obnoveného emailu. Obnova zmenila dátum, ktorý si schránka zaznamenala, a niekedy pridala aj riadok Received: navrch, ale nedotkla sa samotného obsahu správy.

Ide o vlastnosť formátu MIME (RFC 2822): správa je nemenná vo svojej internej štruktúre. Hlavičky Received: sa vrstvami hromadia navrchu, ale pôvodné informácie zostávajú pod nimi.

Takže nie, informáciu ste nestratili. Je len skrytá artefaktom reinzercie.

Prečo opätovná obnova nie je riešenie

Prvá myšlienka, ktorá príde na um: vymazať obnovené emaily a spustiť obnovu znova v nádeji, že tentokrát budú dátumy správne. To je zlý nápad, z niekoľkých dôvodov.

Po prvé, zálohovacie nástroje sa pri druhom prechode nebudú správať inak. Ten istý nástroj, to isté nastavenie: emaily sa zapíšu naspäť rovnakým spôsobom, bez ich pôvodného dátumu. Dostanete presne ten istý výsledok.

Po druhé, spustenie obnovy na produkčných schránkach znova znamená čas, šírku pásma a riziko. Pri 50 schránkach s 20 000 správami každá ide o operáciu trvajúcu niekoľko hodín, ktorá monopolizuje API a môže spustiť limity rýchlosti na strane Microsoftu alebo Googlu (ten neslávny 429 Too Many Requests o 2:00 ráno počas dávky).

Skrátka: obnova fungovala. Dáta sú na mieste. To, čo treba opraviť, je artefakt dátumu, nie obnova samotná.

Oprava vlastnými silami: konkrétne riziká

Porozumieť problému je jedna vec. Opraviť ho na 80 000 emailoch bez straty jediného je vec druhá.

Python skript, ktorý prechádza IMAP správy a opravuje dátumy, môže vyzerať realizovateľne. Na 50 testovacích emailoch bude fungovať výborne. V produkcii je to iné. Hraničné prípady sa hromadia: S/MIME podpísané emaily (úprava hlavičky zneplatní kryptografický podpis), PGP šifrované správy, multipart štruktúry s neštandardnými MIME hranicami, hlavičky kódované v RFC 2047 (non-ASCII), prílohy s veľkosťou 40 MB, ktoré preťažia pamäť skriptu. A emaily s viacerými pridanými hlavičkami Received: (ak bola obnova čiastočne zopakovaná, čo sa stáva), ktoré vyžadujú jemnejšiu detekčnú logiku.

Vlastne, skutočné riziko nie je skript, ktorý zlyháva: je to skript, ktorý beží bez zjavnej chyby, ale produkuje poškodené správy. Rozbitá vlákna diskusií. Duplikáty. Oddelené prílohy. Čo si možno nevšimnete niekoľko týždňov, kým sa používateľ nepokúsi nájsť dôležitý email.

A ako overíte, že každý opravený email je po úprave skutočne neporušený? Domáci skript to väčšinou nerobí.

Čo robí Redate.io inak

Redate.io analyzuje reťazec hlavičiek každého emailu, aby identifikoval artefakty reinzercie, či pochádzajú z obnovy Veeam, migrácie BitTitan, alebo manuálneho importu. Proprietárny opravný engine nepotrebuje vedieť, ktorý nástroj chybu spôsobil: vyhľadáva emaily, ktorých zobrazený dátum nezodpovedá ich pôvodnému dátumu, takže odhalí aj nástroj, o ktorom ešte nikto nepočul.

Pred akoukoľvek opravou Redate.io naskenuje celú schránku a predloží správu: koľko emailov je postihnutých, aký je nesprávny dátum, aký pôvodný dátum bol zistený. Tento sken je bezplatný. Rozsah problému vidíte skôr, než sa rozhodnete konať.

Každý email je po oprave individuálne overený. Redate.io originály nikdy nevymaže, zostávajú vo viditeľnom záložnom priečinku vašej schránky, kým ich sami neodstránite.

Každý používateľ sa prihlási svojím kontom Microsoft alebo účtom Google a Redate.io otvorí presne tú schránku, ku ktorej toto prihlásenie udeľuje prístup, pričom žiadny email neprechádza cez sprostredkovateľské servery. Oprava prebieha priamo v schránke, bez exportu ani reimportu.

Pre MSP, ktorí spravujú viacero súčasne postihnutých klientov, pozri stránku venovanú MSP: Redate.io umožňuje spracovať viacero schránok paralelne z jedného rozhrania.

Ďalšie scenáre, ktoré produkujú rovnaký artefakt

Obnova zo zálohovacieho nástroja nie je jediný prípad. Rovnaký artefakt dátumu sa objavuje v iných situáciách:

• Import IMAP z Exchange (archivované schránky reinzerované do Exchange Online)
• Migrácia na Exchange Online s nástrojmi, ktoré na cieľovej strane používajú IMAP
• Granulárna obnova z exportovaného PST, ktorý bol následne reimportovaný (pozri článok o importe PST)
• Zdieľané schránky zrekonštruované po incidente (pozri opravu zdieľaných schránok)

Vo všetkých týchto prípadoch je základný mechanizmus rovnaký: reinzercia, ktorá neprenáša pôvodný dátum (niekedy s novou hlavičkou Received: navrch), a poštový klient, ktorý tento nový dátum zobrazuje ako referenčný.

Emaily sú tam, pôvodný dátum je zachovaný v každej správe. Spustite bezplatný sken na Redate.io a zistite presne, koľko emailov je vo vašej schránke postihnutých. Potom sa rozhodnete, či chcete spustiť opravu.