Veeam/Datto: emails fechados con la restauración, no el envío

Al día siguiente de la restauración, llegan los tickets

Acaba de terminar una restauración de buzón mediante Veeam Backup for Microsoft 365. La operación fue bien, los datos están ahí, las carpetas intactas. Y entonces, el lunes por la mañana, un usuario le escribe: "Todos mis correos tienen la fecha de hoy. No encuentro nada."

El problema no es que los emails hayan desaparecido. Están ahí. Pero la fecha que muestran corresponde a la hora exacta de la restauración, no a la fecha en que se enviaron o recibieron. Un correo de enero de 2021 aparece como recibido anoche a las 23:47. El hilo de conversación está roto. La cronología es ilegible.

Este comportamiento afecta a Veeam Backup for Microsoft 365, Datto SaaS Protection, Synology Active Backup for Microsoft 365 y AvePoint Cloud Backup, entre otros. Cada uno a su manera, pero el resultado es idéntico.

Lo que ocurre técnicamente

Para entender de dónde viene la fecha incorrecta, hay que ver cómo estas herramientas reinyectan los correos en un buzón de Exchange Online o Google Workspace.

Cuando una herramienta de backup restaura un mensaje, no puede simplemente "devolver" el email a su sitio como si moviera un archivo en un disco local. Escribe una nueva copia del mensaje en el buzón, mediante IMAP o mediante la API del proveedor (EWS o Microsoft Graph en el caso de Microsoft, la API de Gmail en el caso de Google). Y junto con esa copia, tiene que indicarle al buzón qué fecha lleva el mensaje.

Y ahí empieza el problema. (Por cierto, si alguna vez ha leído los encabezados en bruto de un email restaurado, probablemente habrá visto una veintena de líneas Received: antes de encontrar el contenido útil.)

IMAP APPEND y el encabezado Received:

El protocolo IMAP dispone de un comando llamado APPEND. Sirve para insertar un mensaje en un buzón de correo. Es exactamente lo que usa una herramienta de restauración: toma el mensaje guardado y lo inyecta en el buzón de destino.

Este mecanismo permite que la herramienta indique una fecha junto con el mensaje. Si la herramienta transmite la fecha original del mensaje, el buzón la conserva: así ocurre en Microsoft 365, Outlook.com y Gmail. Si no transmite ninguna fecha, o transmite la fecha de la restauración, el buzón clasifica el email bajo el día de la restauración. Y algunas formas de reescribir un mensaje añaden además una línea más al principio: un encabezado Received: con la fecha del día de la copia. La propia API de importación de Gmail hace exactamente eso.

Esta línea adicional tiene un aspecto similar a este:

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

Resultado: el email original está intacto en su interior, con su encabezado Date: original (por ejemplo, "3 Jan 2021 09:15:00"). Pero se ha pegado encima un nuevo encabezado Received: con la fecha de la restauración.

Cómo leen la fecha Outlook y Gmail

Los clientes de correo como Outlook o la interfaz web de Gmail no siempre leen el encabezado Date: para decidir qué fecha mostrar en la lista de mensajes. Muchos utilizan el INTERNALDATE del protocolo IMAP, es decir, la fecha en que el mensaje fue añadido al buzón, o el encabezado Received: más reciente.

Outlook para Windows, especialmente desde su actualización de finales de 2023, es particularmente sensible a esto. Cuando detecta un encabezado Received: reciente al principio de la cadena, lo usa como fecha de visualización. El Date: original queda relegado a los detalles del mensaje, visible solo si se abren las propiedades del correo.

El usuario final ve entonces una lista de mensajes todos fechados la noche de la restauración. Para él, su historial de tres años acaba de aplanarse en una sola noche.

Este problema es distinto de una migración

Conviene distinguirlo del problema clásico de fechas incorrectas tras migración IMAP. En una migración, la herramienta mueve correos de un servidor A a un servidor B, y que cada email conserve o no su fecha depende de lo que la herramienta le indique al servidor B al escribirlo. El mecanismo es el mismo, pero el contexto es diferente.

Aquí se trata de una restauración desde una copia de seguridad. Los emails nunca abandonaron la organización, simplemente se pusieron a buen recaudo en algún lugar (Azure Blob Storage, AWS S3, appliance de Datto...) y luego se reinyectaron. El usuario lo espera aún menos: para él, son "sus" correos que vuelven, no emails importados.

Pero técnicamente, el mecanismo es el mismo. Una reinyección que no transmite la fecha original produce los mismos artefactos. Y la corrección sigue también la misma lógica.

Cómo gestiona (o no gestiona) cada herramienta el INTERNALDATE

No todas las herramientas se comportan exactamente igual, y aquí es donde las cosas se vuelven interesantes.

Veeam Backup for Microsoft 365

Veeam utiliza la API EWS (Exchange Web Services) para restaurar hacia Exchange Online. EWS permite especificar la fecha del mensaje mediante el campo DateTimeReceived, pero este valor no siempre se traslada al INTERNALDATE a nivel IMAP. Resultado: la fecha de ordenación en Outlook puede no coincidir con la fecha original, sobre todo si la restauración se hace hacia un buzón distinto del original (restauración granular hacia un buzón alternativo, por ejemplo).

Datto SaaS Protection

Datto restaura a través de Microsoft Graph API o IMAP según la configuración. En ambos casos, la fecha que muestra el buzón depende de si la restauración transmite la fecha original de cada mensaje. Los MSP que usan Datto para sus clientes se encuentran con este problema con bastante frecuencia, especialmente tras incidentes de ransomware donde se restauran en urgencia varios cientos de buzones a la vez. No es el momento de descubrir que todas las fechas están mal.

AvePoint y Synology Active Backup

AvePoint Cloud Backup y Synology Active Backup for Microsoft 365 siguen mecanismos similares. AvePoint ha documentado este comportamiento en su base de conocimiento (el mensaje se restaura con la fecha de restauración como fecha de recepción visible), sin ofrecer una corrección nativa. Synology Active Backup presenta el mismo problema, agravado por el hecho de que la interfaz de restauración no distingue claramente la "fecha del mensaje" de la "fecha de restauración".

Buena noticia: la fecha original sigue ahí

Lo que hace recuperable la situación es que el encabezado Date: original del mensaje no ha sido modificado. Sigue presente, intacto, dentro de cada email restaurado. La restauración cambió la fecha que el buzón registró y, a veces, añadió una línea Received: encima, pero no ha tocado el contenido del mensaje en sí.

Es una propiedad del formato MIME (RFC 2822): un mensaje es inmutable en su estructura interna. Los encabezados Received: se acumulan arriba como capas, pero la información original permanece debajo.

O sea, no ha perdido la información. Está simplemente oculta bajo un artefacto de reinyección.

Por qué relanzar la restauración no es la solución

La primera idea que se le ocurre: borrar los emails restaurados y relanzar la restauración esperando que esta vez las fechas sean correctas. Mala idea, por varias razones.

Primero, las herramientas de restauración no se van a comportar de manera diferente en el segundo intento. Misma herramienta, misma configuración: los correos se vuelven a escribir de la misma manera, sin su fecha original. Obtendrá exactamente el mismo resultado.

Además, relanzar una restauración sobre buzones en producción implica tiempo, ancho de banda y riesgo. Con 50 buzones de 20.000 mensajes cada uno, hablamos de una operación de varias horas que acapara las APIs y puede desencadenar límites de tasa por parte de Microsoft o Google (el famoso 429 Too Many Requests a las 2 de la madrugada durante el batch).

En definitiva: la restauración funcionó. Los datos están ahí. Lo que hay que corregir es el artefacto de fecha, no la restauración en sí.

Corregirlo uno mismo: los riesgos concretos

Entender el problema es una cosa. Corregirlo en 80.000 correos sin perder ni uno solo es otra muy distinta.

Un script Python que recorra los mensajes IMAP y corrija las fechas puede parecer factible. Y sobre 50 emails de prueba, funcionará perfectamente. En producción, es diferente. Los casos extremos se acumulan: emails firmados con S/MIME (modificar el encabezado invalida la firma criptográfica), mensajes cifrados con PGP, estructuras multipart con límites MIME no estándar, encabezados codificados en RFC 2047 (no-ASCII), archivos adjuntos de 40 MB que hacen estallar la memoria del script. Y los emails con varios encabezados Received: añadidos (si la restauración se relanzó parcialmente, lo que ocurre), que requieren una lógica de detección más fina.

Para ser preciso: el verdadero riesgo no es el script que falla, sino el script que se ejecuta sin error aparente pero produce mensajes corruptos. Hilos de conversación rotos. Duplicados. Archivos adjuntos desvinculados. Que quizás no detectará hasta varias semanas después, cuando un usuario intente encontrar un correo importante.

¿Y cómo verifica que cada email corregido está realmente intacto tras la modificación? Un script casero generalmente no lo hace.

Lo que Redate.io hace de forma diferente

Redate.io analiza la cadena de encabezados de cada email para identificar los artefactos de reinyección, tanto si proceden de una restauración Veeam como de una migración BitTitan o de una importación manual. El motor de corrección propietario no necesita saber qué herramienta causó el problema: busca los correos cuya fecha mostrada no coincide con su fecha original, de modo que incluso una herramienta desconocida queda detectada.

Antes de corregir nada, Redate.io analiza la totalidad del buzón y presenta un informe: cuántos emails están afectados, cuál es la fecha incorrecta, cuál es la fecha original detectada. Este análisis es gratuito. Puede ver el alcance del problema antes de decidir si actúa.

Cada email se verifica individualmente tras la corrección. Los originales se conservan en una carpeta de copia de seguridad visible en su propio buzón, hasta que usted decida eliminarlos, lo que ofrece una red de seguridad completa si fuera necesario.

Cada usuario abre su buzón de Exchange Online iniciando sesión con su propia cuenta de Microsoft, sin portales ni aplicaciones que registrar; si la organización lo requiere, Redate.io prepara un enlace de aprobación para el administrador. Para Google Workspace, el acceso se concede mediante delegación de dominio, sin que ningún correo transite por servidores intermediarios. La corrección se realiza en el propio buzón, sin exportación ni reimportación.

Para los MSP que gestionan varios clientes afectados simultáneamente, consulte la página dedicada a los MSP: Redate.io permite tratar varios buzones en paralelo desde una interfaz única.

Otros escenarios que producen el mismo artefacto

La restauración desde una herramienta de backup no es el único caso. El mismo artefacto de fecha aparece en otras situaciones:

• Importación IMAP desde Exchange (buzones archivados reinyectados en Exchange Online)
• Migración hacia Exchange Online con herramientas que utilizan IMAP en el destino
• Restauración granular desde un PST exportado y luego reimportado (ver el artículo sobre la importación PST)
• Buzones compartidos reconstituidos tras un incidente (ver la corrección de buzones compartidos)

En todos estos casos, el mecanismo subyacente es idéntico: una reinyección que no transmite la fecha original (a veces con un nuevo encabezado Received: encima), y un cliente de correo que muestra esa nueva fecha como referencia.

Los correos están ahí, la fecha original está preservada en cada mensaje. Lance un análisis gratuito en Redate.io para ver exactamente cuántos emails están afectados en su buzón, y decida después si desea lanzar la corrección.