Veeam/Datto: e-maily datované dobou obnovy, ne odesláním

Druhý den po obnově přicházejí tikety

Právě jste dokončili obnovu poštovní schránky přes Veeam Backup for Microsoft 365. Operace proběhla v pořádku, data jsou na místě, složky jsou nedotčené. A pak v pondělí ráno Vám uživatel napíše: "Všechny moje e-maily mají dnešní datum. Nic nemůžu najít."

Problém není v tom, že by e-maily zmizely. Jsou tam. Ale zobrazené datum odpovídá přesné době obnovy, ne datu, kdy byly odeslány nebo přijaty. E-mail z ledna 2021 se tváří, jako by byl přijat včera večer v 23:47. Vlákno konverzace je rozbitě. Chronologie je nečitelná.

Toto chování se týká Veeam Backup for Microsoft 365, Datto SaaS Protection, Synology Active Backup for Microsoft 365 a AvePoint Cloud Backup, mimo jiné. Každý nástroj po svém, ale výsledek je stejný.

Co se děje na technické úrovni

Abychom pochopili, odkud se bere špatné datum, musíme se podívat na to, jak tyto nástroje reinjectují e-maily zpět do schránky Exchange Online nebo Google Workspace.

Když zálohovací nástroj obnovuje zprávu, nemůže jednoduše e-mail "vrátit na místo" jako při přesunu souboru na lokálním disku. Nástroj zapíše do schránky novou kopii zprávy, a to přes IMAP nebo přes API poskytovatele (EWS nebo Microsoft Graph na straně Microsoftu, Gmail API na straně Googlu). A s touto kopií musí schránce sdělit, jaké datum zpráva nese.

A tady problém začíná. (Mimochodem, pokud jste někdy četli nezpracované hlavičky obnoveného e-mailu, pravděpodobně jste viděli přibližně dvacet řádků Received: ještě než jste se dostali k samotnému obsahu.)

Příkaz IMAP APPEND a hlavička Received:

Protokol IMAP obsahuje příkaz APPEND. Slouží k vložení zprávy do poštovní schránky. Přesně to používá nástroj pro obnovu: vezme uloženou zprávu a vloží ji do cílové schránky.

Tento příkaz umožňuje nástroji předat s e-mailem datum. Pokud nástroj předá původní datum zprávy, schránka si ho zachová: platí to pro Microsoft 365, Outlook.com i Gmail. Pokud nepředá žádné datum, nebo předá datum obnovy, schránka e-mail zařadí podle dne obnovy. A některé způsoby zpětného zápisu zprávy přidají na začátek ještě jeden řádek: hlavičku Received: s datem dne kopie. Přesně to dělá importní API Gmailu.

Tento další řádek vypadá přibližně takto:

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

Výsledek: původní e-mail je uvnitř nedotčen, s původní hlavičkou Date: (například "3 Jan 2021 09:15:00"). Ale navrch byla přilepena nová hlavička Received: s datem obnovy.

Jak Outlook a Gmail čtou datum

E-mailoví klienti jako Outlook nebo webové rozhraní Gmailu ne vždy čtou hlavičku Date: pro rozhodnutí, jaké datum zobrazit v seznamu zpráv. Mnozí používají INTERNALDATE protokolu IMAP, tedy datum, kdy byla zpráva přidána do schránky, nebo nejnovější hlavičku Received:.

Outlook pro Windows, zvláště od aktualizace koncem roku 2023, je na toto obzvláště citlivý. Když vidí nedávnou hlavičku Received: na vrcholu řetězce, použije ji jako zobrazované datum. Původní Date: je odsunuto do detailů zprávy, viditelné jen při otevření vlastností e-mailu.

Koncový uživatel pak vidí seznam zpráv, kde všechny mají datum noci obnovy. Pro něj se třetí história e-mailů za tři roky zploštila do jedné noci.

Tento problém se liší od migrace

Je třeba rozlišovat od klasického problému chybných dat po migraci IMAP. Při migraci nástroj přesouvá e-maily ze serveru A na server B a zda si každý e-mail zachová své datum, závisí na tom, co nástroj serveru B sdělí při zápisu. Jde o stejný mechanismus, ale v jiném kontextu.

Tady mluvíme o obnově ze zálohy. E-maily organizaci nikdy neopustily, byly jen zabezpečeny někde jinde (Azure Blob Storage, AWS S3, zařízení Datto...) a pak reinjectovány zpět. Uživatel to čeká ještě méně: pro něj se vrací "jeho" e-maily, ne importované zprávy odjinud.

Technicky je ale mechanismus stejný. Reinjectování, které nenese původní datum, produkuje stejné artefakty. A oprava se řídí stejnou logikou.

Jak jednotlivé nástroje pracují (nebo nepracují) s INTERNALDATE

Všechny nástroje se nechovají úplně stejně, a tady to začíná být zajímavé.

Veeam Backup for Microsoft 365

Veeam používá pro obnovu do Exchange Online API EWS (Exchange Web Services). EWS umožňuje specifikovat datum zprávy přes pole DateTimeReceived, ale tato hodnota se ne vždy promítne do INTERNALDATE na úrovni IMAP. Výsledek: datum třídění v Outlooku nemusí odpovídat původnímu datu, zvláště při obnově do jiné schránky, než byla původní (granulární obnova do alternativní schránky).

Datto SaaS Protection

Datto obnovuje přes Microsoft Graph API nebo IMAP podle konfigurace. V obou případech závisí datum, které schránka zobrazí, na tom, zda obnova předá původní datum každé zprávy. MSP, kteří pro své klienty používají Datto, se s tímto problémem setkávají poměrně pravidelně, zejména po ransomwarových incidentech, kdy se urgentně obnovují stovky schránek najednou. To není správná chvíle zjistit, že všechna data jsou špatně.

AvePoint a Synology Active Backup

AvePoint Cloud Backup a Synology Active Backup for Microsoft 365 fungují na podobných principech. AvePoint toto chování zdokumentoval ve své znalostní bázi (zpráva je obnovena s datem obnovy jako viditelným datem přijetí), aniž by nabídl nativní opravu. Synology Active Backup má stejný problém, navíc umocněný tím, že rozhraní pro obnovu jasně nerozlišuje "datum zprávy" od "data obnovy".

Dobrá zpráva: původní datum je stále tam

Co situaci zachraňuje, je skutečnost, že původní hlavička Date: zprávy nebyla změněna. Je stále přítomna, nedotčena, v těle každého obnoveného e-mailu. Obnova změnila datum, které si schránka zaznamenala, a někdy navrch přidala řádek hlavičky Received:, ale nesáhla na samotný obsah zprávy.

To je vlastnost formátu MIME (RFC 2822): zpráva je ve své vnitřní struktuře neměnná. Hlavičky Received: se hromadí nahoře jako vrstvy, ale původní informace zůstávají níže.

Takže ne, informaci jste neztratili. Je jen zakryta artefaktem reinjectování.

Proč znovu spustit obnovu není řešení

První nápad, který přijde na mysl: smazat obnovené e-maily a spustit obnovu znovu s nadějí, že tentokrát budou data správná. To je špatný nápad, a to hned z několika důvodů.

Za prvé, nástroje pro obnovu se při druhém průchodu nezachovají jinak. Stejný nástroj, stejná nastavení: e-maily se zapíšou zpět stejným způsobem, bez svého původního data. Dostanete přesně stejný výsledek.

Za druhé, spouštět obnovu znovu na produkčních schránkách znamená čas, šířku pásma a riziko. U 50 schránek s 20 000 zprávami každá se bavíme o operaci trvající několik hodin, která monopolizuje API a může vyvolat omezení rychlosti na straně Microsoftu nebo Googlu (ten slavný 429 Too Many Requests ve 2 ráno uprostřed dávkového zpracování).

Zkrátka. Obnova proběhla úspěšně. Data jsou tam. Co je potřeba opravit, je artefakt data, ne samotná obnova.

Oprava vlastními silami: konkrétní rizika

Pochopit problém je jedna věc. Opravit ho na 80 000 e-mailech bez ztráty jediného je věc druhá.

Python skript, který prochází IMAP zprávy a opravuje jejich datum, může vypadat jako schůdné řešení. Na 50 testovacích e-mailech bude fungovat skvěle. V produkci je to jiné. Okrajové případy se hromadí: e-maily podepsané S/MIME (úprava hlavičky zruší kryptografický podpis), zprávy šifrované PGP, struktury multipart s nestandardními MIME hranicemi, hlavičky kódované podle RFC 2047 (non-ASCII), přílohy o velikosti 40 MB, které přetíží paměť skriptu. A e-maily s více přidanými hlavičkami Received: (pokud byla obnova částečně zopakována, což se stává), které vyžadují jemnější logiku detekce.

Přesněji řečeno, skutečné riziko není skript, který havaruje: je to skript, který běží bez viditelné chyby, ale produkuje poškozené zprávy. Rozbitá vlákna konverzací. Duplikáty. Odtržené přílohy. Které možná odhalíte až o několik týdnů později, když uživatel bude hledat důležitý e-mail.

A jak ověříte, že každý opravený e-mail je po úpravě skutečně v pořádku? Domácí skript to zpravidla nezajistí.

Co dělá Redate.io jinak

Redate.io analyzuje řetězec hlaviček každého e-mailu za účelem identifikace artefaktů reinjectování, ať už pocházejí z obnovy Veeam, migrace BitTitan, nebo ručního importu. Proprietární korekční engine nepotřebuje znát nástroj, který chybu způsobil: vyhledává e-maily, jejichž zobrazené datum neodpovídá jejich původnímu datu, takže odhalí i nástroj, o kterém nikdy neslyšel.

Než Redate.io cokoliv opraví, prohledá celou schránku a předloží přehled: kolik e-mailů je ovlivněno, jaké je chybné datum a jaké původní datum bylo detekováno. Tento sken je zdarma. Vidíte rozsah problému ještě před rozhodnutím, zda chcete zahájit opravu.

Každý e-mail je po opravě individuálně ověřen. Originály zůstávají ve viditelné záložní složce Vaší schránky, dokud je sami neodstraníte, což poskytuje úplnou záchrannou síť v případě potřeby.

Uživatel se přihlásí svým účtem Microsoft nebo Google, a Redate.io tak získá přístup přímo k jeho schránce, aniž by jakýkoli e-mail procházel přes prostřední servery. Oprava probíhá přímo na místě, ve schránce, bez exportu nebo reimportování.

Pro MSP spravující více klientů zasažených současně viz stránka věnovaná MSP: Redate.io umožňuje zpracovat několik schránek paralelně z jediného rozhraní.

Další scénáře, které produkují stejný artefakt

Obnova ze zálohovacího nástroje není jediný případ. Stejný artefakt data se objevuje v dalších situacích:

• Import IMAP z Exchange (archivované schránky reinjectované do Exchange Online)
• Migrace do Exchange Online s nástroji, které na cílové straně používají IMAP
• Granulární obnova z PST exportovaného a pak znovu importovaného (viz článek o importu PST)
• Sdílené poštovní schránky obnovené po incidentu (viz oprava sdílených schránek)

Ve všech těchto případech je podkladový mechanismus identický: reinjectování, které nenese původní datum (někdy s novou hlavičkou Received: navrch), a e-mailový klient, který toto nové datum zobrazí jako referenční.

E-maily jsou tam, původní datum je zachováno v každé zprávě. Spusťte bezplatný sken na Redate.io a zjistěte přesně, kolik e-mailů je ve Vaší schránce ovlivněno, a pak se rozhodněte, zda chcete zahájit opravu.