Veeam/Datto: e-post daterad vid återställning, inte vid sändning

Dagen efter återställningen börjar tickets trilla in

Du har precis avslutat en återställning av en postlåda via Veeam Backup for Microsoft 365. Allt gick bra, datan finns där, mapparna är intakta. Sedan, på måndagsmorgonen, skriver en användare: "Alla mina e-postmeddelanden har dagens datum. Jag hittar ingenting."

Problemet är inte att e-posten har försvunnit. Den finns där. Men det visade datumet motsvarar exakt tidpunkten för återställningen, inte när meddelandena skickades eller togs emot. Ett e-postmeddelande från januari 2021 visas som mottaget igår kväll klockan 23:47. Konversationstråden är trasig. Kronologin är oläslig.

Det här drabbar Veeam Backup for Microsoft 365, Datto SaaS Protection, Synology Active Backup for Microsoft 365 och AvePoint Cloud Backup, bland andra. Varje verktyg på sitt sätt, men resultatet är detsamma.

Vad som händer tekniskt

För att förstå varifrån det felaktiga datumet kommer behöver man titta på hur dessa verktyg återinjicerar e-post i en Exchange Online- eller Google Workspace-postlåda.

När ett backupverktyg återställer ett meddelande kan det inte bara "lägga tillbaka" e-posten som om man flyttade en fil på en lokal disk. Verktyget skriver in en ny kopia av meddelandet i postlådan, via IMAP-protokollet eller via leverantörens API (EWS eller Microsoft Graph på Microsoft-sidan, Gmail API på Google-sidan). Tillsammans med kopian måste det också tala om för postlådan vilket datum meddelandet har.

Och det är där problemet börjar. (Har du någonsin läst råa e-posthuvuden från ett återställt meddelande, vet du att man kan bläddra igenom ett tjugotal Received:-rader innan man hittar det faktiska innehållet.)

IMAP APPEND och Received:-headern

IMAP-protokollet har ett kommando som heter APPEND. Det används för att infoga ett meddelande i en postlåda. Det är precis vad ett återställningsverktyg använder: det tar det sparade meddelandet och injicerar det i målpostlådan via IMAP APPEND.

Det här kommandot låter verktyget skicka med ett datum tillsammans med meddelandet. Om verktyget skickar med meddelandets ursprungliga datum behåller postlådan det: det gäller Microsoft 365, Outlook.com och Gmail. Skickar verktyget inget datum, eller datumet för återställningen, hamnar e-postmeddelandet under återställningsdagen. Och vissa sätt att skriva tillbaka ett meddelande lägger till en extra rad längst upp: en Received:-header daterad till kopieringsdagen. Gmails eget import-API gör precis det.

Den extra raden ser ut ungefär så här:

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

Resultatet: det ursprungliga e-postmeddelandet är intakt inuti, med sin ursprungliga Date:-header (säg "3 Jan 2021 09:15:00"). Men en ny Received:-header har klistrats längst upp, daterad till återställningstidpunkten.

Hur Outlook och Gmail läser datumet

E-postklienter som Outlook eller Gmails webbgränssnitt läser inte alltid Date:-headern för att avgöra vilket datum som ska visas i meddelandelistan. Många använder INTERNALDATE i IMAP-protokollet, alltså det datum då meddelandet lades till i postlådan, eller den senaste Received:-headern.

Outlook för Windows, särskilt sedan uppdateringen i slutet av 2023, är extra känslig för det här. När det ser en ny Received:-header högst upp i kedjan används den som visningsdatum. Den ursprungliga Date:-headern hamnar i meddelandedetaljerna, synlig bara om man öppnar e-postens egenskaper.

Slutanvändaren ser alltså en lista med meddelanden som alla är daterade till natten för återställningen. För denne har tre års e-posthistorik plattat till på en enda natt.

Det här skiljer sig från en migrering

Man ska skilja det här från det klassiska problemet med felaktiga datum efter IMAP-migrering. Vid en migrering flyttar verktyget e-post från server A till server B, och om varje e-postmeddelande behåller sitt datum beror på vad verktyget talar om för server B när det skriver in meddelandet. Det är samma mekanism, men i ett annat sammanhang.

Här handlar det om återställning från backup. E-posten har aldrig lämnat organisationen, den har bara lagrats säkert någonstans (Azure Blob Storage, AWS S3, Datto-apparat...) och sedan återinjicerats. Användaren förväntar sig det ännu mindre: för hen är det "sina" e-postmeddelanden som kommer tillbaka, inte importerade meddelanden.

Men tekniskt sett är mekanismen densamma. En återinjicering som inte bär med sig det ursprungliga datumet ger samma artefakter. Och korrigeringen följer samma logik.

Hur varje verktyg hanterar (eller inte hanterar) INTERNALDATE

Alla verktyg beter sig inte exakt likadant, och det är där det blir intressant.

Veeam Backup for Microsoft 365

Veeam använder EWS API:et (Exchange Web Services) för att återställa till Exchange Online. EWS tillåter att meddelandedatumet anges via fältet DateTimeReceived, men det här värdet återspeglas inte alltid i INTERNALDATE på IMAP-nivå. Resultatet: sorteringsdatumet i Outlook kanske inte stämmer överens med det ursprungliga datumet, särskilt om återställningen sker till en annan postlåda än originalet (granulär återställning till en alternativ postlåda, till exempel).

Datto SaaS Protection

Datto återställer via Microsoft Graph API eller IMAP beroende på konfigurationen. I båda fallen beror det datum postlådan visar på om återställningen skickar med varje meddelandes ursprungliga datum. MSPs som använder Datto för sina kunder stöter på det här problemet ganska regelbundet, framförallt efter ransomware-incidenter där man återställer hundratals postlådor i en enda rörelse. Det är inte läget att upptäcka att alla datum är felaktiga.

AvePoint och Synology Active Backup

AvePoint Cloud Backup och Synology Active Backup for Microsoft 365 följer liknande mekanismer. AvePoint har dokumenterat det här beteendet i sin kunskapsbas (meddelandet återställs med återställningsdatumet som synligt ankomstdatum), utan att erbjuda en inbyggd korrigering. Synology Active Backup har samma problem, förstärkt av att återställningsgränssnittet inte tydligt skiljer mellan "meddelandedatum" och "återställningsdatum".

Goda nyheter: det ursprungliga datumet finns kvar

Det som gör situationen möjlig att rädda är att den ursprungliga Date:-headern i meddelandet inte har ändrats. Den finns fortfarande, intakt, i varje återställt e-postmeddelande. Återställningen ändrade det datum som postlådan registrerade, och lade ibland till en Received:-rad ovanpå, men rörde inte vid innehållet i meddelandet.

Det är en egenskap hos MIME-formatet (RFC 2822): ett meddelande är oföränderligt i sin interna struktur. Received:-headers ackumuleras längst upp som lager, men den ursprungliga informationen finns kvar nedanför.

Alltså: du har inte förlorat informationen. Den är bara dold av en återinjiceringsartefakt.

Varför det inte hjälper att köra återställningen igen

Den första tanken som dyker upp: radera de återställda e-postmeddelandena och köra återställningen igen i hopp om att datumen blir rätt den här gången. Det är en dålig idé, av flera skäl.

Återställningsverktygen kommer inte att bete sig annorlunda vid andra försöket. Samma verktyg, samma inställningar: e-postmeddelandena skrivs tillbaka på samma sätt, utan sitt ursprungliga datum. Du får exakt samma resultat.

Att dessutom köra en återställning på postlådor i produktion kostar tid, bandbredd och innebär risker. På 50 postlådor med 20 000 meddelanden var handlar det om en operation på flera timmar som monopoliserar API:erna och kan utlösa hastighetsbegränsningar hos Microsoft eller Google (det välkända 429 Too Many Requests klockan 02:00 under ett batchjobb).

Kort sagt: återställningen fungerade. Datan finns där. Det som behöver korrigeras är datumartefakten, inte återställningen i sig.

Att korrigera själv: de konkreta riskerna

Att förstå problemet är en sak. Att korrigera det på 80 000 e-postmeddelanden utan att förlora ett enda är en helt annan sak.

Ett Python-skript som går igenom IMAP-meddelanden och korrigerar datumen kan verka genomförbart. På 50 testmeddelanden fungerar det alldeles utmärkt. I produktion är det annorlunda. Kantfallen hopar sig: S/MIME-signerade e-postmeddelanden (att ändra headern ogiltigförklarar den kryptografiska signaturen), PGP-krypterade meddelanden, multipart-strukturer med icke-standardiserade MIME-gränser, headers kodade i RFC 2047 (icke-ASCII), bilagor på 40 MB som spränger skriptets minne. Och e-postmeddelanden med flera Received:-headers (om återställningen kördes om delvis, vilket händer), som kräver mer avancerad detekteringslogik.

Den verkliga risken är faktiskt inte skriptet som kraschar: det är skriptet som körs utan synbara fel men producerar korrupta meddelanden. Trasiga konversationstrådar. Dubbletter. Borttappade bilagor. Som du kanske inte märker förrän flera veckor senare, när en användare försöker hitta ett viktigt e-postmeddelande.

Och hur verifierar du att varje korrigerat e-postmeddelande verkligen är intakt efter ändringen? Ett hemmagjort skript gör det i regel inte.

Vad Redate.io gör annorlunda

Redate.io analyserar header-kedjan i varje e-postmeddelande för att identifiera återinjiceringsartefakter, oavsett om de kommer från en Veeam-återställning, en BitTitan-migrering eller en manuell import. Den egenutvecklade korrigeringsmotorn behöver inte veta vilket verktyg som orsakade problemet: den letar efter e-postmeddelanden vars visade datum inte stämmer med det ursprungliga datumet, så även ett verktyg ingen har hört talas om upptäcks.

Innan något korrigeras skannar Redate.io hela postlådan och presenterar en rapport: hur många e-postmeddelanden som berörs, vilket felaktigt datum de har, vilket ursprungligt datum som detekterades. Det här skannet är gratis. Du ser problemets omfattning innan du bestämmer dig för att agera.

Varje e-postmeddelande verifieras individuellt efter korrigeringen. Originalen raderas aldrig av Redate.io. De ligger kvar i en synlig mapp i din egen postlåda tills du själv väljer att ta bort dem.

Var användare loggar in med sitt eget Microsoft- eller Google-konto, och Redate.io öppnar just den postlådan med den åtkomst som inloggningen ger, utan att något e-postmeddelande passerar genom mellanliggande servrar. Korrigeringen sker på plats, i postlådan, utan export eller reimport.

För MSPs som hanterar flera drabbade kunder samtidigt, se MSP-sidan: Redate.io gör det möjligt att behandla flera postlådor parallellt från ett enda gränssnitt.

Andra scenarier som ger samma artefakt

Återställning från ett backupverktyg är inte det enda fallet. Samma datumartefakt uppstår i andra situationer:

• IMAP-import från Exchange (arkiverade postlådor återinjicerade i Exchange Online)
• Migrering till Exchange Online med verktyg som använder IMAP på målsidan
• Granulär återställning från en exporterad PST som sedan reimporteras (se artikeln om PST-import)
• Delade postlådor som rekonstruerats efter en incident (se korrigering av delade postlådor)

I alla dessa fall är den underliggande mekanismen densamma: en återinjicering som inte bär med sig det ursprungliga datumet (ibland med en ny Received:-header ovanpå), och en e-postklient som visar det nya datumet som referens.

E-posten finns där, det ursprungliga datumet är bevarat i varje meddelande. Starta en gratis skanning på Redate.io för att se exakt hur många e-postmeddelanden som berörs i din postlåda, och bestäm sedan om du vill köra korrigeringen.