Veeam/Datto : emails datés de la restauration, pas de l'envoi

Le lendemain de la restauration, les tickets arrivent

Vous venez de terminer une restauration de boîte mail via Veeam Backup for Microsoft 365. L'opération s'est bien passée, les données sont là, les dossiers sont intacts. Et puis, lundi matin, un utilisateur vous écrit : "Tous mes emails ont la date d'aujourd'hui. Je ne retrouve rien."

Le problème n'est pas que les emails ont disparu. Ils sont là. Mais leur date affichée correspond à l'heure exacte de la restauration, pas à la date à laquelle ils ont été envoyés ou reçus. Un email de janvier 2021 apparaît comme reçu hier soir à 23h47. Le fil de conversation est cassé. La chronologie est illisible.

Ce comportement touche Veeam Backup for Microsoft 365, Datto SaaS Protection, Synology Active Backup for Microsoft 365, et AvePoint Cloud Backup, entre autres. Chacun à sa manière, mais le résultat est identique.

Ce qui se passe techniquement

Pour comprendre d'où vient la mauvaise date, il faut regarder comment ces outils réinjectent les emails dans une boîte Exchange Online ou Google Workspace.

Quand un outil de backup restaure un message, il ne peut pas simplement "remettre en place" l'email comme on déplacerait un fichier sur un disque local. Il écrit une nouvelle copie du message dans la boîte, par le protocole IMAP ou par l'API du fournisseur (EWS ou Microsoft Graph côté Microsoft, l'API Gmail côté Google). Et avec cette copie, il doit indiquer à la boîte la date que porte le message.

Et c'est là que le problème commence. (D'ailleurs, si vous avez déjà lu les en-têtes bruts d'un email restauré, vous avez probablement vu défiler une vingtaine de lignes Received: avant de trouver le contenu utile.)

IMAP APPEND et le header Received:

Le protocole IMAP dispose d'une commande nommée APPEND. Elle sert à insérer un message dans une boîte mail. C'est exactement ce qu'utilise un outil de restauration : il prend le message sauvegardé, et l'injecte dans la boîte cible via IMAP APPEND.

Avec cette commande, l'outil peut transmettre une date en même temps que le message. S'il transmet la date d'origine du message, la boîte la garde : Microsoft 365, Outlook.com et Gmail le font tous les trois. S'il ne transmet rien, ou la date de la restauration, la boîte range l'email au jour de la restauration. Et certaines façons de réécrire un message ajoutent une ligne de plus en haut : un en-tête Received: daté du jour de la copie. L'API d'import de Gmail fait exactement cela.

Cette ligne supplémentaire ressemble à quelque chose comme :

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

Résultat : l'email original est intact à l'intérieur, avec son en-tête Date: d'origine (disons "3 Jan 2021 09:15:00"). Mais un nouvel en-tête Received: a été collé tout en haut, daté du moment de la restauration.

Comment Outlook et Gmail lisent la date

Les clients de messagerie comme Outlook ou l'interface web de Gmail ne lisent pas toujours l'en-tête Date: pour décider de la date à afficher dans la liste des messages. Beaucoup utilisent l'INTERNALDATE du protocole IMAP, c'est-à-dire la date à laquelle le message a été ajouté à la boîte, ou l'en-tête Received: le plus récent.

Outlook pour Windows, notamment depuis sa mise à jour de fin 2023, est particulièrement sensible à cela. Quand il voit un en-tête Received: récent en haut de la chaîne, il l'utilise comme date d'affichage. Le Date: original est relégué dans les détails du message, visible seulement si on ouvre les propriétés de l'email.

L'utilisateur final voit donc une liste de messages tous datés de la nuit de la restauration. Pour lui, son historique de trois ans vient de s'aplatir en une seule nuit.

Ce problème est différent d'une migration

Il faut faire la distinction avec le problème classique de dates erronées après migration IMAP. Dans une migration, l'outil déplace des emails d'un serveur A vers un serveur B, et chaque email garde ou perd sa date selon ce que l'outil indique au serveur B en l'écrivant. C'est la même mécanique, mais le contexte est différent.

Ici, on parle d'une restauration depuis une sauvegarde. Les emails n'ont jamais quitté l'organisation, ils ont juste été mis en sécurité quelque part (Azure Blob Storage, AWS S3, appliance Datto...) puis réinjectés. L'utilisateur s'y attend d'autant moins : pour lui, c'est "ses" emails qui reviennent, pas des emails importés.

Mais techniquement, le mécanisme est le même. Une réinjection qui ne transmet pas la date d'origine produit les mêmes artefacts. Et le correctif, lui aussi, suit la même logique.

Comment chaque outil gère (ou ne gère pas) l'INTERNALDATE

Tous les outils ne se comportent pas exactement de la même manière, et c'est là que les choses deviennent intéressantes.

Veeam Backup for Microsoft 365

Veeam utilise l'API EWS (Exchange Web Services) pour restaurer vers Exchange Online. EWS permet de spécifier la date du message via le champ DateTimeReceived, mais cette valeur n'est pas toujours répercutée sur l'INTERNALDATE au niveau IMAP. Résultat : la date de tri dans Outlook peut ne pas correspondre à la date originale, surtout si la restauration se fait vers une boîte différente de l'originale (restoration granulaire vers une boîte alternative, par exemple).

Datto SaaS Protection

Datto restaure via Microsoft Graph API ou IMAP selon la configuration. Dans les deux cas, la date affichée dépend de ce que la restauration transmet pour chaque message : sa date d'origine, ou non. Les MSPs qui utilisent Datto pour leurs clients rencontrent ce problème assez régulièrement, notamment après des incidents ransomware où on restaure en urgence plusieurs centaines de boîtes à la fois. Ce n'est pas le moment de découvrir que les dates sont toutes fausses.

AvePoint et Synology Active Backup

AvePoint Cloud Backup et Synology Active Backup for Microsoft 365 suivent des mécanismes similaires. AvePoint a documenté ce comportement dans sa base de connaissances (le message est restauré avec la date de restauration comme date de réception visible), sans pour autant proposer de correctif natif. Synology Active Backup présente le même problème, amplifié par le fait que l'interface de restauration ne distingue pas clairement la "date du message" de la "date de restauration".

Bonne nouvelle : la date originale est toujours là

Ce qui rend la situation récupérable, c'est que l'en-tête Date: original du message n'a pas été modifié. Il est toujours présent, intact, dans le corps de chaque email restauré. La restauration a changé la date enregistrée par la boîte, et parfois ajouté une ligne Received: par-dessus, mais elle n'a pas touché au contenu du message lui-même.

C'est une propriété du format MIME (RFC 2822) : un message est immuable dans sa structure interne. Les en-têtes Received: s'accumulent en haut comme des couches, mais les informations originales restent en dessous.

Donc non, vous n'avez pas perdu l'information. Elle est juste masquée par un artefact de réinjection.

Pourquoi relancer la restauration n'est pas la solution

La première idée qui vient à l'esprit : effacer les emails restaurés et relancer la restauration en espérant que cette fois-ci les dates seront correctes. C'est une mauvaise idée, pour plusieurs raisons.

D'abord, les outils de restauration ne vont pas se comporter différemment au deuxième passage. Même outil, mêmes réglages : les emails sont réécrits de la même façon, sans leur date d'origine. Vous obtiendrez exactement le même résultat.

Ensuite, relancer une restauration sur des boîtes en production, c'est du temps, de la bande passante, et du risque. Sur 50 boîtes avec 20 000 messages chacune, on parle d'une opération de plusieurs heures qui monopolise les APIs et peut déclencher des limites de taux côté Microsoft ou Google (le fameux 429 Too Many Requests à 2h du matin pendant le batch).

Bref. La restauration a fonctionné. Les données sont là. Ce qui doit être corrigé, c'est l'artefact de date, pas la restauration elle-même.

Corriger soi-même : les risques concrets

Comprendre le problème est une chose. Le corriger sur 80 000 emails sans en perdre un seul, c'en est une autre.

Un script Python qui parcourt les messages IMAP et corrige les dates peut sembler faisable. Et sur 50 emails de test, il fonctionnera très bien. En production, c'est différent. Les cas limites s'accumulent : emails signés S/MIME (modifier l'en-tête invalide la signature cryptographique), messages PGP chiffrés, structures multipart avec des frontières MIME non standards, en-têtes encodés en RFC 2047 (non-ASCII), pièces jointes de 40 Mo qui font exploser la mémoire du script. Et les emails avec plusieurs en-têtes Received: ajoutés (si la restauration a été relancée partiellement, ce qui arrive), qui demandent une logique de détection plus fine.

Pour être précis, le vrai risque n'est pas le script qui plante : c'est le script qui tourne sans erreur apparente mais produit des messages corrompus. Des fils de discussion cassés. Des doublons. Des pièces jointes détachées. Que vous ne détecterez peut-être que plusieurs semaines plus tard, quand un utilisateur essaie de retrouver un email important.

Et comment vérifiez-vous que chaque email corrigé est réellement intact après modification ? Un script maison ne le fait généralement pas.

Ce que Redate.io fait différemment

Redate.io analyse la chaîne d'en-têtes de chaque email pour identifier les artefacts de réinjection, qu'ils viennent d'une restauration Veeam, d'une migration BitTitan, ou d'un import manuel. Le moteur de correction propriétaire n'a pas besoin de savoir quel outil a causé le problème : il repère les emails dont la date affichée ne correspond pas à leur date d'origine, si bien que même un outil inconnu ne passe pas entre les mailles.

Avant de corriger quoi que ce soit, Redate.io scanne l'intégralité de la boîte et présente un rapport : combien d'emails sont affectés, quelle est la date incorrecte, quelle est la date originale détectée. Ce scan est gratuit. Vous voyez l'étendue du problème avant de décider d'agir.

Chaque email est vérifié individuellement après correction. Les originaux sont conservés dans un dossier de sauvegarde visible jusqu'à ce que vous les supprimiez vous-même, ce qui offre un filet de sécurité complet en cas de besoin.

Chaque utilisateur se connecte avec son propre compte Microsoft ou Google, et Redate.io ouvre uniquement cette boîte mail, avec les accès que cette connexion autorise, sans qu'aucun email ne transite par des serveurs intermédiaires. La correction se fait sur place, dans la boîte, sans export ni réimport.

Pour les MSPs qui gèrent plusieurs clients touchés simultanément, voir la page dédiée aux MSPs : Redate.io permet de traiter plusieurs boîtes en parallèle depuis une interface unique.

Autres scénarios qui produisent le même artefact

La restauration depuis un outil de backup n'est pas le seul cas. Le même artefact de date apparaît dans d'autres situations :

• Import IMAP depuis Exchange (boîtes archivées réinjectées dans Exchange Online)
• Migration vers Exchange Online avec des outils qui utilisent IMAP côté destination
• Restauration granulaire depuis un PST exporté puis réimporté (voir l'article sur l'import PST)
• Boîtes mail partagées reconstituées après incident (voir la correction des boîtes partagées)

Dans tous ces cas, la mécanique sous-jacente est identique : une réinjection qui ne transmet pas la date d'origine (parfois avec un nouvel en-tête Received: par-dessus), et un client mail qui affiche cette nouvelle date comme date de référence.

Les emails sont là, la date originale est préservée dans chaque message. Lancez un scan gratuit sur Redate.io pour voir exactement combien d'emails sont affectés dans votre boîte, et décidez ensuite si vous souhaitez lancer la correction.