Veeam/Datto: email datate con l'ora del ripristino, non dell'invio

Il giorno dopo il ripristino, arrivano i ticket

Ha appena terminato un ripristino di cassette postali tramite Veeam Backup for Microsoft 365. L'operazione è andata bene, i dati ci sono, le cartelle sono intatte. E poi, lunedì mattina, un utente scrive: "Tutte le mie email hanno la data di oggi. Non ritrovo niente."

Il problema non è che le email siano sparite. Ci sono. Ma la data visualizzata corrisponde all'ora esatta del ripristino, non alla data in cui sono state inviate o ricevute. Un'email di gennaio 2021 appare come ricevuta ieri sera alle 23:47. Il filo della conversazione è spezzato. La cronologia è illeggibile.

Questo comportamento riguarda Veeam Backup for Microsoft 365, Datto SaaS Protection, Synology Active Backup for Microsoft 365 e AvePoint Cloud Backup, tra gli altri. Ognuno a modo suo, ma il risultato è identico.

Cosa succede tecnicamente

Per capire da dove viene la data sbagliata, bisogna guardare come questi strumenti reinseriscono le email in una casella Exchange Online o Google Workspace.

Quando uno strumento di backup ripristina un messaggio, non può semplicemente "rimettere al suo posto" l'email come si sposterebbe un file su un disco locale. Scrive una nuova copia del messaggio nella casella, tramite IMAP o tramite l'API del provider (EWS o Microsoft Graph lato Microsoft, l'API Gmail lato Google). E insieme a quella copia, deve indicare alla casella quale data porta il messaggio.

Ed è qui che inizia il problema. (Tra l'altro, se ha mai letto le intestazioni grezze di un'email ripristinata, ha probabilmente visto scorrere una ventina di righe Received: prima di trovare il contenuto utile.)

IMAP APPEND e l'header Received:

Il protocollo IMAP dispone di un comando chiamato APPEND. Serve a inserire un messaggio in una casella di posta. È esattamente quello che usa uno strumento di ripristino: prende il messaggio salvato e lo inietta nella casella di destinazione tramite IMAP APPEND.

Questo comando permette allo strumento di trasmettere una data insieme al messaggio. Se lo strumento trasmette la data originale del messaggio, la casella la conserva: succede su Microsoft 365, Outlook.com e Gmail. Se non trasmette nulla, o trasmette la data del ripristino, la casella archivia l'email sotto il giorno del ripristino. E alcuni modi di riscrivere un messaggio aggiungono un'ulteriore riga in cima: un'intestazione Received: datata al giorno della copia. È esattamente ciò che fa l'API di import di Gmail.

Questa riga in più assomiglia a qualcosa del genere:

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

Risultato: l'email originale è intatta all'interno, con la sua intestazione Date: d'origine (diciamo "3 Jan 2021 09:15:00"). Ma una nuova intestazione Received: è stata incollata in cima, datata al momento del ripristino.

Come Outlook e Gmail leggono la data

I client di posta come Outlook o l'interfaccia web di Gmail non leggono sempre l'intestazione Date: per decidere quale data mostrare nell'elenco dei messaggi. Molti usano l'INTERNALDATE del protocollo IMAP, ovvero la data in cui il messaggio è stato aggiunto alla casella, oppure l'intestazione Received: più recente.

Outlook per Windows, in particolare dall'aggiornamento di fine 2023, è particolarmente sensibile a questo. Quando vede un'intestazione Received: recente in cima alla catena, la usa come data di visualizzazione. Il Date: originale viene relegato nei dettagli del messaggio, visibile solo aprendo le proprietà dell'email.

L'utente finale si ritrova quindi con un elenco di messaggi tutti datati alla notte del ripristino. Per lui, tre anni di archivio si sono appiattiti in una sola notte.

Questo problema è diverso da una migrazione

Bisogna distinguerlo dal problema classico delle date errate dopo migrazione IMAP. In una migrazione, lo strumento sposta le email da un server A a un server B, e se ogni email conserva la sua data dipende da cosa lo strumento comunica al server B mentre la scrive. È la stessa meccanica, ma il contesto è diverso.

Qui si parla di un ripristino da backup. Le email non hanno mai lasciato l'organizzazione, sono state semplicemente messe al sicuro da qualche parte (Azure Blob Storage, AWS S3, appliance Datto...) e poi reiniettate. L'utente se lo aspetta ancora meno: per lui sono "le sue" email che tornano, non email importate.

Ma tecnicamente, il meccanismo è lo stesso. Una reiniezione che non trasmette la data originale produce gli stessi artefatti. E la correzione segue la stessa logica.

Come ogni strumento gestisce (o non gestisce) l'INTERNALDATE

Non tutti gli strumenti si comportano esattamente allo stesso modo, ed è qui che le cose diventano interessanti.

Veeam Backup for Microsoft 365

Veeam usa l'API EWS (Exchange Web Services) per ripristinare verso Exchange Online. EWS consente di specificare la data del messaggio tramite il campo DateTimeReceived, ma questo valore non viene sempre riportato sull'INTERNALDATE a livello IMAP. Risultato: la data di ordinamento in Outlook può non corrispondere alla data originale, soprattutto se il ripristino avviene verso una casella diversa dall'originale (ripristino granulare verso una casella alternativa, per esempio).

Datto SaaS Protection

Datto ripristina tramite Microsoft Graph API o IMAP a seconda della configurazione. In entrambi i casi, la data mostrata dalla casella dipende dal fatto che il ripristino trasmetta o no la data originale di ogni messaggio. Gli MSP che usano Datto per i propri clienti incontrano questo problema abbastanza regolarmente, in particolare dopo incidenti ransomware in cui si ripristinano d'urgenza centinaia di caselle contemporaneamente. Non è certo il momento di scoprire che tutte le date sono sbagliate.

AvePoint e Synology Active Backup

AvePoint Cloud Backup e Synology Active Backup for Microsoft 365 seguono meccanismi simili. AvePoint ha documentato questo comportamento nella propria knowledge base (il messaggio viene ripristinato con la data di ripristino come data di ricezione visibile), senza tuttavia proporre una correzione nativa. Synology Active Backup presenta lo stesso problema, amplificato dal fatto che l'interfaccia di ripristino non distingue chiaramente la "data del messaggio" dalla "data di ripristino".

La buona notizia: la data originale è ancora lì

Ciò che rende la situazione recuperabile è che l'intestazione Date: originale del messaggio non è stata modificata. È ancora presente, intatta, nel corpo di ogni email ripristinata. Il ripristino ha modificato la data registrata dalla casella, e talvolta ha aggiunto una riga Received: sopra, ma non ha toccato il contenuto del messaggio in sé.

È una proprietà del formato MIME (RFC 2822): un messaggio è immutabile nella sua struttura interna. Le intestazioni Received: si accumulano in cima come strati, ma le informazioni originali rimangono sotto.

Quindi no, l'informazione non è andata persa. È semplicemente mascherata da un artefatto di reiniezione.

Perché rilanciare il ripristino non è la soluzione

La prima idea che viene in mente: cancellare le email ripristinate e rilanciare il ripristino sperando che questa volta le date siano corrette. Non è una buona idea, per diversi motivi.

Prima di tutto, gli strumenti di ripristino non si comporteranno diversamente al secondo tentativo. Stesso strumento, stesse impostazioni: le email vengono riscritte allo stesso modo, senza la loro data originale. Si otterrà esattamente lo stesso risultato.

Poi, rilanciare un ripristino su caselle in produzione significa tempo, larghezza di banda e rischio. Su 50 caselle con 20.000 messaggi ciascuna, si tratta di un'operazione di diverse ore che monopolizza le API e può innescare limiti di frequenza lato Microsoft o Google (il classico 429 Too Many Requests alle 2 di notte durante il batch).

Insomma. Il ripristino ha funzionato. I dati ci sono. Quello che va corretto è l'artefatto di data, non il ripristino in sé.

Correggere da soli: i rischi concreti

Capire il problema è una cosa. Correggerlo su 80.000 email senza perderne nemmeno una è un'altra.

Uno script Python che scorre i messaggi IMAP e corregge le date può sembrare fattibile. E su 50 email di test funzionerà benissimo. In produzione è diverso. I casi limite si accumulano: email firmate S/MIME (modificare l'intestazione invalida la firma crittografica), messaggi PGP cifrati, strutture multipart con boundary MIME non standard, intestazioni codificate RFC 2047 (non-ASCII), allegati da 40 MB che mandano in overflow la memoria dello script. E le email con più intestazioni Received: aggiunte (se il ripristino è stato rilanciato parzialmente, cosa che capita), che richiedono una logica di rilevamento più sofisticata.

A dire il vero, il rischio vero non è lo script che crasha: è lo script che gira senza errori apparenti ma produce messaggi corrotti. Conversazioni spezzate. Duplicati. Allegati scollegati. Che si scopriranno forse solo settimane dopo, quando un utente cerca di ritrovare un'email importante.

E come si verifica che ogni email corretta sia davvero intatta dopo la modifica? Uno script artigianale generalmente non lo fa.

Cosa fa Redate.io in modo diverso

Redate.io analizza la catena di intestazioni di ogni email per identificare gli artefatti di reiniezione, che provengano da un ripristino Veeam, una migrazione BitTitan o un import manuale. Il motore di correzione proprietario non ha bisogno di sapere quale strumento ha causato il danno: cerca le email la cui data visualizzata non corrisponde alla loro data originale, così viene individuato anche uno strumento di cui nessuno ha mai sentito parlare.

Prima di correggere qualsiasi cosa, Redate.io esegue una scansione completa della casella e presenta un rapporto: quante email sono interessate, qual è la data errata, qual è la data originale rilevata. Questa scansione è gratuita. Si vede l'entità del problema prima di decidere se intervenire.

Ogni email viene verificata individualmente dopo la correzione. Gli originali vengono conservati in una cartella di backup visibile all'interno della casella, finché non li elimina personalmente, offrendo una rete di sicurezza completa in caso di necessità.

Ogni utente effettua l'accesso con il proprio account Microsoft o Google, e Redate.io apre così quella singola casella, senza che nessuna email transiti per server intermedi. La correzione avviene sul posto, nella casella, senza export né reimport.

Per gli MSP che gestiscono più clienti colpiti contemporaneamente, si consulti la pagina dedicata agli MSP: Redate.io consente di trattare più caselle in parallelo da un'unica interfaccia.

Altri scenari che producono lo stesso artefatto

Il ripristino da uno strumento di backup non è l'unico caso. Lo stesso artefatto di data compare in altre situazioni:

• Import IMAP da Exchange (caselle archiviate reiniettate in Exchange Online)
• Migrazione verso Exchange Online con strumenti che usano IMAP lato destinazione
• Ripristino granulare da un PST esportato e reimportato (vedi l'articolo sull'import PST)
• Caselle di posta condivise ricostituite dopo un incidente (vedi la correzione delle caselle condivise)

In tutti questi casi, la meccanica sottostante è identica: una reiniezione che non trasmette la data originale (a volte con una nuova intestazione Received: in cima), e un client di posta che mostra quella nuova data come riferimento.

Le email ci sono, la data originale è preservata in ogni messaggio. Lanci una scansione gratuita su Redate.io per vedere esattamente quante email sono interessate nella Sua casella, e decida poi se avviare la correzione.