Como migrar um site ou app para um novo servidor cloud
Para migrar para um servidor cloud com segurança, deixe a máquina antiga intacta até que a nova tenha servido tráfego real. Este guia é um plano para um site, uma loja ou uma aplicação: três checklists (antes, comutação e reversão), comandos que pode adaptar e limites honestos sobre o tempo de indisponibilidade. Dimensione primeiro o destino com o guia de dimensionamento de servidores cloud e escolha a região com o guia de localizações na Europa.
Escolha o método de migração
Quatro métodos cobrem quase qualquer mudança. Muitos projetos combinam dois.
| Método | Ideal para | Risco principal |
|---|---|---|
| rsync de ficheiros | Sites estáticos, uploads, código da app | Os dados mudam durante a cópia, é preciso uma sincronização final |
| Imagem ou restauro de backup | Mesmo sistema e estrutura, restauro testado | Drivers e nomes de rede antigos, mais dados a mover |
| Reimplantação da app | Contentores e código em git | O estado oculto do disco antigo é esquecido |
| Replicação de base de dados | Bases grandes ou muito ativas | Esforço de configuração e limites de versão |
Comece com um servidor cloud desde EUR 15.00/mês, verificado 2026-10 e ensaie lá todo o plano.
Checklist antes da migração
- Inventário - liste serviços, portas, tarefas cron, definições de e-mail, certificados, regras de firewall e todos os nomes que apontam para o IP antigo.
- Estado oculto - procure ficheiros fora da raiz web: uploads, filas, sessões, licenças, segredos em variáveis de ambiente.
- Backups - faça uma cópia completa do servidor antigo e restaure-a uma vez noutro lado, porque um backup por testar é só uma esperança.
- Acesso - só chaves SSH, uma firewall e um utilizador de deploy sem root no novo servidor.
- Snapshot - crie um snapshot do servidor novo antes da primeira sincronização real, para que um erro custe minutos.
Copie ficheiros e dados
Os exemplos usam o endereço de documentação 203.0.113.10 como servidor novo. Substitua nomes e caminhos pelos seus. Os passos 1 e 2 podem repetir-se sem risco; o passo 5 só corre com o site antigo em modo só de leitura.
# 1. Bulk copy while the old server keeps serving (repeat any time)
rsync -aHAX --numeric-ids --info=progress2 \
-e ssh /var/www/ deploy@203.0.113.10:/var/www/
# 2. Database dump and restore (MySQL / MariaDB shown)
mysqldump --single-transaction --routines --triggers appdb \
| gzip | ssh deploy@203.0.113.10 'gunzip | mysql appdb'
# 3. Test the new server under the real hostname, DNS untouched
curl -sS --resolve example.com:443:203.0.113.10 \
https://example.com/ -o /dev/null -w '%{http_code}\n'
# 4. Check the TTL resolvers will honour
dig +noall +answer example.com A
# 5. Final sync after the old site is read-only
rsync -aHAX --numeric-ids --delete \
-e ssh /var/www/ deploy@203.0.113.10:/var/www/
A opção --delete apaga no destino os ficheiros que já não existem na origem. Use-a apenas na última execução e só se souber qual dos lados é o mestre.
Teste primeiro com o ficheiro hosts
Antes de mudar o DNS, faça o seu próprio computador resolver o site para o servidor novo. Adicione uma linha ao ficheiro hosts (/etc/hosts, ou C:\Windows\System32\drivers\etc\hosts no Windows): 203.0.113.10 example.com www.example.com. A opção --resolve do curl (passo 3) faz o mesmo para um único pedido. Depois remova a linha, ou passará semanas a testar o servidor novo sem dar conta.
Reduza o TTL do DNS e comute
Reduza o TTL dos registos A e AAAA para cerca de 300 segundos, pelo menos um período completo do TTL antigo antes da mudança. Caso contrário, os resolvers mantêm o endereço antigo enquanto o TTL antigo o permitir. Alguns resolvers ignoram um TTL curto, por isso espere uma cauda de visitantes no IP antigo durante horas (uma estimativa, não uma medição).
Checklist de comutação:
- TTL - o valor reduzido está ativo e o antigo já expirou.
- Só leitura - o site antigo está em manutenção ou só de leitura.
- Sincronização final - último dump da base e passo 5 do código acima concluídos.
- DNS - os registos A e AAAA apontam para o IP novo; os de e-mail ficam como estão, a menos que o e-mail também mude.
- Teste rápido - login, encomenda, upload, e-mail, cron e certificado verificados no nome público.
- Servidor antigo - mantenha-o ligado, acessível e intocado.
Checklist de reversão
- Limite - decida antes o que conta como falha, por exemplo pagamentos falhados ou uma taxa de 5xx, e quem decide.
- DNS de volta - aponte os registos para o IP antigo; com um TTL baixo a maioria regressa em minutos ou horas.
- Escritas - reabra o site antigo. Se o novo aceitou encomendas ou uploads desde a comutação, exporte-os primeiro e repita-os no antigo.
O que o zero downtime exige de verdade
O zero downtime depende da arquitetura da sua aplicação e não é prometido para nenhum projeto. Exige uma app sem estado, uma base que replique ou aceite escritas dos dois lados, armazenamento partilhado ou replicado e uma comutação testada. Um site clássico com uma única base costuma ter uma curta janela só de leitura de minutos.
Depois da mudança
Acompanhe durante pelo menos uma semana os logs de erro, o disco, a memória, os tempos de resposta e a entrega de e-mail. Volte a subir o TTL do DNS quando tudo estiver estável. Desative o servidor antigo só depois de um ciclo completo de backups no novo; um backup semanal está incluído em cada preset. Teste antes de se comprometer com a checklist do período de teste; um teste curto pode ser possível escrevendo para sales@dcxv.com, a critério da DCXV e sem garantia.
Configure o servidor cloud de destino ou pergunte a um engenheiro sobre a migração.
