Veeam/Datto: e-mails dateret ved gendannelse, ikke afsendelse

Dagen efter gendannelsen begynder billetterne at ryge ind

Du har netop afsluttet en postkassegendannelse via Veeam Backup for Microsoft 365. Operationen gik fint, dataene er der, mapperne er intakte. Og så, mandag morgen, skriver en bruger til dig: "Alle mine e-mails har fået dags dato. Jeg kan slet ikke finde noget."

Problemet er ikke, at e-mails er forsvundet. De er der. Men den viste dato svarer til tidspunktet for gendannelsen, ikke den dato, de blev sendt eller modtaget. En e-mail fra januar 2021 vises som modtaget i aftes klokken 23:47. Samtaletråde er brudt. Kronologien er ulæselig.

Denne adfærd rammer Veeam Backup for Microsoft 365, Datto SaaS Protection, Synology Active Backup for Microsoft 365 og AvePoint Cloud Backup, blandt andre. Hver på sin måde, men resultatet er identisk.

Hvad der teknisk set sker

For at forstå, hvor den forkerte dato kommer fra, skal man se på, hvordan disse værktøjer genindsætter e-mails i en Exchange Online- eller Google Workspace-postkasse.

Når et backup-værktøj gendanner en besked, kan det ikke bare "lægge e-mailen tilbage" som at flytte en fil på en lokal disk. Det skriver en ny kopi af beskeden ind i postkassen, via IMAP eller via udbyderens API (EWS eller Microsoft Graph hos Microsoft, Gmail API hos Google). Og sammen med kopien skal det angive, hvilken dato beskeden bærer.

Og dér begynder problemet. (Hvis du nogensinde har læst de rå headers på en gendannet e-mail, har du sikkert set en snes Received:-linjer rulle forbi, inden du fandt det faktiske indhold.)

IMAP APPEND og Received:-headeren

IMAP-protokollen har en kommando ved navn APPEND. Den bruges til at indsætte en besked i en postkasse. Det er præcis, hvad et gendannelsesværktøj anvender: det tager den gemte besked og injicerer den i destinationspostkassen via IMAP APPEND.

Denne kommando lader værktøjet angive en dato sammen med beskeden. Hvis værktøjet angiver beskedens oprindelige dato, bevarer postkassen den: det gælder for Microsoft 365, Outlook.com og Gmail. Hvis det ikke angiver noget, eller angiver datoen for gendannelsen, arkiverer postkassen e-mailen under gendannelsens dato. Og nogle måder at skrive en besked tilbage på tilføjer endnu en linje øverst: en Received:-header dateret til kopieringens dag. Gmails egen import-API gør netop det.

Denne ekstra linje ligner noget i stil med:

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

Resultatet: den originale e-mail er intakt indeni, med sin originale Date:-header (lad os sige "3 Jan 2021 09:15:00"). Men en ny Received:-header er klistret øverst, dateret til gendannelsestidspunktet.

Hvordan Outlook og Gmail læser datoen

E-mailklienter som Outlook eller Gmails webgrænseflade læser ikke altid Date:-headeren for at bestemme, hvilken dato der vises i beskedlisten. Mange bruger INTERNALDATE fra IMAP-protokollen, altså den dato, beskeden blev tilføjet til postkassen, eller den nyeste Received:-header.

Outlook til Windows, særligt siden opdateringen i slutningen af 2023, er specielt følsom over for dette. Når den ser en nylig Received:-header øverst i kæden, bruger den den som visningsdato. Den originale Date: havner i beskeddetaljerne, synlig kun hvis man åbner e-mailens egenskaber.

Slutbrugeren ser altså en liste med beskeder, der alle er dateret til natten for gendannelsen. For vedkommende er tre års historik pludselig skrumpet ind til én enkelt nat.

Dette problem er forskelligt fra en migrering

Det er vigtigt at skelne fra det klassiske problem med forkerte datoer efter IMAP-migrering. Ved en migrering flytter værktøjet e-mails fra server A til server B, og om hver e-mail bevarer sin dato afhænger af, hvad værktøjet fortæller server B, når den skrives. Mekanikken er den samme, men konteksten er anderledes.

Her taler vi om en gendannelse fra en backup. E-mails har aldrig forladt organisationen, de er blot blevet opbevaret et sted (Azure Blob Storage, AWS S3, Datto-appliance...) og derefter genindsattet. Brugeren forventer det endnu mindre: for vedkommende er det "sine egne" e-mails, der vender tilbage, ikke importerede e-mails.

Men teknisk set er mekanikken den samme. En geninjektion, der ikke bærer den oprindelige dato, producerer de samme artefakter. Og rettelsen følger den samme logik.

Hvordan hvert værktøj håndterer (eller ikke håndterer) INTERNALDATE

Ikke alle værktøjer opfører sig helt ens, og det er her tingene bliver interessante.

Veeam Backup for Microsoft 365

Veeam bruger EWS API (Exchange Web Services) til at gendanne mod Exchange Online. EWS giver mulighed for at angive beskedens dato via feltet DateTimeReceived, men denne værdi afspejles ikke altid i INTERNALDATE på IMAP-niveau. Resultat: sorteringsdatoen i Outlook svarer ikke nødvendigvis til den originale dato, især hvis gendannelsen sker til en anden postkasse end den originale (granulær gendannelse til en alternativ postkasse, for eksempel).

Datto SaaS Protection

Datto gendanner via Microsoft Graph API eller IMAP, afhængigt af konfigurationen. I begge tilfælde afhænger den dato, postkassen viser, af, om gendannelsen angiver hver beskeds oprindelige dato. MSP'er, der bruger Datto til deres kunder, støder på dette problem temmelig jævnligt, især efter ransomware-hændelser, hvor man i en fart gendanner flere hundrede postkasser på én gang. Det er ikke det rette tidspunkt at opdage, at alle datoerne er forkerte.

AvePoint og Synology Active Backup

AvePoint Cloud Backup og Synology Active Backup for Microsoft 365 følger lignende mekanismer. AvePoint har dokumenteret denne adfærd i sin vidensbase (beskeden gendannes med gendannelsesdatoen som synlig modtagelsesdato), uden dog at tilbyde en native rettelse. Synology Active Backup har samme problem, forstærket af, at gendannelsesgrænsefladen ikke klart skelner mellem "beskedens dato" og "gendannelsesdatoen".

Den gode nyhed: den originale dato er stadig der

Det, der gør situationen redningsbar, er, at den originale Date:-header i beskeden ikke er blevet ændret. Den er stadig til stede, intakt, i hver eneste gendannet e-mail. Gendannelsen har ændret den dato, postkassen registrerede, og har nogle gange tilføjet en Received:-linje ovenpå, men har ikke rørt ved selve beskedens indhold.

Det er en egenskab ved MIME-formatet (RFC 2822): en besked er uforanderlig i sin interne struktur. Received:-headers akkumuleres øverst som lag, men de originale oplysninger er stadig nedenunder.

Så nej, du har ikke mistet informationen. Den er blot skjult af et geninjektion-artefakt.

Hvorfor en ny gendannelse ikke er løsningen

Den første tanke, der melder sig: slet de gendannede e-mails og kør gendannelsen igen i håbet om, at datoerne denne gang er korrekte. Det er en dårlig idé, af flere årsager.

For det første vil gendannelsesværktøjerne ikke opføre sig anderledes ved andet forsøg. Samme værktøj, samme indstillinger: e-mailene skrives tilbage på samme måde, uden deres oprindelige dato. Du vil få nøjagtigt det samme resultat.

Derudover er det at køre en ny gendannelse på produktionspostkasser en tidskrævende, båndbredde-intensiv og risikabel operation. Med 50 postkasser à 20.000 beskeder taler vi om en operation på flere timer, der lægger beslag på API'erne og kan udløse rate limits hos Microsoft eller Google (den velkendte 429 Too Many Requests klokken 2 om natten under et migreringsbatch).

Kort sagt: gendannelsen har virket. Dataene er der. Det, der skal rettes, er dato-artefaktet, ikke gendannelsen i sig selv.

At rette det selv: de konkrete risici

At forstå problemet er én ting. At rette det på 80.000 e-mails uden at miste en eneste er noget ganske andet.

Et Python-script, der gennemgår IMAP-beskeder og retter datoerne, kan virke overkommeligt. Og på 50 test-e-mails vil det fungere fint. I produktion er det en anden sag. Edge cases hober sig op: S/MIME-signerede e-mails (ændring af headeren ugyldiggør den kryptografiske signatur), PGP-krypterede beskeder, multipart-strukturer med ikke-standardiserede MIME-grænser, RFC 2047-kodede headers (non-ASCII), 40 MB-vedhæftninger der sprænger scriptets hukommelse. Og e-mails med flere tilføjede Received:-headers (hvis gendannelsen er kørt delvist om igen, hvilket sker), der kræver mere subtil detektionslogik.

For at sige det præcist: den reelle risiko er ikke scriptet, der fejler. Det er scriptet, der kører tilsyneladende fejlfrit, men producerer korrupte beskeder. Ødelagte samtaletråde. Dubletter. Løsrevne vedhæftninger. Som du måske først opdager uger senere, når en bruger forsøger at finde en vigtig e-mail.

Og hvordan verificerer du, at hver rettet e-mail er helt intakt efter ændringen? Et hjemmelavet script gør det som regel ikke.

Hvad Redate.io gør anderledes

Redate.io analyserer header-kæden i hver e-mail for at identificere geninjektion-artefakter, uanset om de stammer fra en Veeam-gendannelse, en BitTitan-migrering eller en manuel import. Den proprietære korrektionsmotor behøver ikke at vide, hvilket værktøj der har forårsaget skaden: den finder e-mails, hvis viste dato ikke stemmer med deres oprindelige dato, så selv et værktøj, ingen har hørt om, bliver fanget.

Inden noget som helst rettes, scanner Redate.io hele postkassen og præsenterer en rapport: hvor mange e-mails er berørt, hvad er den forkerte dato, og hvad er den opdagede originale dato. Dette scan er gratis. Du ser omfanget af problemet, inden du beslutter dig for at handle.

Hver e-mail verificeres individuelt efter korrektion. Originalerne opbevares i en synlig backup-mappe i din egen postkasse, indtil du selv sletter dem, hvilket giver et komplet sikkerhedsnet, hvis det skulle blive nødvendigt.

Hver bruger logger ind med sin egen Microsoft- eller Google-konto, og Redate.io åbner kun denne postkasse med den adgang, login giver, uden at nogen e-mails passerer gennem mellemliggende servere. Korrektionen sker på stedet, i postkassen, uden eksport eller reimport.

For MSP'er, der håndterer flere berørte kunder samtidig, se siden dedikeret til MSP'er: Redate.io gør det muligt at behandle flere postkasser parallelt fra én enkelt grænseflade.

Andre scenarier, der producerer det samme artefakt

Gendannelse fra et backup-værktøj er ikke det eneste tilfælde. Det samme dato-artefakt opstår i andre situationer:

• IMAP-import fra Exchange (arkiverede postkasser genindsattet i Exchange Online)
• Migrering til Exchange Online med værktøjer, der bruger IMAP på destinationssiden
• Granulær gendannelse fra en eksporteret PST, der derefter reimporteres (se artiklen om PST-import)
• Delte postkasser rekonstrueret efter en hændelse (se rettelse af delte postkasser)

I alle disse tilfælde er den underliggende mekanik identisk: en geninjektion, der ikke bærer den oprindelige dato (nogle gange med en ny Received:-header ovenpå), og en e-mailklient, der viser denne nye dato som reference.

E-mails er der, og den originale dato er bevaret i hver besked. Kør et gratis scan på Redate.io for at se præcis, hvor mange e-mails der er berørt i din postkasse, og beslut derefter, om du vil sætte korrektionen i gang.