Como migrar servidor entre provedores sem downtime

Tempo estimado: 60-90 minutos

Dificuldade: Avançado

Este guia mostra uma estratégia prática para migrar um servidor Linux entre provedores com downtime zero ou quase zero. O cenário usado é um servidor Ubuntu 22.04 com Nginx, aplicação web em /var/www/app, MySQL e domínio app.melhorvps.net. O servidor antigo usa o IP 203.0.113.10 e o novo usa 198.51.100.25. Troque esses valores pelos seus, mas mantenha a mesma lógica.

Antes de começar, trate a migração como uma mudança de produção. Você vai validar cada etapa, manter o servidor antigo funcional e só apontar o tráfego quando o novo servidor estiver respondendo corretamente. Se você ainda está escolhendo o destino, veja também o guia sobre diferenças entre cloud server e VPS para entender limites de rede, disco e isolamento.

O que você vai aprender

Ao final deste guia, você vai conseguir:

• Planejar uma migração entre provedores sem depender apenas da propagação de DNS.
• Reduzir TTL de registros DNS antes da virada de tráfego.
• Preparar o novo servidor com pacotes, firewall, diretórios e serviços equivalentes.
• Fazer backup e sincronização incremental com rsync sem copiar arquivos temporários desnecessários.
• Migrar banco MySQL com uma etapa final curta de congelamento de escrita.
• Usar Nginx no servidor antigo como proxy temporário para encaminhar usuários atrasados ao servidor novo.
• Validar aplicação, headers, logs, conectividade e plano de rollback antes de encerrar o servidor antigo.

A ideia central é simples: primeiro você copia quase tudo com o sistema ainda em produção. Depois executa uma sincronização final curta, muda o DNS e mantém o servidor antigo encaminhando conexões para o novo. Assim, quem ainda resolver o IP antigo não recebe erro, recebe a aplicação no novo destino.

Pré-requisitos

Você precisa de acesso SSH com sudo nos dois servidores. Neste guia, o servidor antigo será chamado de old-vps e o novo de new-vps. Configure variáveis no seu terminal local para evitar digitação repetida:

export OLD_IP=203.0.113.10
export NEW_IP=198.51.100.25
export DOMAIN=app.melhorvps.net
export SSH_USER=ubuntu

Teste o acesso aos dois servidores:

ssh $SSH_USER@$OLD_IP 'hostname && uptime'
ssh $SSH_USER@$NEW_IP 'hostname && uptime'

Saída esperada:

old-vps
 10:21:44 up 42 days,  3 users,  load average: 0.18, 0.22, 0.20
new-vps
 10:22:01 up 4 min,  1 user,  load average: 0.02, 0.01, 0.00

Você também precisa controlar o DNS do domínio, conhecer o serviço de banco em uso e ter espaço em disco suficiente no novo servidor. Verifique disco e memória nos dois lados:

ssh $SSH_USER@$OLD_IP 'df -h / /var && free -h'
ssh $SSH_USER@$NEW_IP 'df -h / /var && free -h'

Saída esperada:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        50G   21G   27G  44% /
              total        used        free      shared  buff/cache   available
Mem:          1.9Gi       620Mi       780Mi        40Mi       520Mi       1.1Gi

Tenha uma janela de baixo tráfego para a etapa final. Mesmo com proxy temporário, você vai fazer mudanças sensíveis. Se a aplicação grava muitos dados por minuto, planeje uma pausa curta de escrita ou coloque a aplicação em modo manutenção apenas para operações que alteram dados.

Passo 1: Mapear o servidor atual e reduzir o TTL do DNS

Comece inventariando o que roda no servidor antigo. Essa etapa evita surpresas, como um worker esquecido no cron, uma fila em Redis ou um serviço escutando porta não documentada. Execute no servidor antigo:

ssh $SSH_USER@$OLD_IP 'hostnamectl; systemctl --type=service --state=running --no-pager; ss -tulpn'

Você deve ver algo parecido com:

Operating System: Ubuntu 22.04.4 LTS
  nginx.service loaded active running A high performance web server
  mysql.service loaded active running MySQL Community Server
  ssh.service loaded active running OpenBSD Secure Shell server
Netid State  Local Address:Port  Process
tcp   LISTEN 0.0.0.0:80          users:(('nginx',pid=812,fd=6))
tcp   LISTEN 0.0.0.0:443         users:(('nginx',pid=812,fd=7))
tcp   LISTEN 127.0.0.1:3306      users:(('mysqld',pid=920,fd=21))

Agora descubra o TTL atual do domínio:

dig +nocmd $DOMAIN A +noall +answer

Saída esperada:

app.melhorvps.net. 3600 IN A 203.0.113.10

Reduza o TTL do registro A para 60 ou 120 segundos no painel DNS do seu provedor. Faça isso pelo menos algumas horas antes da migração, preferencialmente 24 horas antes, para que caches antigos expirem. Depois valide:

dig +nocmd $DOMAIN A +noall +answer @1.1.1.1
dig +nocmd $DOMAIN A +noall +answer @8.8.8.8

Saída esperada após a alteração:

app.melhorvps.net. 60 IN A 203.0.113.10

Se o TTL ainda aparece como 3600, aguarde. Não avance para a virada final até enxergar TTL baixo em resolvedores públicos. Enquanto isso, documente caminhos críticos:

ssh $SSH_USER@$OLD_IP 'ls -lah /var/www; crontab -l || true; sudo ls -lah /etc/nginx/sites-enabled'

Esse mapeamento também ajuda a comparar provedores e recursos. Se você está saindo por falta de desempenho, use a lista de melhores opções de VPS no Brasil como referência para latência, localização e suporte.

Passo 2: Preparar o servidor novo com os mesmos serviços

No novo servidor, instale os pacotes necessários e aplique atualizações. O comando abaixo não remove dados, mas pode reiniciar serviços se houver atualizações de segurança. Execute em horário seguro:

ssh $SSH_USER@$NEW_IP 'sudo apt update && sudo apt install -y nginx mysql-server rsync curl dnsutils ufw'

Saída esperada:

Reading package lists... Done
Building dependency tree... Done
nginx is already the newest version or will be installed
mysql-server is already the newest version or will be installed
rsync is already the newest version or will be installed

Configure o firewall antes de expor o serviço. Libere SSH, HTTP e HTTPS. Se você usa porta SSH diferente, ajuste antes de ativar o UFW para não se bloquear.

ssh $SSH_USER@$NEW_IP 'sudo ufw allow OpenSSH && sudo ufw allow 80/tcp && sudo ufw allow 443/tcp && sudo ufw --force enable && sudo ufw status verbose'

Saída esperada:

Firewall is active and enabled on system startup
Status: active
To                         Action      From
22/tcp                     ALLOW IN    Anywhere
80/tcp                     ALLOW IN    Anywhere
443/tcp                    ALLOW IN    Anywhere

Crie o diretório da aplicação e ajuste permissões. Use o mesmo caminho do servidor antigo para reduzir mudanças de configuração:

ssh $SSH_USER@$NEW_IP 'sudo mkdir -p /var/www/app && sudo chown -R ubuntu:www-data /var/www/app && sudo chmod 775 /var/www/app'

Verifique:

ssh $SSH_USER@$NEW_IP 'ls -ld /var/www/app && nginx -v && mysql --version'

Saída esperada:

drwxrwxr-x 2 ubuntu www-data 4096 Aug 17 10:40 /var/www/app
nginx version: nginx/1.18.0 (Ubuntu)
mysql  Ver 8.0.39-0ubuntu0.22.04.1 for Linux on x86_64

Copie a configuração do Nginx do servidor antigo, mas ainda não habilite tráfego público definitivo. Primeiro, faça backup local no novo servidor:

ssh $SSH_USER@$NEW_IP 'sudo cp -a /etc/nginx /etc/nginx.backup.$(date +%F-%H%M%S)'

Esse backup permite voltar para uma configuração limpa caso a cópia traga diretivas incompatíveis. Mais adiante você vai testar o Nginx com nginx -t antes de recarregar.

Passo 3: Fazer backup e sincronizar arquivos com rsync

Antes de copiar, faça um backup verificável no servidor antigo. Se você já usa snapshots ou rotina externa, mantenha mesmo assim um pacote local dos arquivos de configuração mais críticos. Para uma estratégia contínua, consulte o guia sobre VPS com backup automático.

ssh $SSH_USER@$OLD_IP 'sudo tar -czf /root/pre-migration-etc-nginx-www.tgz /etc/nginx /var/www/app && sudo ls -lh /root/pre-migration-etc-nginx-www.tgz'

Saída esperada:

-rw-r--r-- 1 root root 184M Aug 17 10:50 /root/pre-migration-etc-nginx-www.tgz

Agora execute a primeira sincronização de arquivos. Ela pode rodar com a aplicação online. Use --numeric-ids para preservar donos por UID quando fizer sentido e exclua caches, logs e diretórios temporários. O --delete remove no destino arquivos que não existem na origem. Ele é útil para espelhar, mas pode apagar conteúdo no servidor novo. Confirme que o destino está correto antes de usar.

rsync -aHAXvz --numeric-ids --delete \
  --exclude='cache/' --exclude='tmp/' --exclude='*.log' \
  -e ssh $SSH_USER@$OLD_IP:/var/www/app/ \
  $SSH_USER@$NEW_IP:/var/www/app/

Saída esperada:

receiving incremental file list
./
index.php
public/
public/assets/app.css
sent 12,480 bytes  received 148,203,912 bytes  9,561,702.71 bytes/sec
total size is 512,944,120  speedup is 3.46

Copie também a configuração do Nginx para uma área temporária no novo servidor:

rsync -aHAXvz -e ssh $SSH_USER@$OLD_IP:/etc/nginx/ $SSH_USER@$NEW_IP:/tmp/nginx-from-old/
ssh $SSH_USER@$NEW_IP 'sudo rsync -a /tmp/nginx-from-old/ /etc/nginx/ && sudo nginx -t'

Saída esperada:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Se o teste falhar por certificados ausentes, não force o reload. Copie /etc/letsencrypt se você usa Certbot ou emita certificados novos depois de apontar o DNS. Para a fase de teste por IP, você consegue validar HTTP e aplicação local antes de resolver HTTPS final.

Passo 4: Migrar banco de dados com janela de escrita controlada

Banco de dados é a parte mais sensível. Se a aplicação continuar gravando durante o dump final, você pode perder pedidos, usuários ou sessões. A estratégia segura é fazer uma carga inicial, depois uma etapa final com escrita pausada por poucos minutos. Primeiro, descubra o tamanho dos bancos no servidor antigo:

ssh $SSH_USER@$OLD_IP "sudo mysql -e 'SELECT table_schema AS db, ROUND(SUM(data_length+index_length)/1024/1024,1) AS mb FROM information_schema.tables GROUP BY table_schema;'"

Saída esperada:

db	mb
appdb	842.7
mysql	3.1
performance_schema	0.0
sys	0.1

Faça um dump inicial com transação consistente. O comando abaixo não bloqueia tabelas InnoDB por muito tempo, mas ainda consome CPU e disco. Verifique espaço antes:

ssh $SSH_USER@$OLD_IP 'df -h /root && sudo mysqldump --single-transaction --routines --triggers --events appdb | gzip > /root/appdb-initial.sql.gz && ls -lh /root/appdb-initial.sql.gz'

Saída esperada:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        50G   22G   26G  46% /
-rw-r--r-- 1 root root 126M Aug 17 11:05 /root/appdb-initial.sql.gz

Transfira e importe no novo servidor:

scp $SSH_USER@$OLD_IP:/root/appdb-initial.sql.gz /tmp/appdb-initial.sql.gz
scp /tmp/appdb-initial.sql.gz $SSH_USER@$NEW_IP:/tmp/appdb-initial.sql.gz
ssh $SSH_USER@$NEW_IP "sudo mysql -e 'CREATE DATABASE IF NOT EXISTS appdb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;' && zcat /tmp/appdb-initial.sql.gz | sudo mysql appdb"

Valide contagem de tabelas nos dois lados:

ssh $SSH_USER@$OLD_IP "sudo mysql -N -e 'SELECT COUNT(*) FROM information_schema.tables WHERE table_schema=\"appdb\";'"
ssh $SSH_USER@$NEW_IP "sudo mysql -N -e 'SELECT COUNT(*) FROM information_schema.tables WHERE table_schema=\"appdb\";'"

Saída esperada:

48
48

Para a sincronização final, coloque a aplicação em modo somente leitura ou manutenção de escrita. O método varia. Em muitas aplicações, você pode criar uma flag:

ssh $SSH_USER@$OLD_IP 'touch /var/www/app/storage/maintenance_write_lock && ls -l /var/www/app/storage/maintenance_write_lock'

Saída esperada:

-rw-rw-r-- 1 ubuntu www-data 0 Aug 17 11:20 /var/www/app/storage/maintenance_write_lock

Faça um dump final e importe novamente. Se o banco for grande, prefira replicação nativa. Para bancos pequenos e médios, o dump final costuma ficar dentro da janela planejada.

Passo 5: Configurar proxy temporário para absorver a propagação

Mesmo com TTL baixo, alguns usuários ainda podem resolver o IP antigo por minutos ou horas. Para evitar erro, transforme o Nginx do servidor antigo em um proxy temporário para o novo servidor. Antes de mexer no Nginx antigo, faça backup da configuração atual:

ssh $SSH_USER@$OLD_IP 'sudo cp -a /etc/nginx /etc/nginx.pre-proxy.$(date +%F-%H%M%S) && sudo ls -ld /etc/nginx.pre-proxy.* | tail -1'

Saída esperada:

drwxr-xr-x 8 root root 4096 Aug 17 11:30 /etc/nginx.pre-proxy.2026-08-17-113000

Crie um bloco de proxy para o domínio. Este comando substitui o site app-migration-proxy apenas, não apaga outros arquivos. Ajuste o nome do server_name se seu domínio for diferente.

ssh $SSH_USER@$OLD_IP "sudo tee /etc/nginx/sites-available/app-migration-proxy >/dev/null <<'EOF'
server {
    listen 80;
    server_name app.melhorvps.net;

    location / {
        proxy_pass http://198.51.100.25;
        proxy_set_header Host \$host;
        proxy_set_header X-Real-IP \$remote_addr;
        proxy_set_header X-Forwarded-For \$proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto \$scheme;
        proxy_connect_timeout 5s;
        proxy_read_timeout 60s;
    }
}
EOF
sudo ln -sf /etc/nginx/sites-available/app-migration-proxy /etc/nginx/sites-enabled/app-migration-proxy
sudo nginx -t"

Saída esperada:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Se o servidor antigo já tem um bloco ativo para o mesmo server_name, você precisa desabilitá-lo ou ele pode vencer a seleção do Nginx. Não remova sem backup. Renomeie o link em sites-enabled e teste:

ssh $SSH_USER@$OLD_IP 'sudo ls -l /etc/nginx/sites-enabled && sudo systemctl reload nginx && systemctl status nginx --no-pager -l | head -20'

Saída esperada:

Active: active (running)

Agora teste o proxy forçando resolução para o IP antigo:

curl -I --resolve $DOMAIN:80:$OLD_IP http://$DOMAIN/

Saída esperada:

HTTP/1.1 200 OK
Server: nginx

Passo 6: Virar o tráfego e manter rollback pronto

Com arquivos, banco e proxy testados, faça a sincronização final. Primeiro, confirme que o novo servidor está respondendo quando você força o domínio para o IP novo:

curl -I --resolve $DOMAIN:80:$NEW_IP http://$DOMAIN/

Saída esperada:

HTTP/1.1 200 OK
Server: nginx

Execute o rsync final. Ele deve ser rápido, pois a maior parte já foi copiada. O aviso sobre --delete continua valendo: confira origem e destino antes de pressionar Enter.

rsync -aHAXvz --numeric-ids --delete \
  --exclude='cache/' --exclude='tmp/' --exclude='*.log' \
  -e ssh $SSH_USER@$OLD_IP:/var/www/app/ \
  $SSH_USER@$NEW_IP:/var/www/app/

Saída esperada:

receiving incremental file list
storage/uploads/new-image.png
sent 4,120 bytes  received 8,340,112 bytes  1,283,712.61 bytes/sec
total size is 513,200,448  speedup is 61.52

Faça o dump final do banco com escrita pausada, transfira e importe. Se você não puder sobrescrever o banco, importe em um banco temporário e troque credenciais depois. O exemplo abaixo assume janela controlada e banco appdb.

ssh $SSH_USER@$OLD_IP 'sudo mysqldump --single-transaction --routines --triggers --events appdb | gzip > /root/appdb-final.sql.gz'
scp $SSH_USER@$OLD_IP:/root/appdb-final.sql.gz /tmp/appdb-final.sql.gz
scp /tmp/appdb-final.sql.gz $SSH_USER@$NEW_IP:/tmp/appdb-final.sql.gz
ssh $SSH_USER@$NEW_IP "sudo mysql -e 'DROP DATABASE IF EXISTS appdb_migration_check; CREATE DATABASE appdb_migration_check CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;' && zcat /tmp/appdb-final.sql.gz | sudo mysql appdb_migration_check"

Atenção: DROP DATABASE IF EXISTS appdb_migration_check apaga apenas o banco temporário de conferência. Não use esse padrão no banco de produção sem backup e confirmação dupla.

Aponte o registro A do DNS para 198.51.100.25. Em seguida, monitore as respostas:

watch -n 5 "dig +short $DOMAIN A @1.1.1.1; curl -s -o /dev/null -w '%{http_code} %{remote_ip}\n' http://$DOMAIN/"

Saída esperada:

198.51.100.25
200 198.51.100.25

Mantenha o servidor antigo ligado por 24 a 72 horas. O rollback é simples enquanto ele existe: retorne o DNS para 203.0.113.10, remova o proxy ou restaure /etc/nginx.pre-proxy.* e reabra escrita no antigo.

Verificação e testes

Depois da virada, teste por três caminhos: DNS público, IP novo direto e proxy antigo. Isso confirma que usuários novos e atrasados chegam à aplicação.

dig +nocmd $DOMAIN A +noall +answer @1.1.1.1
curl -I --resolve $DOMAIN:80:$NEW_IP http://$DOMAIN/
curl -I --resolve $DOMAIN:80:$OLD_IP http://$DOMAIN/

Saída esperada:

app.melhorvps.net. 60 IN A 198.51.100.25
HTTP/1.1 200 OK
HTTP/1.1 200 OK

Confira logs no novo servidor enquanto acessa a aplicação pelo navegador:

ssh $SSH_USER@$NEW_IP 'sudo tail -f /var/log/nginx/access.log /var/log/nginx/error.log'

Saída esperada:

198.51.100.40 - - [17/Aug/2026:12:10:02 +0000] "GET / HTTP/1.1" 200 6152

Valide banco e uploads recentes. Crie um arquivo de teste pelo fluxo normal da aplicação ou faça uma consulta conhecida. Para MySQL:

ssh $SSH_USER@$NEW_IP "sudo mysql -e 'SELECT NOW() AS db_time; SELECT COUNT(*) AS tables_count FROM information_schema.tables WHERE table_schema=\"appdb\";'"

Saída esperada:

db_time
2026-08-17 12:12:44
tables_count
48

Verifique serviços habilitados no boot:

ssh $SSH_USER@$NEW_IP 'systemctl is-enabled nginx mysql; systemctl is-active nginx mysql'

Saída esperada:

enabled
enabled
active
active

Por fim, acompanhe métricas básicas:

ssh $SSH_USER@$NEW_IP 'uptime; free -h; df -h /var; ss -s'

Se CPU, memória e conexões estiverem normais por algumas horas, a migração pode ser considerada estável.

Troubleshooting

1. O domínio ainda aponta para o IP antigo.

Verifique TTL e resolvedores diferentes. Alguns provedores ignoram TTL baixo por cache interno.

dig +trace $DOMAIN A
dig +short $DOMAIN A @1.1.1.1
dig +short $DOMAIN A @8.8.8.8

Se apenas alguns resolvedores retornam o IP antigo, mantenha o proxy ativo. Não desligue o servidor antigo. Se todos retornam o IP antigo, revise o painel DNS e confirme que você alterou a zona autoritativa correta.

2. O Nginx retorna 502 pelo proxy antigo.

Teste conectividade do antigo para o novo:

ssh $SSH_USER@$OLD_IP "curl -I http://198.51.100.25/ && nc -vz 198.51.100.25 80"

Saída saudável:

HTTP/1.1 200 OK
Connection to 198.51.100.25 80 port [tcp/http] succeeded!

Se falhar, verifique UFW no novo servidor e se o Nginx está escutando em 0.0.0.0:80, não apenas em 127.0.0.1.

3. A aplicação abre, mas login ou uploads falham.

Geralmente é permissão, caminho absoluto ou variável de ambiente. Compare donos e permissões:

ssh $SSH_USER@$NEW_IP 'sudo find /var/www/app -maxdepth 2 -type d -printf "%u:%g %m %p\n" | head -30'

Ajuste somente diretórios necessários, por exemplo storage e uploads. Evite chmod 777. Use:

ssh $SSH_USER@$NEW_IP 'sudo chown -R www-data:www-data /var/www/app/storage /var/www/app/public/uploads'

4. O banco importou, mas dados recentes sumiram.

Você provavelmente fez a virada antes do dump final ou permitiu escrita no antigo depois da exportação. Reabra o antigo apenas se for rollback completo. Para recuperar pontualmente, compare tabelas modificadas e exporte registros específicos. Não execute comandos de exclusão no banco novo sem backup.

5. HTTPS falha depois da migração.

Verifique certificados e server_name:

ssh $SSH_USER@$NEW_IP 'sudo nginx -t; sudo ls -lah /etc/letsencrypt/live || true'

Se os certificados não foram copiados, emita novamente com Certbot depois que o DNS público apontar para o novo IP.

Próximos passos

Quando a migração estiver estável por 24 a 72 horas, remova o proxy temporário do servidor antigo e faça um último backup antes de desligá-lo. Guarde esse backup por alguns dias, especialmente se a aplicação lida com pagamentos, uploads de usuários ou auditoria.

Atualize registros operacionais: IP novo, fingerprints SSH, regras de firewall, scripts de deploy, monitoramento e alertas. Se sua equipe usa CI/CD, revise variáveis secretas e chaves conhecidas. Também ajuste SPF, DKIM ou integrações externas se o servidor envia e-mails.

Configure monitoramento no novo provedor e crie uma rotina de backup automatizada. Migração sem downtime não termina na troca de DNS. Ela termina quando você consegue restaurar o ambiente, auditar logs e repetir o processo com menos risco na próxima vez.

Depois de alguns dias, aumente o TTL do DNS para um valor normal, como 300 ou 3600 segundos, se você não espera novas mudanças. Isso reduz consultas DNS e deixa a zona mais estável.