Veeam/Datto: emails com data da restauração, não do envio

Na manhã seguinte à restauração, os tickets chegam

Você acabou de concluir uma restauração de caixa de email via Veeam Backup for Microsoft 365. A operação correu bem, os dados estão lá, as pastas estão intactas. Aí, na segunda-feira de manhã, um usuário te escreve: "Todos os meus emails estão com a data de hoje. Não consigo encontrar nada."

O problema não é que os emails sumiram. Eles estão lá. Mas a data exibida corresponde ao horário exato da restauração, não à data em que foram enviados ou recebidos. Um email de janeiro de 2021 aparece como recebido ontem à noite às 23h47. O fio da conversa está quebrado. A cronologia ficou ilegível.

Esse comportamento afeta o Veeam Backup for Microsoft 365, o Datto SaaS Protection, o Synology Active Backup for Microsoft 365 e o AvePoint Cloud Backup, entre outros. Cada um à sua maneira, mas o resultado é idêntico.

O que acontece tecnicamente

Para entender de onde vem a data errada, é preciso olhar como essas ferramentas reinjetam os emails em uma caixa Exchange Online ou Google Workspace.

Quando uma ferramenta de backup restaura uma mensagem, ela não pode simplesmente "recolocar" o email no lugar como se estivesse movendo um arquivo em disco local. Ela escreve uma nova cópia da mensagem na caixa de correio, através do IMAP ou da API do fornecedor (EWS ou Microsoft Graph do lado da Microsoft, a API do Gmail do lado da Google). E, junto com essa cópia, precisa indicar à caixa de correio qual é a data que a mensagem carrega.

E é aí que o problema começa. (Aliás, se você já leu os cabeçalhos brutos de um email restaurado, provavelmente viu uma vintena de linhas Received: antes de chegar ao conteúdo útil.)

IMAP APPEND e o cabeçalho Received:

O protocolo IMAP tem um comando chamado APPEND. Ele serve para inserir uma mensagem em uma caixa de email. É exatamente isso que uma ferramenta de restauração usa: ela pega a mensagem salva e a injeta na caixa de destino via IMAP APPEND.

Esse comando permite à ferramenta transmitir uma data junto com a mensagem. Se a ferramenta transmitir a data original da mensagem, a caixa de correio mantém-na, tanto no Microsoft 365, no Outlook.com, como no Gmail. Se não transmitir nenhuma data, ou transmitir a data da restauração, a caixa de correio arquiva o email no dia da restauração. E algumas formas de reescrever uma mensagem adicionam mais uma linha no topo: um cabeçalho Received: datado do dia da cópia. É exatamente isso que a API de importação do Gmail faz.

Essa linha adicional fica mais ou menos assim:

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

Resultado: o email original está intacto por dentro, com seu cabeçalho Date: original (digamos, "3 Jan 2021 09:15:00"). Mas um novo cabeçalho Received: foi colado no topo, datado do momento da restauração.

Como o Outlook e o Gmail leem a data

Clientes de email como o Outlook ou a interface web do Gmail nem sempre leem o cabeçalho Date: para decidir qual data exibir na lista de mensagens. Muitos usam o INTERNALDATE do protocolo IMAP, ou seja, a data em que a mensagem foi adicionada à caixa, ou o cabeçalho Received: mais recente.

O Outlook para Windows, especialmente após a atualização de fim de 2023, é particularmente sensível a isso. Quando ele vê um cabeçalho Received: recente no topo da cadeia, usa esse valor como data de exibição. O Date: original fica nos detalhes da mensagem, visível só se você abrir as propriedades do email.

O usuário final acaba vendo uma lista de mensagens todas datadas da noite da restauração. Para ele, seu histórico de três anos acabou de se comprimir em uma única noite.

Esse problema é diferente de uma migração

É importante distinguir esse caso do problema clássico de datas erradas após migração IMAP. Em uma migração, a ferramenta move emails de um servidor A para um servidor B, e se cada email mantém a sua data depende do que a ferramenta indica ao servidor B ao escrevê-lo. A mecânica é a mesma, mas o contexto é diferente.

Aqui, estamos falando de uma restauração a partir de um backup. Os emails nunca saíram da organização, foram apenas armazenados em algum lugar (Azure Blob Storage, AWS S3, appliance Datto...) e depois reinjetados. O usuário espera ainda menos: para ele, são "seus" emails que voltaram, não emails importados.

Mas tecnicamente, o mecanismo é idêntico. Uma reinjeção que não transporta a data original produz os mesmos artefatos. E a correção segue a mesma lógica.

Como cada ferramenta lida (ou não) com o INTERNALDATE

Nem todas as ferramentas se comportam exatamente da mesma forma, e é aí que as coisas ficam interessantes.

Veeam Backup for Microsoft 365

O Veeam usa a API EWS (Exchange Web Services) para restaurar no Exchange Online. O EWS permite especificar a data da mensagem pelo campo DateTimeReceived, mas esse valor nem sempre é refletido no INTERNALDATE no nível IMAP. Resultado: a data de ordenação no Outlook pode não corresponder à data original, especialmente quando a restauração é feita para uma caixa diferente da original (restauração granular para uma caixa alternativa, por exemplo).

Datto SaaS Protection

O Datto restaura via Microsoft Graph API ou IMAP, dependendo da configuração. Nos dois casos, a data que a caixa de correio mostra depende de a restauração transmitir ou não a data original de cada mensagem. Os MSPs que usam o Datto para seus clientes encontram esse problema com bastante frequência, principalmente após incidentes de ransomware em que se restauram centenas de caixas de uma vez em situação de emergência. Não é o momento de descobrir que todas as datas estão erradas.

AvePoint e Synology Active Backup

O AvePoint Cloud Backup e o Synology Active Backup for Microsoft 365 seguem mecanismos similares. O AvePoint documentou esse comportamento em sua base de conhecimento (a mensagem é restaurada com a data da restauração como data de recepção visível), sem oferecer uma correção nativa. O Synology Active Backup apresenta o mesmo problema, agravado pelo fato de que a interface de restauração não distingue claramente a "data da mensagem" da "data de restauração".

Boa notícia: a data original ainda está lá

O que torna a situação recuperável é que o cabeçalho Date: original da mensagem não foi alterado. Ele ainda está presente, intacto, dentro de cada email restaurado. A restauração fez a caixa de correio registar uma data diferente, e por vezes acrescentou uma linha Received: por cima, mas não tocou no conteúdo da mensagem em si.

É uma propriedade do formato MIME (RFC 2822): uma mensagem é imutável em sua estrutura interna. Os cabeçalhos Received: se acumulam no topo como camadas, mas as informações originais permanecem abaixo.

Então não, você não perdeu a informação. Ela está apenas mascarada por um artefato de reinjeção.

Por que relançar a restauração não é a solução

A primeira ideia que vem à cabeça: apagar os emails restaurados e relançar a restauração esperando que desta vez as datas fiquem corretas. Má ideia, por vários motivos.

Primeiro, as ferramentas de restauração não vão se comportar de forma diferente na segunda tentativa. A mesma ferramenta, com as mesmas definições, volta a escrever os emails da mesma forma, sem a sua data original. Você vai obter exatamente o mesmo resultado.

Além disso, relançar uma restauração em caixas em produção significa tempo, largura de banda e risco. Com 50 caixas e 20.000 mensagens cada, estamos falando de uma operação de várias horas que monopoliza as APIs e pode acionar limites de taxa do Microsoft ou do Google (o famoso 429 Too Many Requests às 2h da manhã durante o processamento em lote).

Bom. A restauração funcionou. Os dados estão lá. O que precisa ser corrigido é o artefato de data, não a restauração em si.

Corrigir por conta própria: os riscos concretos

Entender o problema é uma coisa. Corrigi-lo em 80.000 emails sem perder um sequer é outra.

Um script Python que percorre as mensagens IMAP e corrige as datas pode parecer viável. Em 50 emails de teste, vai funcionar muito bem. Em produção, é diferente. Os casos extremos se acumulam: emails assinados com S/MIME (modificar o cabeçalho invalida a assinatura criptográfica), mensagens PGP criptografadas, estruturas multipart com delimitadores MIME não padrão, cabeçalhos codificados em RFC 2047 (não-ASCII), anexos de 40 MB que estouram a memória do script. E os emails com vários cabeçalhos Received: adicionados (caso a restauração tenha sido relançada parcialmente, o que acontece), que exigem uma lógica de detecção mais refinada.

Para ser preciso, o risco real não é o script que falha: é o script que roda sem erro aparente, mas produz mensagens corrompidas. Conversas quebradas. Duplicatas. Anexos desvinculados. Que você talvez só descubra semanas depois, quando um usuário tentar encontrar um email importante.

E como você verifica que cada email corrigido está realmente íntegro após a modificação? Um script caseiro geralmente não faz isso.

O que o Redate.io faz de diferente

O Redate.io analisa a cadeia de cabeçalhos de cada email para identificar artefatos de reinjeção, sejam eles provenientes de uma restauração Veeam, de uma migração BitTitan ou de uma importação manual. O motor de correção proprietário não precisa de saber qual ferramenta causou o problema: procura os emails cuja data apresentada não corresponde à sua data original, por isso até uma ferramenta desconhecida é detetada.

Antes de corrigir qualquer coisa, o Redate.io escaneia toda a caixa e apresenta um relatório: quantos emails estão afetados, qual é a data incorreta, qual é a data original detectada. Esse escaneamento é gratuito. Você vê a extensão do problema antes de decidir agir.

Cada email é verificado individualmente após a correção. Os originais ficam numa pasta visível da sua própria caixa de correio até que decida eliminá-los, oferecendo uma rede de segurança completa caso seja necessário.

Cada utilizador inicia sessão com a sua própria conta Microsoft ou Google, e o Redate.io abre apenas essa caixa de correio, sem que nenhum email passe por servidores intermediários. A correção é feita no lugar, dentro da caixa, sem exportação nem reimportação.

Para os MSPs que gerenciam vários clientes afetados simultaneamente, veja a página dedicada aos MSPs: o Redate.io permite processar várias caixas em paralelo a partir de uma única interface.

Outros cenários que produzem o mesmo artefato

A restauração a partir de uma ferramenta de backup não é o único caso. O mesmo artefato de data aparece em outras situações:

• Import IMAP a partir do Exchange (caixas arquivadas reinjetadas no Exchange Online)
• Migração para o Exchange Online com ferramentas que usam IMAP no lado de destino
• Restauração granular a partir de um PST exportado e reimportado (veja o artigo sobre importação de PST)
• Caixas compartilhadas reconstituídas após incidente (veja a correção de caixas compartilhadas)

Em todos esses casos, a mecânica subjacente é idêntica: uma reinjeção que não transporta a data original (por vezes com um novo cabeçalho Received: por cima), e um cliente de email que apresenta essa nova data como referência.

Os emails estão lá, a data original está preservada em cada mensagem. Faça um escaneamento gratuito no Redate.io para ver exatamente quantos emails estão afetados na sua caixa, e decida depois se deseja iniciar a correção.