Veeam/Datto: e-poster datert til gjenoppretting, ikke sending

Dagen etter gjenopprettingen begynner henvendelsene

Du har akkurat fullført en gjenoppretting av en postboks via Veeam Backup for Microsoft 365. Alt gikk greit, dataene er på plass, mappene er intakte. Og så, mandag morgen, skriver en bruker til deg: "Alle e-postene mine har fått dagens dato. Jeg finner ingenting."

Problemet er ikke at e-postene har forsvunnet. De er der. Men datoen som vises tilsvarer nøyaktig tidspunktet for gjenopprettingen, ikke datoen de ble sendt eller mottatt. En e-post fra januar 2021 fremstår som mottatt i går kveld klokken 23:47. Samtaletråden er brutt. Tidslinjen er uleselig.

Dette problemet rammer Veeam Backup for Microsoft 365, Datto SaaS Protection, Synology Active Backup for Microsoft 365 og AvePoint Cloud Backup, blant andre. Hvert verktøy gjør det på sin måte, men resultatet er det samme.

Hva som skjer teknisk

For å forstå hvor den uriktige datoen kommer fra, må man se på hvordan disse verktøyene injiserer e-poster tilbake i en Exchange Online- eller Google Workspace-postboks.

Når et backupverktøy gjenoppretter en melding, kan det ikke bare "legge e-posten tilbake på plass" slik man ville flyttet en fil på en lokal disk. Verktøyet skriver en ny kopi av meldingen inn i postboksen, via IMAP eller via leverandørens API (EWS eller Microsoft Graph på Microsoft-siden, Gmail-API-et på Google-siden). Og sammen med den kopien må det fortelle postboksen hvilken dato meldingen har.

Og det er her problemet starter. (Forresten, hvis du noen gang har lest rå e-posthoder på en gjenopprettet melding, har du sannsynligvis sett to dusin Received:-linjer rulle forbi før du finner det faktiske innholdet.)

IMAP APPEND og Received:-hodet

IMAP-protokollen har en kommando kalt APPEND. Den brukes til å sette inn en melding i en postboks. Det er nøyaktig dette et gjenopprettingsverktøy gjør: det henter den sikkerhetskopierten meldingen og injiserer den i målpostboksen via IMAP APPEND.

Denne kommandoen lar verktøyet sende med en dato sammen med meldingen. Hvis verktøyet sender med e-postens opprinnelige dato, beholder postboksen den: det gjelder Microsoft 365, Outlook.com og Gmail. Hvis verktøyet ikke sender med noen dato, eller sender datoen for gjenopprettingen, arkiverer postboksen e-posten under datoen for gjenopprettingen. Og noen måter å skrive meldingen tilbake på legger til enda en linje øverst: et Received:-hode datert til kopieringsdagen. Det er nøyaktig det Gmails eget import-API gjør.

Den nye linjen ser omtrent slik ut:

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

Resultatet: den originale e-posten er intakt inni, med sitt opprinnelige Date:-hode (si "3 Jan 2021 09:15:00"). Men et nytt Received:-hode er limt øverst, datert til gjenopprettingstidspunktet.

Hvordan Outlook og Gmail leser datoen

E-postklienter som Outlook eller Gmails nettgrensesnitt leser ikke alltid Date:-hodet for å avgjøre hvilken dato som skal vises i meldingslisten. Mange bruker INTERNALDATE fra IMAP-protokollen, altså datoen meldingen ble lagt til i postboksen, eller det nyeste Received:-hodet.

Outlook for Windows, særlig etter oppdateringen i slutten av 2023, er spesielt følsom for dette. Når den ser et nylig Received:-hode øverst i kjeden, brukes det som visningsdato. Det opprinnelige Date:-hodet havner i meldingsdetaljene, synlig bare hvis man åpner e-postens egenskaper.

Sluttbrukeren ser altså en meldingsliste der alt er datert til natten for gjenopprettingen. For dem har tre års e-posthistorikk plutselig kollapset til én natt.

Dette er forskjellig fra en migrering

Det er viktig å skille dette fra det klassiske problemet med feil datoer etter IMAP-migrering. Ved en migrering flytter verktøyet e-poster fra server A til server B, og om hver e-post beholder datoen sin, avhenger av hva verktøyet forteller server B når den skriver meldingen. Mekanikken er den samme, men konteksten er annerledes.

Her snakker vi om gjenoppretting fra en sikkerhetskopi. E-postene har aldri forlatt organisasjonen, de ble bare lagret et sted (Azure Blob Storage, AWS S3, Datto-appliance...) og så re-injisert. Brukeren forventer det enda mindre: for dem er det "sine egne" e-poster som kommer tilbake, ikke importerte meldinger.

Men teknisk sett er mekanismen identisk. En re-injeksjon som ikke bærer med seg den opprinnelige datoen, produserer de samme artefaktene. Og løsningen følger den samme logikken.

Hvordan hvert verktøy håndterer (eller ikke håndterer) INTERNALDATE

Ikke alle verktøy oppfører seg nøyaktig likt, og det er her ting blir interessant.

Veeam Backup for Microsoft 365

Veeam bruker EWS-API-et (Exchange Web Services) for å gjenopprette til Exchange Online. EWS lar deg spesifisere meldingsdatoen via feltet DateTimeReceived, men denne verdien reflekteres ikke alltid i INTERNALDATE på IMAP-nivå. Resultatet: sorteringsdatoen i Outlook samsvarer kanskje ikke med den opprinnelige datoen, særlig hvis gjenopprettingen skjer til en annen postboks enn originalen (granulær gjenoppretting til en alternativ postboks, for eksempel).

Datto SaaS Protection

Datto gjenoppretter via Microsoft Graph API eller IMAP avhengig av konfigurasjonen. I begge tilfeller avhenger datoen postboksen viser, av om gjenopprettingen sender med den opprinnelige datoen for hver melding. MSP-er som bruker Datto for sine kunder støter på dette problemet ganske jevnlig, særlig etter ransomware-hendelser der man akutt gjenoppretter flere hundre postbokser på en gang. Det er ikke det øyeblikket du vil oppdage at alle datoene er feil.

AvePoint og Synology Active Backup

AvePoint Cloud Backup og Synology Active Backup for Microsoft 365 følger tilsvarende mekanismer. AvePoint har dokumentert denne oppførselen i sin kunnskapsbase (meldingen gjenopprettes med gjenopprettingsdatoen som synlig mottaksdato), uten å tilby en innebygd løsning. Synology Active Backup har det samme problemet, forsterket av at gjenopprettingsgrensesnittet ikke tydelig skiller mellom "meldingsdato" og "gjenopprettingsdato".

Godt nytt: den opprinnelige datoen er fortsatt der

Det som gjør situasjonen mulig å redde, er at det opprinnelige Date:-hodet i meldingen ikke er endret. Det er fremdeles til stede, intakt, i hver gjenopprettet e-post. Gjenopprettingen har endret datoen postboksen registrerte, og har noen ganger lagt en Received:-linje oppå, men har ikke rørt selve meldingsinnholdet.

Det er en egenskap ved MIME-formatet (RFC 2822): en melding er uforanderlig i sin interne struktur. Received:-hodene akkumuleres øverst som lag, men den opprinnelige informasjonen ligger urørt under.

Så nei, du har ikke mistet informasjonen. Den er bare skjult av et re-injeksjonsartefakt.

Hvorfor det ikke hjelper å kjøre gjenopprettingen på nytt

Den første tanken er gjerne: slett de gjenopprettede e-postene og kjør gjenopprettingen på nytt i håp om at datoene blir riktige denne gangen. Det er en dårlig idé, av flere grunner.

For det første vil ikke gjenopprettingsverktøyene oppføre seg annerledes på andre forsøk. Samme verktøy, samme innstillinger: e-postene skrives tilbake på samme måte, uten sin opprinnelige dato. Du får nøyaktig det samme resultatet.

Dernest er det å kjøre gjenoppretting på nytt på produksjonspostbokser tidkrevende, båndbreddekrevende og risikabelt. Med 50 postbokser og 20 000 meldinger i hver snakker vi om en operasjon på flere timer som monopoliserer API-ene og kan utløse ratebegrensninger hos Microsoft eller Google (den klassiske 429 Too Many Requests-feilen klokken 02:00 midt i en batchjobb).

Gjenopprettingen fungerte. Dataene er der. Det som må korrigeres er datoartefaktet, ikke selve gjenopprettingen.

Å fikse det selv: de konkrete risikoene

Å forstå problemet er én ting. Å korrigere 80 000 e-poster uten å miste én eneste er noe helt annet.

Et Python-skript som går gjennom IMAP-meldingene og korrigerer datoene kan virke overkommelig. Og på 50 test-e-poster vil det fungere utmerket. I produksjon er det annerledes. Kanttilfellene hope seg opp: S/MIME-signerte e-poster (å endre hodet ugyldiggjør den kryptografiske signaturen), PGP-krypterte meldinger, multipart-strukturer med ikke-standard MIME-grenser, hoder kodet etter RFC 2047 (ikke-ASCII), vedlegg på 40 MB som sprengt skriptets minne. Og e-poster med flere Received:-hoder som ble lagt til (hvis gjenopprettingen ble delvis kjørt på nytt, noe som skjer), og som krever mer sofistikert deteksjonslogikk.

For å være presis: den virkelige risikoen er ikke skriptet som krasjer. Det er skriptet som kjører uten synlige feil men produserer korrupte meldinger. Ødelagte samtaletråder. Duplikater. Løsrevne vedlegg. Som du kanskje ikke oppdager før flere uker senere, når en bruker prøver å finne en viktig e-post.

Og hvordan verifiserer du at hver korrigert e-post faktisk er intakt etter endringen? Et hjemmelaget skript gjør vanligvis ikke det.

Hva Redate.io gjør annerledes

Redate.io analyserer hodekjeden i hver enkelt e-post for å identifisere re-injeksjonsartefakter, enten de stammer fra en Veeam-gjenoppretting, en BitTitan-migrering eller en manuell import. Den proprietære korrigeringsmotoren behøver ikke å vite hvilket verktøy som forårsaket skaden: den ser etter e-poster der den viste datoen ikke stemmer med den opprinnelige datoen, slik at selv et verktøy ingen har hørt om, blir avslørt.

Før noe korrigeres, skanner Redate.io hele postboksen og presenterer en rapport: hvor mange e-poster er berørt, hvilken dato er feil, og hvilken opprinnelig dato er oppdaget. Skanningen er gratis. Du ser omfanget av problemet før du bestemmer deg for å handle.

Hver enkelt e-post verifiseres individuelt etter korrigering. Originalene slettes aldri av Redate.io. De ligger i en synlig sikkerhetskopieringsmappe i postboksen din til du selv sletter dem.

Redate.io åpner postboksen din med den innloggingen du selv gjør, uten portal og uten applikasjon å registrere. Korrigeringen skjer på stedet, i postboksen, uten eksport eller reimport.

For MSP-er som håndterer flere berørte kunder samtidig, se siden dedikert til MSP-er: Redate.io gjør det mulig å behandle flere postbokser parallelt fra ett enkelt grensesnitt.

Andre scenarier som gir det samme artefaktet

Gjenoppretting fra et backupverktøy er ikke det eneste tilfellet. Det samme datoartefaktet dukker opp i andre situasjoner:

• IMAP-import fra Exchange (arkiverte postbokser re-injisert i Exchange Online)
• Migrering til Exchange Online med verktøy som bruker IMAP på mottakssiden
• Granulær gjenoppretting fra en PST som er eksportert og deretter re-importert (se artikkelen om PST-import)
• Delte postbokser rekonstituert etter en hendelse (se korrigering av delte postbokser)

I alle disse tilfellene er den underliggende mekanikken identisk: en re-injeksjon som ikke bærer med seg den opprinnelige datoen (noen ganger med et nytt Received:-hode oppå), og en e-postklient som viser den nye datoen som referanse.

E-postene er der, og den opprinnelige datoen er bevart i hver melding. Kjør en gratis skanning på Redate.io for å se nøyaktig hvor mange e-poster som er berørt i postboksen din, og bestem deretter om du vil starte korrigeringen.