Veeam/Datto: E-Mails zeigen Wiederherstellungsdatum statt Sendedatum

Am Tag nach der Wiederherstellung kommen die Tickets

Sie haben gerade eine Postfachwiederherstellung über Veeam Backup for Microsoft 365 abgeschlossen. Der Vorgang lief reibungslos, die Daten sind vorhanden, die Ordner sind intakt. Und dann, Montagmorgen, schreibt Ihnen ein Nutzer: "Alle meine E-Mails haben das heutige Datum. Ich finde nichts mehr."

Das Problem ist nicht, dass die E-Mails verschwunden sind. Sie sind da. Aber ihr angezeigtes Datum entspricht dem exakten Zeitpunkt der Wiederherstellung, nicht dem Datum, an dem sie gesendet oder empfangen wurden. Eine E-Mail vom Januar 2021 erscheint als gestern Abend um 23:47 Uhr empfangen. Der Gesprächsfaden ist zerrissen. Die Chronologie ist unleserlich.

Dieses Verhalten betrifft Veeam Backup for Microsoft 365, Datto SaaS Protection, Synology Active Backup for Microsoft 365 und AvePoint Cloud Backup, unter anderem. Jedes Tool auf seine eigene Weise, aber das Ergebnis ist identisch.

Was technisch passiert

Um zu verstehen, woher das falsche Datum kommt, muss man sich ansehen, wie diese Tools E-Mails in ein Exchange-Online- oder Google-Workspace-Postfach zurückschreiben.

Wenn ein Backup-Tool eine Nachricht wiederherstellt, kann es die E-Mail nicht einfach "zurücklegen", wie man eine Datei auf einem lokalen Laufwerk verschieben würde. Es schreibt eine neue Kopie der Nachricht in das Postfach, über IMAP oder über die API des Anbieters (EWS oder Microsoft Graph bei Microsoft, die Gmail-API bei Google). Und zusammen mit dieser Kopie muss es dem Postfach mitteilen, welches Datum die Nachricht trägt.

Und genau hier beginnt das Problem. (Wenn Sie jemals die rohen Header einer wiederhergestellten E-Mail gelesen haben, haben Sie wahrscheinlich zwanzig Zeilen Received: durchgescrollt, bevor Sie zum eigentlichen Inhalt gelangt sind.)

IMAP APPEND und der Received:-Header

Das IMAP-Protokoll verfügt über einen Befehl namens APPEND. Er dient dazu, eine Nachricht in ein Postfach einzufügen. Genau das verwendet ein Wiederherstellungs-Tool: Es nimmt die gespeicherte Nachricht und injiziert sie über IMAP APPEND in das Zielpostfach.

Dieser Befehl erlaubt es dem Tool, der Nachricht ein Datum mitzugeben. Übergibt das Tool das ursprüngliche Datum der Nachricht, behält das Postfach es bei: Microsoft 365, Outlook.com und Gmail tun das alle. Übergibt es nichts, oder das Datum der Wiederherstellung, ordnet das Postfach die E-Mail dem Tag der Wiederherstellung zu. Und manche Arten, eine Nachricht zurückzuschreiben, fügen ganz oben noch eine weitere Zeile hinzu: einen Received:-Header, datiert auf den Tag der Kopie. Genau das macht Gmails eigene Import-API.

Diese zusätzliche Zeile sieht dann etwa so aus:

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

Ergebnis: Die ursprüngliche E-Mail ist innen intakt, mit ihrem ursprünglichen Date:-Header (sagen wir "3 Jan 2021 09:15:00"). Aber ein neuer Received:-Header wurde ganz oben eingefügt, datiert auf den Zeitpunkt der Wiederherstellung.

Wie Outlook und Gmail das Datum lesen

E-Mail-Clients wie Outlook oder die Gmail-Weboberfläche lesen nicht immer den Date:-Header, um das in der Nachrichtenliste angezeigte Datum zu bestimmen. Viele verwenden das INTERNALDATE des IMAP-Protokolls, also das Datum, an dem die Nachricht dem Postfach hinzugefügt wurde, oder den neuesten Received:-Header.

Outlook für Windows ist dafür besonders anfällig, insbesondere seit dem Update Ende 2023. Wenn es einen aktuellen Received:-Header ganz oben in der Kette sieht, verwendet es diesen als Anzeigdatum. Das ursprüngliche Date: wird in die Nachrichtendetails verbannt, sichtbar nur, wenn man die E-Mail-Eigenschaften öffnet.

Der Endnutzer sieht also eine Liste von Nachrichten, die alle auf die Nacht der Wiederherstellung datiert sind. Für ihn hat sich sein dreijähriger Verlauf auf eine einzige Nacht zusammengezogen.

Dieses Problem unterscheidet sich von einer Migration

Man muss hier eine Unterscheidung zum klassischen Problem falscher Daten nach einer IMAP-Migration ziehen. Bei einer Migration verschiebt das Tool E-Mails von Server A zu Server B, und ob jede E-Mail ihr Datum behält, hängt davon ab, was das Tool Server B beim Schreiben mitteilt. Die Mechanik ist dieselbe, aber der Kontext ist anders.

Hier geht es um eine Wiederherstellung aus einer Sicherung. Die E-Mails haben die Organisation nie verlassen, sie wurden nur irgendwo sicher aufbewahrt (Azure Blob Storage, AWS S3, Datto-Appliance...) und dann neu eingefügt. Der Nutzer erwartet das umso weniger: Für ihn kommen "seine" E-Mails zurück, keine importierten Nachrichten.

Technisch gesehen ist der Mechanismus jedoch derselbe. Eine Neuinjektion, die das ursprüngliche Datum nicht mitträgt, erzeugt dieselben Artefakte. Und die Korrektur folgt ebenfalls derselben Logik.

Wie jedes Tool das INTERNALDATE behandelt (oder nicht)

Nicht alle Tools verhalten sich genau gleich, und das ist der Punkt, an dem es interessant wird.

Veeam Backup for Microsoft 365

Veeam verwendet die EWS-API (Exchange Web Services) für die Wiederherstellung in Exchange Online. EWS ermöglicht es, das Nachrichtendatum über das Feld DateTimeReceived anzugeben, aber dieser Wert wird nicht immer auf das INTERNALDATE auf IMAP-Ebene übertragen. Ergebnis: Das Sortierdatum in Outlook stimmt möglicherweise nicht mit dem ursprünglichen Datum überein, insbesondere wenn die Wiederherstellung in ein anderes Postfach als das ursprüngliche erfolgt (granulare Wiederherstellung in ein alternatives Postfach zum Beispiel).

Datto SaaS Protection

Datto stellt je nach Konfiguration über die Microsoft Graph API oder IMAP wieder her. In beiden Fällen hängt das im Postfach angezeigte Datum davon ab, ob die Wiederherstellung das ursprüngliche Datum jeder Nachricht mitgibt. MSPs, die Datto für ihre Kunden einsetzen, stoßen auf dieses Problem recht regelmäßig, insbesondere nach Ransomware-Vorfällen, bei denen mehrere Hundert Postfächer auf einmal notfallmäßig wiederhergestellt werden. Das ist nicht der richtige Moment, um festzustellen, dass alle Daten falsch sind.

AvePoint und Synology Active Backup

AvePoint Cloud Backup und Synology Active Backup for Microsoft 365 folgen ähnlichen Mechanismen. AvePoint hat dieses Verhalten in seiner Wissensdatenbank dokumentiert (die Nachricht wird mit dem Wiederherstellungsdatum als sichtbares Empfangsdatum wiederhergestellt), ohne dabei eine native Lösung anzubieten. Synology Active Backup weist dasselbe Problem auf, verstärkt durch die Tatsache, dass die Wiederherstellungsoberfläche nicht klar zwischen "Nachrichtendatum" und "Wiederherstellungsdatum" unterscheidet.

Die gute Nachricht: Das ursprüngliche Datum ist noch vorhanden

Was die Situation behebbar macht: Der ursprüngliche Date:-Header der Nachricht wurde nicht verändert. Er ist nach wie vor vorhanden, intakt, in jeder wiederhergestellten E-Mail. Die Wiederherstellung hat das vom Postfach erfasste Datum verändert, und manchmal zusätzlich eine Received:-Zeile darüber gelegt, aber den Nachrichteninhalt selbst nicht angetastet.

Das ist eine Eigenschaft des MIME-Formats (RFC 2822): Eine Nachricht ist in ihrer internen Struktur unveränderlich. Die Received:-Header häufen sich oben wie Schichten auf, aber die ursprünglichen Informationen bleiben darunter erhalten.

Sie haben also die Information nicht verloren. Sie ist nur durch ein Neuinjektions-Artefakt verdeckt.

Warum eine erneute Wiederherstellung keine Lösung ist

Der erste Gedanke, der einem kommt: Die wiederhergestellten E-Mails löschen und die Wiederherstellung erneut starten, in der Hoffnung, dass die Daten diesmal korrekt sind. Das ist eine schlechte Idee, aus mehreren Gründen.

Erstens werden sich die Wiederherstellungs-Tools beim zweiten Durchgang nicht anders verhalten. Gleiches Tool, gleiche Einstellungen: Die E-Mails werden auf dieselbe Weise zurückgeschrieben, ohne ihr ursprüngliches Datum. Sie erhalten genau dasselbe Ergebnis.

Zudem bedeutet eine erneute Wiederherstellung in Produktionspostfächern Zeit, Bandbreite und Risiko. Bei 50 Postfächern mit je 20.000 Nachrichten spricht man von einem mehrstündigen Vorgang, der die APIs belastet und serverseitig bei Microsoft oder Google Ratenbegrenzungen auslösen kann (das berühmte 429 Too Many Requests um 2 Uhr nachts während des Batches).

Kurzum: Die Wiederherstellung hat funktioniert. Die Daten sind vorhanden. Was korrigiert werden muss, ist das Datumsartefakt, nicht die Wiederherstellung selbst.

Selbst korrigieren: Die konkreten Risiken

Das Problem zu verstehen ist eine Sache. Es auf 80.000 E-Mails zu korrigieren, ohne eine einzige zu verlieren, ist eine andere.

Ein Python-Skript, das IMAP-Nachrichten durchläuft und Daten korrigiert, mag machbar erscheinen. Auf 50 Test-E-Mails wird es auch gut funktionieren. Im Produktivbetrieb sieht das anders aus. Grenzfälle häufen sich: S/MIME-signierte E-Mails (das Ändern des Headers macht die kryptografische Signatur ungültig), PGP-verschlüsselte Nachrichten, Multipart-Strukturen mit nicht standardmäßigen MIME-Grenzen, nach RFC 2047 kodierte Header (Nicht-ASCII), 40-MB-Anhänge, die den Skriptspeicher sprengen. Dazu kommen E-Mails mit mehreren hinzugefügten Received:-Headern (wenn die Wiederherstellung teilweise neu gestartet wurde, was vorkommt), die eine feinere Erkennungslogik erfordern.

Das eigentliche Risiko ist nicht das Skript, das abstürzt: Es ist das Skript, das ohne offensichtlichen Fehler läuft, aber beschädigte Nachrichten erzeugt. Unterbrochene Gesprächsfäden. Duplikate. Abgetrennte Anhänge. Die Sie vielleicht erst Wochen später bemerken, wenn ein Nutzer eine wichtige E-Mail sucht.

Und wie überprüfen Sie, dass jede korrigierte E-Mail nach der Änderung wirklich intakt ist? Ein selbst gebautes Skript tut das in der Regel nicht.

Was Redate.io anders macht

Redate.io analysiert die Header-Kette jeder E-Mail, um Neuinjektions-Artefakte zu identifizieren, egal ob sie von einer Veeam-Wiederherstellung, einer BitTitan-Migration oder einem manuellen Import stammen. Die proprietäre Korrektur-Engine muss nicht wissen, welches Tool den Schaden verursacht hat: Sie erkennt E-Mails, deren angezeigtes Datum nicht mit ihrem ursprünglichen Datum übereinstimmt, sodass selbst ein unbekanntes Tool auffällt.

Bevor irgendetwas korrigiert wird, scannt Redate.io das gesamte Postfach und zeigt einen Bericht: Wie viele E-Mails sind betroffen, was ist das falsche Datum, was ist das erkannte Originaldatum. Dieser Scan ist kostenlos. Sie sehen den Umfang des Problems, bevor Sie entscheiden, ob Sie handeln möchten.

Jede E-Mail wird nach der Korrektur einzeln verifiziert. Die Originale bleiben in einem sichtbaren Sicherungsordner in Ihrem eigenen Postfach erhalten, bis Sie sie selbst löschen, was im Bedarfsfall ein vollständiges Sicherheitsnetz bietet.

Jeder Nutzer meldet sich mit seinem eigenen Microsoft- oder Google-Konto an, und Redate.io öffnet genau dieses Postfach mit den dabei erteilten Zugriffsrechten, ohne dass E-Mails über zwischengelagerte Server übertragen werden. Die Korrektur erfolgt direkt im Postfach, ohne Export oder Reimport.

Für MSPs, die mehrere gleichzeitig betroffene Kunden verwalten, bietet die MSP-Seite eine Übersicht: Redate.io ermöglicht die parallele Bearbeitung mehrerer Postfächer über eine einzige Oberfläche.

Andere Szenarien, die dasselbe Artefakt erzeugen

Die Wiederherstellung aus einem Backup-Tool ist nicht der einzige Fall. Dasselbe Datumsartefakt tritt in anderen Situationen auf:

• IMAP-Import aus Exchange (archivierte Postfächer, die in Exchange Online neu injiziert werden)
• Migration zu Exchange Online mit Tools, die IMAP auf der Zielseite verwenden
• Granulare Wiederherstellung aus einer exportierten und dann reimportierten PST-Datei (siehe den Artikel zum PST-Import)
• Geteilte Postfächer, die nach einem Vorfall rekonstruiert wurden (siehe die Korrektur geteilter Postfächer)

In all diesen Fällen ist die zugrunde liegende Mechanik identisch: Eine Neuinjektion, die das ursprüngliche Datum nicht mitträgt (manchmal mit einem neuen Received:-Header darüber), und ein E-Mail-Client, der dieses neue Datum als Referenz anzeigt.

Die E-Mails sind vorhanden, das ursprüngliche Datum ist in jeder Nachricht erhalten. Starten Sie einen kostenlosen Scan auf Redate.io, um genau zu sehen, wie viele E-Mails in Ihrem Postfach betroffen sind, und entscheiden Sie dann, ob Sie die Korrektur starten möchten.