Checklist de migração de servidor de outro provedor com o mínimo de downtime: inventário, TTL de DNS, sincronização final, virada, rollback e pós-migração.

Para que serve

Trazer sistemas de outro provedor para o seu servidor dedicado envolve muito mais que copiar arquivos. A maior parte das indisponibilidades acontece por um detalhe esquecido: um registro DNS com TTL de um dia, um cron que não foi recriado, um IP liberado no firewall de um parceiro. Este checklist organiza a migração de servidor em fases, com o objetivo de deixar a janela de parada em minutos e ter sempre um caminho de volta. Os detalhes técnicos de cada cópia estão nos outros artigos desta categoria (rsync, bancos, cPanel) e no artigo «Como migrar VMs para o Proxmox VE: VMware ESXi, Hyper-V e outro provedor».

Pré-requisitos

  • Servidor novo entregue e acessível (SSH, RDP ou painel do Proxmox) e acesso ao console IPMI/iLO.
  • Acesso administrativo ao servidor antigo durante toda a migração. Não cancele o contrato antigo antes de terminar.
  • Acesso ao painel onde o DNS dos domínios é gerenciado (Registro.br, Cloudflare, o próprio provedor antigo etc.).

Fase 1: inventário (1 a 2 semanas antes)

  • Serviços e versões: sistema operacional, servidor web, PHP, banco de dados, Java/.NET, ERP. Anote versões exatas: migrar e atualizar ao mesmo tempo multiplica os riscos.
  • Portas e regras de firewall abertas hoje (ss -tlnp no Linux, Get-NetTCPConnection -State Listen no Windows).
  • Tarefas agendadas: crontab -l de cada usuário, /etc/cron.d, timers do systemd, Agendador de Tarefas do Windows.
  • Certificados SSL e onde são renovados.
  • Todos os registros DNS de cada domínio: A, AAAA, MX, TXT (SPF, DKIM, DMARC), CNAME, SRV. Exporte a zona se o painel permitir.
  • Dependências externas que conhecem o IP antigo: liberações em firewall de bancos, APIs de pagamento, VPNs site-to-site com filiais, SPF de e-mail, licenças de software amarradas a IP ou MAC.
  • Volume de dados e taxa de mudança, para estimar o tempo de cópia. Com 1 Gbps, conte de forma conservadora com cerca de 300 a 400 GB por hora no melhor caso; o limite costuma ser o uplink do provedor antigo.

Fase 2: preparação (3 a 7 dias antes)

  1. Reduza o TTL dos registros que vão mudar (A, AAAA e, se for o caso, MX) para 300 segundos. Faça isso com antecedência de pelo menos o TTL atual: se o registro estava com 86400 (24 horas), os resolvedores podem guardar o valor antigo por até 24 horas depois da redução. Confira o TTL em vigor:

    dig +noall +answer www.seudominio.com.br A

  2. Monte o servidor novo com as mesmas versões de software, usuários, permissões e regras de firewall. Planeje os IPs do seu bloco /28 que cada serviço vai usar (veja também o artigo «Como configurar IP adicional no Linux e no Windows Server: bloco /28 e IPv6 /56 (netplan, ifupdown, Proxmox)»).

  3. Faça a cópia inicial com o sistema antigo no ar: rsync de arquivos, restauração de um dump do banco, transferência de contas cPanel ou importação das VMs. Essa cópia leva tempo, mas não causa parada.

  4. Teste o servidor novo sem mexer no DNS, apontando o domínio para o IP novo só no seu computador. No Linux/macOS edite /etc/hosts; no Windows, C:\Windows\System32\drivers\etc\hosts:

    203.0.113.20   www.seudominio.com.br seudominio.com.br

    Navegue pelo sistema, faça login, gere um relatório, envie um e-mail de teste. Remova a linha depois.

  5. Ensaie a sincronização final e cronometre. O tempo do rsync incremental e do dump/restauração do banco define o tamanho real da janela de parada.

  6. Escreva o plano de rollback com critério objetivo de desistência (ex.: "se o ERP não abrir até 30 minutos após a virada, voltamos").

  7. Avise usuários e parceiros sobre a janela e envie o IP novo para quem precisa liberar em firewall.

Fase 3: virada (dia D)

  1. Coloque a aplicação em manutenção no servidor antigo ou pare os serviços que gravam dados (aplicação, filas, cron). Leitura pode continuar.
  2. Faça a sincronização final: rsync incremental dos arquivos e dump/restauração final do banco (ou promoção da réplica, se você montou replicação).
  3. Confira contagens: número de arquivos, tamanho das pastas principais, registros nas tabelas mais movimentadas.
  4. Suba os serviços no servidor novo e teste novamente pelo arquivo hosts.
  5. Altere os registros DNS para os IPs novos.

  6. No servidor antigo, redirecione o tráfego residual para o novo, para atender quem ainda tem o IP antigo em cache. Para sites, um proxy reverso no Nginx/Apache antigo apontando para o IP novo resolve. Para outros serviços em Linux, um DNAT funciona:

    sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination 203.0.113.20:443
iptables -t nat -A POSTROUTING -p tcp -d 203.0.113.20 --dport 443 -j MASQUERADE
    Regras de NAT e firewall erradas podem derrubar o acesso SSH ao servidor antigo. Aplique-as com uma sessão de console aberta no provedor antigo e sem salvar as regras de forma persistente até confirmar que funcionam. No servidor novo, se perder acesso após mudar rede ou firewall, entre pelo console IPMI/iLO para desfazer.
  7. Acompanhe os logs dos dois servidores. Quando o antigo parar de receber requisições, a propagação terminou.

Fase 4: rollback (se necessário)

  • Se o critério de desistência for atingido antes de liberar gravações no servidor novo: volte o DNS, remova o redirecionamento e religue os serviços no antigo. Nada se perde.
  • Se o servidor novo já recebeu gravações, voltar exige copiar esses dados de volta (rsync no sentido inverso, dump do banco novo). Por isso, defina um ponto de não retorno e evite liberar gravações até ter certeza.

Fase 5: pós-migração (D+1 a D+15)

  • Volte o TTL dos registros para o valor normal (3600 ou mais).
  • Atualize SPF, PTR (DNS reverso, configurado por você na Central do Cliente: Serviços → seu servidor → lista de IPs) e liberações de IP em parceiros. Veja também o artigo «Como configurar DNS reverso (PTR), SPF, DKIM e DMARC para o e-mail não cair no spam».
  • Configure e teste os backups no servidor novo antes de qualquer outra coisa.
  • Mantenha o servidor antigo ligado, sem receber gravações, por 7 a 15 dias. Faça um backup final completo dele antes de cancelar.

Como saber se a migração de servidor funcionou

  • dig +short seudominio.com.br @8.8.8.8 e @1.1.1.1 retornam o IP novo.
  • Os logs do servidor antigo não mostram mais acessos de clientes.
  • Tarefas agendadas, envio de e-mail e integrações rodaram com sucesso no servidor novo pelo menos uma vez.

Problemas comuns

Parte dos usuários ainda cai no servidor antigo

Algum resolvedor ainda guarda o TTL antigo, ou o TTL não foi reduzido a tempo. O redirecionamento da fase 3 cobre essa janela. Se você trocou os servidores DNS (NS) do domínio, a troca de delegação pode levar mais tempo, porque o TTL dos registros NS é definido pelo registro do domínio; prefira mudar só os registros A/AAAA quando possível.

E-mails sumiram durante a virada

Mensagens entregues no servidor antigo depois da sincronização final ficaram lá. Rode uma nova sincronização das caixas de correio (rsync das pastas Maildir ou imapsync) após a propagação.

Aplicação conecta no banco antigo

Arquivos de configuração com IP fixo do banco ou do servidor antigo. Procure com grep -r "IP_ANTIGO" /etc /var/www /srv antes da virada.

Perguntas frequentes

Dá para migrar um servidor sem nenhum downtime?

Na maioria dos casos sobra uma janela curta, de minutos, para a sincronização final dos dados. Com cópia inicial antecipada, TTL baixo e redirecionamento no servidor antigo, essa janela fica pequena.

Quanto tempo antes devo baixar o TTL do DNS?

Pelo menos o valor do TTL atual. Se o registro está com 86400 segundos, reduza para 300 com no mínimo 24 horas de antecedência.

Como testar o servidor novo antes de mudar o DNS?

Aponte o domínio para o IP novo apenas no seu computador, editando o arquivo hosts, e teste o sistema normalmente. Remova a linha depois.

Quando posso cancelar o servidor antigo?

Depois que ele parar de receber acessos e o servidor novo já tiver backups testados. Mantenha o antigo por 7 a 15 dias e faça um backup final completo antes de cancelar.

Como configurar o DNS reverso do IP novo?

Você mesmo configura na Central do Cliente, em Serviços, clicando no servidor e ajustando o reverso na lista de IPs.

Leitura complementar

Precisa de ajuda?

Vai migrar para a E-Consulters e quer revisar o plano, ou tem dúvida sobre a rede do servidor? Abra um ticket na área do cliente ou fale com o suporte pelo WhatsApp.

Esta resposta lhe foi útil? 0 Usuários acharam útil (0 Votos)

Leia também