Solucionar IMAPSync vs rsync: migrar e-mail com histórico

IMAPSync vs rsync é a decisão central ao migrar e-mail corporativo para outro servidor Linux mantendo histórico: IMAPSync copia mensagens via protocolo IMAP, enquanto rsync replica arquivos de mailbox no sistema de arquivos quando você controla origem e destino. Para migrar com segurança, siga estes passos:

1. Audite contas, domínios, aliases, espaço usado e acesso ao servidor antigo.
2. Escolha IMAPSync para migração por login IMAP ou rsync para cópia direta de Maildir no Linux.
3. Sincronize o histórico antes de alterar o MX do domínio.
4. Reduza TTL, faça a janela de virada e execute uma sincronização final.
5. Valide pastas, mensagens, envio, recebimento, SPF, DKIM e DMARC.

Pré-requisitos

• Acesso administrativo ao servidor Linux antigo e ao novo, ou credenciais IMAP válidas para todas as caixas.
• Servidor de e-mail funcional no destino, com contas já criadas e capacidade de armazenamento suficiente.
• Ambiente Linux atual, como Debian 13+, Rocky Linux 10+ ou AlmaLinux 10+, com acesso SSH estável.
• IMAP habilitado quando a migração for por protocolo; acesso ao diretório das mailboxes quando a migração for por rsync.
• Controle da zona DNS do domínio para revisar MX, SPF, DKIM, DMARC e TTL. Se precisar revisar a base, consulte Guia de zona DNS: registros A, MX, CNAME e TXT do zero.
• Plano de rollback: manter o servidor antigo ativo até confirmar login, pastas, volume de mensagens e envio pelo novo servidor.

Escolha entre IMAPSync e rsync para migração de e-mail

Migrar caixas IMAP com histórico exige entender onde está a fonte confiável das mensagens. IMAPSync é a escolha natural quando você tem usuário e senha de cada conta, mas não tem acesso direto aos arquivos internos do servidor antigo. Ele se conecta à origem por IMAP, lê pastas e mensagens e grava no destino também por IMAP. Isso ajuda quando a estrutura do servidor muda, por exemplo, de um painel para outro ou de um provedor externo para um servidor Linux próprio.

Copiar Maildir com rsync faz sentido quando origem e destino usam diretórios de mailbox compatíveis e você controla permissões, donos e caminhos. Nesse cenário, rsync trabalha no nível do sistema de arquivos, preservando dados locais com eficiência, mas exige mais cuidado: se copiar para o caminho errado, aplicar dono incorreto ou usar exclusões indevidas, a conta pode aparecer vazia no webmail mesmo com arquivos presentes no disco.

• Use IMAPSync quando: você quer preservar mensagens e pastas acessando as contas via IMAP, sem depender do formato local da mailbox.
• Use rsync quando: você administra os dois servidores e precisa replicar diretórios de e-mail no Linux, especialmente Maildir.
• Evite rsync quando: você não sabe o caminho real das mailboxes, não conhece o usuário do serviço de e-mail ou o destino usa estrutura diferente.
• Evite IMAPSync quando: você não possui senhas das contas nem mecanismo seguro para autenticar em cada mailbox.

IMAPSync vs rsync: diferença prática na preservação do histórico

A diferença prática é que IMAPSync enxerga o histórico como mensagens IMAP, enquanto rsync enxerga como arquivos. Ao rodar uma migração real, trate IMAPSync como ferramenta de compatibilidade entre servidores e rsync como ferramenta de espelhamento controlado. Para servidores de e-mail recém-configurados, vale revisar também Passo a passo para configurar servidor de e-mail no VPS Linux antes de receber produção.

Inventário antes de migrar e-mail corporativo com histórico

Migrar e-mail corporativo com histórico começa antes da cópia. O erro mais comum é alterar o MX primeiro e descobrir depois que faltam contas, aliases, caixas compartilhadas ou espaço no destino. Faça um inventário objetivo: lista de contas, tamanho aproximado, domínios atendidos, aliases, redirecionamentos, pastas especiais e forma de autenticação. Se houver usuários que acessam por cliente local, avise que eles não devem apagar mensagens durante a janela de migração.

Registre também o IP antigo, o IP novo e o estado atual do DNS. O MX define para onde novas mensagens serão entregues; por isso, enquanto o MX ainda aponta para o servidor antigo, você pode copiar o histórico com menor risco. A redução de TTL deve ser feita antes da virada para que a propagação seja mais previsível na janela de troca.

1. Liste todas as contas que existem na origem.
2. Crie as mesmas contas no destino antes da sincronização.
3. Confirme que cada conta consegue autenticar no IMAP do destino.
4. Verifique MX atual e planeje o novo MX.
5. Separe contas grandes para sincronização antecipada.

resolvectl query -t MX seudominio.com.br

Output esperado:
seudominio.com.br IN MX 10 mail.seudominio.com.br
mail.seudominio.com.br IN A 203.0.113.10

ss -lntp | grep -E ':143|:993|:25|:587'

Output esperado:
LISTEN 0 4096 0.0.0.0:993 0.0.0.0:* users:(("imap",pid=1200,fd=8))
LISTEN 0 4096 0.0.0.0:587 0.0.0.0:* users:(("smtp",pid=1210,fd=6))

Ao rodar esses comandos, você verá se o DNS ainda aponta para o servidor antigo e se o novo servidor já escuta nas portas necessárias. Se o IMAP do destino não responder, não inicie a migração por IMAPSync; corrija autenticação e serviço primeiro.

Sincronizar histórico com IMAPSync antes da troca de MX

Sincronização IMAP entre servidores é o método mais seguro quando a prioridade é manter pastas e mensagens sem depender do layout interno de armazenamento. Antes de executar em massa, faça um teste com uma conta real de baixo risco. O primeiro teste deve validar login na origem, login no destino, criação de pastas e contagem aproximada de mensagens. Em migrações com muitas contas, rode em lotes para não sobrecarregar o servidor antigo.

Use nomes de host explícitos para evitar confusão durante a propagação de DNS. Enquanto o MX ainda aponta para o servidor antigo, conecte a origem pelo host antigo e o destino pelo novo host ou IP configurado. Se usar nomes como mail.seudominio.com.br para os dois lados, você pode acabar sincronizando para o servidor errado após a virada.

1. Teste uma conta piloto.
2. Valide pastas no webmail do novo servidor.
3. Repita para contas maiores em janelas antecipadas.
4. Registre contas com erro para nova tentativa.

imapsync --host1 203.0.113.10 --user1 [email protected] --password1 senha-origem --ssl1 --host2 198.51.100.20 --user2 [email protected] --password2 senha-destino --ssl2

Output esperado:
Host1 connected
Host2 connected
Folder INBOX synced
Folder Sent synced
Messages transferred: 1240
Detected 0 errors

Se o teste funcionar, repita o padrão para as demais contas. Não use a mesma senha em todas as contas apenas para facilitar a migração sem avaliar o risco operacional. Em ambientes corporativos, o ideal é registrar quem autorizou a troca de senha temporária, quando ela foi feita e quando será revertida.

Replicar mailboxes com rsync quando você controla os arquivos

Rsync para Maildir é eficiente quando o servidor antigo e o novo usam estrutura de arquivos compatível. A grande vantagem é copiar diretórios inteiros com atributos, preservando o histórico no nível do disco. A grande desvantagem é que rsync não entende a lógica IMAP da conta: ele apenas copia arquivos. Portanto, caminhos, donos, grupos e permissões precisam estar corretos para o serviço de e-mail enxergar as mensagens no destino.

Atenção: comandos com --delete removem no destino arquivos que não existem mais na origem. Use somente depois de confirmar o caminho correto, o usuário correto e um backup válido. Em uma primeira passagem, prefira sincronizar sem exclusão destrutiva.

1. Identifique o diretório real das mailboxes no servidor antigo.
2. Confirme que o destino usa estrutura compatível.
3. Execute uma primeira cópia sem apagar dados no destino.
4. Ajuste dono e permissões conforme o serviço de e-mail do destino.
5. Faça a sincronização final apenas durante a janela de virada.

rsync -avz --progress /var/mail/vhosts/seudominio.com.br/ [email protected]:/var/mail/vhosts/seudominio.com.br/

Output esperado:
sending incremental file list
usuario/
usuario/Maildir/
usuario/Maildir/cur/
sent 842.10M bytes  received 18.42K bytes
total size is 851.30M  speedup is 1.01

Depois da cópia, valide no destino se o serviço consegue listar a mailbox. Se as mensagens não aparecerem, não conclua que a cópia falhou imediatamente; primeiro confira dono, grupo, permissões e caminho esperado pelo serviço IMAP. Em migração com rsync, um erro de permissão pode parecer perda de histórico, mesmo quando os arquivos foram copiados.

ssh [email protected] "ls -la /var/mail/vhosts/seudominio.com.br/usuario/Maildir | head"

Output esperado:
drwx------ 5 usuario mail 4096 .
drwx------ 3 usuario mail 4096 ..
drwx------ 2 usuario mail 4096 cur
drwx------ 2 usuario mail 4096 new
drwx------ 2 usuario mail 4096 tmp

Trocar MX sem perder mensagens durante a virada

Trocar MX sem perder e-mail depende de sequência, não de pressa. Primeiro copie o histórico; depois reduza TTL com antecedência; só então altere o MX na janela combinada. Durante a propagação, alguns remetentes ainda podem entregar no servidor antigo, enquanto outros já entregam no novo. Por isso, a sincronização final depois da virada é indispensável tanto em IMAPSync quanto em rsync.

O servidor antigo deve permanecer ativo e recebendo por um período de validação. Desligá-lo logo após alterar o MX aumenta o risco de mensagens presas, rejeições temporárias ou caixas incompletas. Também revise SPF, DKIM e DMARC se o novo servidor passará a enviar mensagens pelo domínio. Para a parte de autenticação de envio, use como referência Guia DKIM, SPF e DMARC: configure e saia do spam.

1. Reduza o TTL antes da migração, se a zona DNS permitir.
2. Confirme que o novo servidor recebe e autentica usuários.
3. Altere o MX para o novo host.
4. Execute uma sincronização final para capturar mensagens tardias.
5. Teste envio e recebimento externo.

resolvectl query -t MX seudominio.com.br

Output esperado:
seudominio.com.br IN MX 10 mail-novo.seudominio.com.br
mail-novo.seudominio.com.br IN A 198.51.100.20

imapsync --host1 203.0.113.10 --user1 [email protected] --password1 senha-origem --ssl1 --host2 198.51.100.20 --user2 [email protected] --password2 senha-destino --ssl2

Output esperado:
Folder INBOX synced
Messages transferred: 12
Messages skipped: 1240
Detected 0 errors

Esse segundo resultado indica o comportamento esperado em uma sincronização final: poucas mensagens novas transferidas e muitas já ignoradas por estarem presentes no destino. Se o volume transferido for muito alto, investigue se a primeira sincronização não foi feita para outra conta ou outro host.

Validação pós-migração das caixas e autenticação do domínio

Validar histórico de e-mails migrados é uma etapa técnica, não apenas visual. Abrir o webmail e ver a caixa de entrada não basta; é preciso conferir pastas enviadas, lixeira, rascunhos, subpastas criadas pelo usuário, mensagens recentes e mensagens antigas. Também teste clientes IMAP, pois alguns usuários dependem de pastas assinadas manualmente.

Use uma amostra representativa: uma conta pequena, uma grande, uma conta com muitas pastas e uma conta crítica da empresa. Compare contagem aproximada, tamanho em disco e presença de mensagens recentes recebidas durante a janela de DNS. Em seguida, envie mensagens de teste para provedores externos e responda a partir deles para confirmar ida e volta.

1. Acesse webmail no novo servidor com a conta migrada.
2. Confira INBOX, Sent, Drafts, Trash e subpastas.
3. Envie uma mensagem para endereço externo.
4. Responda a mensagem externa para testar recebimento.
5. Verifique logs do serviço se houver atraso ou rejeição.

resolvectl query -t TXT seudominio.com.br

Output esperado:
seudominio.com.br IN TXT "v=spf1 ip4:198.51.100.20 include:seudominio.com.br -all"

resolvectl query -t TXT _dmarc.seudominio.com.br

Output esperado:
_dmarc.seudominio.com.br IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

Se o novo servidor envia pelo domínio, o SPF precisa autorizar o novo IP ou serviço de envio. DKIM e DMARC devem ser revisados para reduzir falhas de autenticação. Não altere políticas agressivas sem testar; primeiro confirme que o novo fluxo de envio está assinando e autenticando corretamente.

Problemas comuns e como resolver

Sintoma: IMAPSync conecta na origem, mas falha no destino

Causa: o IMAP do novo servidor pode não estar ativo, a conta pode não existir, a senha pode estar errada ou o firewall pode bloquear a porta segura de IMAP. Solução: teste login no webmail do destino, confirme portas com ss e rode novamente a sincronização apenas quando a autenticação estiver válida.

Sintoma: mensagens copiadas por rsync não aparecem no webmail

Causa: o caminho da mailbox pode estar errado ou os arquivos podem ter sido copiados com dono e permissões incompatíveis com o serviço IMAP. Solução: compare o caminho esperado pelo servidor de e-mail, ajuste dono e grupo conforme o padrão do destino e reinicie somente o serviço necessário se a indexação não atualizar.

Sintoma: usuários recebem mensagens no servidor antigo após trocar MX

Causa: propagação DNS e caches externos ainda podem entregar mensagens no MX anterior por algum tempo. Solução: mantenha o servidor antigo ativo, faça uma sincronização final depois da virada e só desative a origem após validar que não há novas entregas relevantes.

Sintoma: envio funciona, mas mensagens caem em falha de autenticação

Causa: o novo IP ou serviço de envio não foi incluído no SPF, a assinatura DKIM não foi configurada ou o DMARC está avaliando o novo fluxo como não autorizado. Solução: revise os registros TXT do domínio, valide o seletor DKIM usado pelo novo servidor e mantenha política DMARC compatível com a fase de migração até concluir os testes.

Perguntas frequentes sobre IMAPSync vs rsync

Como migrar e-mail corporativo para outro servidor Linux sem perder mensagens?

A forma mais segura é auditar as contas, fazer backup, sincronizar as caixas antes da troca de DNS e validar o histórico no novo servidor. Em migrações IMAP, ferramentas de sincronização preservam mensagens e pastas quando as credenciais e permissões estão corretas.

IMAPSync ou rsync: qual usar para manter o histórico dos e-mails?

IMAPSync é indicado quando você precisa copiar mensagens entre servidores acessando as caixas por IMAP, inclusive entre estruturas diferentes. Rsync é mais adequado quando você controla os arquivos locais do serviço de e-mail e precisa replicar diretórios de mailboxes no nível do sistema de arquivos.

Preciso alterar MX antes ou depois de copiar as mensagens?

O ideal é copiar o histórico primeiro, reduzir o TTL com antecedência e alterar o MX apenas na janela de virada. Depois da troca, faça uma sincronização final para capturar mensagens recebidas no servidor antigo durante a propagação DNS.

Como confirmar que nenhuma caixa de e-mail ficou incompleta após a migração?

Compare a lista de contas, pastas e volume de mensagens entre origem e destino, além de testar login via webmail ou cliente IMAP. Também é importante enviar e receber mensagens de teste e verificar logs do serviço de e-mail no novo servidor.

A migração de e-mail corporativo afeta SPF, DKIM e DMARC?

Pode afetar se o novo servidor passar a enviar mensagens pelo domínio. Nesse caso, revise os registros SPF, DKIM e DMARC no DNS para autorizar o novo IP ou serviço de envio e reduzir falhas de autenticação.

Conclusão

• Escolha IMAPSync quando a migração depende de acesso IMAP e compatibilidade entre servidores diferentes.
• Escolha rsync quando você controla os diretórios de mailbox e consegue preservar caminhos, donos e permissões.
• Não altere o MX antes de copiar o histórico; faça a virada, sincronize novamente e valide DNS, pastas, envio e recebimento.

Leia também

• Solucionar problemas de DNS no VPS Linux gratuito vs pago: vale a pena investir em 2025?
• migrar email corporativo para Gmail sem perder mensagens
• Entenda backup WhatsApp no e-mail corporativo Linux

Precisa de ajuda com migração de e-mail corporativo com histórico?

Uma migração de e-mail exige planejamento de DNS, autenticação, cópia de histórico e validação pós-virada. Se você quer reduzir riscos durante a mudança de servidor, fale com a equipe da AviraHost para avaliar o melhor caminho para o seu ambiente.

Solicitar suporte para migração de e-mail