Migre um VPS para um novo host sem downtime

Os três relógios, e por que “zero downtime” é o alvo errado#

O que o host antigo guarda depois que você vai embora#

O relógio do TTL começa a correr uma semana antes da mudança#

dig +noall +answer example.com A
dig +noall +answer www.example.com A
dig +noall +answer example.com MX
dig +noall +answer example.com NS

Dimensionando a nova máquina, e o que verificar antes de se comprometer com ela#

# peak RAM actually in use, not allocated
free -m
# what has been paging, if anything
vmstat -s | grep -i swap
# real disk consumption, biggest first
du -xh --max-depth=2 / 2>/dev/null | sort -rh | head -20
# load relative to core count
uptime; nproc

Passo a passo#

1. Baixe todo TTL, dias antes de planejar a mudança

   Este é o primeiro porque é o único passo com um período de espera obrigatório. Tudo o mais pode ser feito numa tarde; este não pode ser apressado, e pulá-lo é o que transforma um corte de cinco minutos num de dois dias.

   Faça login onde quer que a sua zona viva e defina o TTL para 300 em todo registro que vai mudar: o ápice A, o AAAA, www, mail, e qualquer outra coisa apontando para um IP literal. Depois confirme de fora, porque painéis de controle e a realidade às vezes discordam:

   dig +noall +answer example.com A @1.1.1.1
   dig +noall +answer example.com AAAA @1.1.1.1
   dig +noall +answer www.example.com A @8.8.8.8

   O número antes de IN é o TTL restante. Consulte de novo um minuto depois: ele deveria estar contando regressivamente a partir de 300, não de algo maior. Se ainda estiver contando a partir de 3600, o valor antigo está em cache e você só espera passar — o que é exatamente por que isso acontece no dia menos sete, e não na manhã da mudança.

   Deixe o TTL em 300 durante a migração e por uma semana depois, para que o seu rollback também seja rápido. Coloque-o de volta em algo sensato — 3600 está bom — assim que a máquina antiga se for.

2. Faça o inventário do servidor antigo antes de copiar qualquer coisa

   Você não está migrando um disco, está migrando um sistema em execução, e as partes que as pessoas esquecem nunca estão em /var/www. São o cron job que roda no dia quatro do mês, a regra de firewall adicionada durante um incidente, o pacote instalado de um repositório de terceiros há dois anos. Capture o estado da máquina como texto, e copie esse texto junto com tudo o mais:

   mkdir -p /root/mig
   dpkg --get-selections > /root/mig/packages.txt
   systemctl list-units --type=service --state=running --no-pager > /root/mig/services.txt
   systemctl list-timers --all --no-pager > /root/mig/timers.txt
   crontab -l > /root/mig/cron-root.txt 2>/dev/null
   for u in $(cut -d: -f1 /etc/passwd); do crontab -lu "$u" 2>/dev/null | sed "s/^/[$u] /"; done > /root/mig/cron-users.txt
   ss -tlnp > /root/mig/listening.txt
   nft list ruleset > /root/mig/firewall.txt 2>/dev/null || iptables-save > /root/mig/firewall.txt
   cp -a /etc/hosts /etc/fstab /root/mig/
   du -xh --max-depth=2 / 2>/dev/null | sort -rh | head -40 > /root/mig/disk.txt

   Agora leia o listening.txt linha por linha e dê conta de cada porta. Esse arquivo é a resposta definitiva para “o que esse servidor realmente faz”, e rotineiramente é uma surpresa — um exportador de métricas, uma cópia de staging esquecida, um banco de dados escutando numa interface pública que nunca deveria ter estado ali.

   Escreva sua lista de exclusão ao mesmo tempo, para que a primeira sincronização não gaste uma hora em dados que você não quer:

   cat > /root/mig/excludes <<'EOF'
   /dev
   /proc
   /sys
   /run
   /tmp
   /var/tmp
   /var/cache
   /var/lib/apt/lists
   /swapfile
   /var/lib/docker/overlay2
   /var/lib/mysql
   /var/lib/postgresql
   **/node_modules
   **/.cache
   EOF

   Note que os diretórios do banco de dados são excluídos deliberadamente. Eles têm o seu próprio passo, e copiá-los aqui é o erro que o passo seis existe para evitar.

3. Implante o novo servidor e proteja-o antes de ele guardar qualquer coisa

   Peça a máquina, escolha a localização e mantenha a mesma versão principal do sistema operacional da antiga, se puder. Migrar de host e trocar de Debian 12 para Debian 13 na mesma operação significa que, quando algo quebrar, você não vai saber qual mudança causou isso. Migre primeiro, atualize depois.

   Antes de qualquer coisa sensível chegar nela, dê à máquina os dez minutos de hardening: SSH somente por chave, login root desabilitado, firewall com negação por padrão, atualizações de segurança automáticas. Isso leva dez minutos agora e é genuinamente tedioso de fazer depois, em torno de um serviço já no ar.

   Depois crie uma chave que existe só para esta migração, no servidor antigo, para que revogar o acesso de migração depois nunca signifique mexer no seu próprio login:

   # on the OLD server
   ssh-keygen -t ed25519 -f /root/.ssh/id_migrate -C 'migration' -N ''
   cat /root/.ssh/id_migrate.pub

   Coloque essa chave pública em /root/.ssh/authorized_keys no servidor novo, depois confirme a direção do envio — a antiga empurra para a nova, então a credencial mora na máquina que você está deixando para trás e morre com ela:

   ssh -i /root/.ssh/id_migrate root@NEW_IP 'hostname; df -h /; free -m'

   Por fim, coloque o novo IP no /etc/hosts do servidor antigo, sob um nome como newbox. Todo comando que vem a seguir fica mais curto e, mais útil ainda, mais difícil de apontar para a máquina errada à uma da manhã.

4. Verifique o novo IP antes de confiar qualquer coisa a ele

   Agora você tem um endereço que ninguém nunca usou para o seu serviço, e este é o último momento em que encontrar um problema nele é de graça. Três verificações, cinco minutos:

   Blocklists. Passe o endereço pelas checagens multi-RBL — o procedimento completo e como ler os resultados está aqui. Um acerto numa lista de política como a Spamhaus PBL é normal para um IP de datacenter e significa pouco para tráfego web. Um acerto na SBL ou XBL é um de verdade, e a hora de resolver isso é agora, não depois que os seus usuários já estiverem nele.

   DNS reverso. Verifique o que o endereço responde hoje:

   dig +short -x NEW_IP

   Se a máquina for mandar e-mail, peça o registro PTR que você quer e garanta que ele corresponda a um hostname cujo registro A aponte de volta para o mesmo IP. Direto e reverso precisam concordar; uma incompatibilidade é pior do que um nome genérico.

   Alcance e rota. Confirme que as portas que você precisa estão realmente abertas de ponta a ponta, de fora, em vez de presumir que o seu firewall é a única coisa no caminho:

   # from a third machine, or your laptop
   nc -vz NEW_IP 22
   mtr -rwc 20 NEW_IP

   A saída do mtr é a que vale a pena guardar. Perda no salto final importa; perda num salto intermediário geralmente é um roteador despriorizando ICMP e não significa nada. Se a latência a partir de onde os seus usuários estão for consideravelmente pior do que no host antigo, é melhor descobrir isso agora, enquanto mudar de ideia ainda custa um pedido e nenhum dado.

5. Copie o sistema de arquivos com rsync — e faça um dry-run primeiro

   Agora a transferência em massa. Faça em duas passadas: uma primeira cópia completa, dias antes, levando o tempo que precisar levar, depois passadas de delta curtas mais tarde que só movem o que mudou. Sempre faça um dry-run primeiro — a saída é uma lista exata do que está prestes a acontecer, e lê-la uma vez já salvou mais migrações do que qualquer outro hábito aqui.

   # on the OLD server, dry run
   rsync -aHAXx --numeric-ids --info=progress2 --dry-run \
     --exclude-from=/root/mig/excludes \
     -e 'ssh -i /root/.ssh/id_migrate' \
     /var/www/ root@newbox:/var/www/

   Depois o mesmo comando sem --dry-run. Repita para cada diretório que importa: /etc seletivamente em vez de por inteiro, /home, /srv, /opt, e onde quer que a sua aplicação realmente guarde os uploads dela.

   As flags merecem o seu lugar. -a preserva permissões, dono, timestamps e symlinks; -H mantém hard links; -A e -X carregam ACLs e atributos estendidos, que é o que o seu diretório de uploads precisa se algum dia alguém os definiu; -x impede que o rsync vagueie para outros sistemas de arquivos montados. --numeric-ids é o que as pessoas deixam de fora e depois se arrependem: sem ele, o rsync mapeia posse por nome, e se o www-data tem um UID diferente nas duas máquinas, todo arquivo chega pertencendo ao usuário errado, de um jeito tedioso de desfazer.

   Dois avisos. Copiar o /etc por inteiro para um sistema em execução vai sobrescrever a configuração de rede da máquina nova, o seu fstab e as suas chaves de host SSH — copie a configuração específica que você precisa, não o diretório. E guarde o --delete só para a passada final: ele é correto para fazer a máquina nova bater exatamente com a antiga, e destrutivo se você já criou alguma coisa no destino.

   Quando a primeira passada completa terminar, compare os dois lados para saber se ela fez o que você acha que fez:

   du -sh /var/www
   ssh -i /root/.ssh/id_migrate root@newbox 'du -sh /var/www'

6. Mova o banco de dados com um dump, nunca com uma cópia de arquivo

   Este é o passo que decide se a sua migração vai ser monótona ou memorável. O diretório de dados de um banco de dados só é consistente quando o servidor está parado. Copie-o ao vivo e você ganha um conjunto de arquivos que parecem bem, transferem bem, e restauram para um banco de dados sutil e permanentemente corrompido — muitas vezes sem erro nenhum até semanas depois.

   Faça o dump direito. Para MySQL ou MariaDB, o --single-transaction é o que te dá um snapshot consistente sem travar tudo inteiro:

   mysqldump --single-transaction --quick --routines --triggers --events \
     --default-character-set=utf8mb4 --databases appdb \
     | zstd -T0 > /root/mig/appdb.sql.zst

   Para PostgreSQL, o formato custom vale a pena — ele comprime, e permite restaurar seletivamente se você precisar:

   pg_dump -Fc -Z6 appdb > /root/mig/appdb.dump

   Envie para o outro lado e restaure:

   scp -i /root/.ssh/id_migrate /root/mig/appdb.sql.zst root@newbox:/root/
   # on the NEW server
   zstd -dc /root/appdb.sql.zst | mysql
   # postgres equivalent
   pg_restore -d appdb -j4 /root/appdb.dump

   Depois verifique, porque “a restauração terminou” e “os dados estão lá” são afirmações diferentes. Compare a contagem de linhas nas tabelas que importam, dos dois lados:

   mysql -N -e "SELECT COUNT(*) FROM appdb.orders; SELECT COUNT(*) FROM appdb.users;"

   Duas coisas que se escondem em dumps: o conjunto de caracteres e a collation, que é de onde vêm os caracteres acentuados corrompidos — se o banco antigo está em utf8 em vez de utf8mb4, decida deliberadamente se a mudança também é o momento de consertar isso; e os usuários do banco de dados e privilégios, que o mysqldump --databases não inclui. Recrie o usuário e a senha da aplicação na máquina nova explicitamente, e depois lembre-se de que a connection string na sua configuração precisa bater.

   Se a sua aplicação usa SQLite, o arquivo é o banco de dados, e a mesma regra se aplica — não o copie ao vivo. Use sqlite3 app.db ".backup /root/mig/app.db", que faz uma cópia consistente com segurança.

7. Suba a stack e ensaie com o truque do arquivo hosts

   O servidor novo agora tem os arquivos e os dados. Suba tudo e teste sob o hostname real dele — enquanto o resto do mundo ainda está usando a máquina antiga tranquilamente. Este é o truque mais valioso de todo o procedimento, e custa uma linha.

   No seu próprio notebook, adicione o IP do servidor novo ao /etc/hosts (ou C:\Windows\System32\drivers\etc\hosts):

   203.0.113.10   example.com www.example.com

   O seu navegador agora resolve o domínio real para o servidor novo, e o de mais ninguém faz isso. Toda URL está correta, todo domínio de cookie bate, todo redirecionamento e caminho de callback se comporta do jeito que vai se comportar depois do corte — que é precisamente o que testar contra um subdomínio temporário new.example.com não consegue capturar, porque metade do que quebra numa migração depende do hostname.

   Para uma checagem rápida única, sem editar nada, o curl pode fazer a mesma coisa embutido:

   curl -sSI --resolve example.com:443:203.0.113.10 https://example.com/
   curl -sS --resolve example.com:80:203.0.113.10 http://example.com/ -o /dev/null -w '%{http_code}\n'

   Percorra a aplicação inteira, não só a página inicial: faça login, envie um formulário, suba um arquivo, dispare um e-mail de redefinição de senha, carregue uma página de admin, acerte o endpoint que um processador de pagamentos chama. Depois leia os logs de erro mesmo que tudo tenha parecido bem — extensões do PHP faltando, um modo de arquivo errado num diretório de cache e um usuário de banco de dados que ainda não existe, tudo isso aparece lá antes de aparecer na tela.

   Lembre-se de remover a linha do hosts depois. Todo mundo esquece uma vez, e depois passa vinte minutos se perguntando por que o rollback parece não ter funcionado.

8. Deixe o TLS funcionando na máquina nova antes de virar qualquer coisa

   Certificados são vinculados a nomes, não a endereços IP, então nada numa migração invalida um certificado que você já tem. O que quebra é a emissão: o desafio HTTP-01 de sempre pede para o Let's Encrypt buscar um arquivo na porta 80 no nome sendo certificado, e esse nome ainda aponta para o servidor antigo. O ovo e a galinha é toda a dificuldade, e há três saídas limpas.

   Copie os certificados existentes. O mais simples e geralmente o certo. A chave privada e a cadeia se movem como qualquer outro arquivo:

   rsync -aHAX -e 'ssh -i /root/.ssh/id_migrate' \
     /etc/letsencrypt/ root@newbox:/etc/letsencrypt/

   O servidor novo consegue servir TLS válido imediatamente, e a renovação começa a funcionar sozinha assim que o DNS apontar para ele. Confirme que o timer está habilitado lá: systemctl list-timers | grep certbot.

   Use um desafio DNS-01. Prova o controle do domínio através de um registro TXT em vez de uma requisição HTTP, então funciona a partir de um servidor para o qual nada aponta ainda. Ideal se você quer um certificado genuinamente independente na máquina nova antes do corte, e a única opção para um wildcard.

   Emita depois da virada. Válido, mas deixa uma brecha em que o site está no ar no IP novo sem certificado nenhum, o que para qualquer coisa com HSTS não é um aviso que os seus visitantes conseguem clicar para atravessar. Só faz sentido para um domínio novinho em folha que ninguém visitou ainda.

   Qualquer que você escolher, verifique contra o IP novo diretamente antes do corte, usando o mesmo truque do --resolve:

   curl -sSI --resolve example.com:443:203.0.113.10 https://example.com/ | head -1
   echo | openssl s_client -connect 203.0.113.10:443 -servername example.com 2>/dev/null \
     | openssl x509 -noout -subject -dates

   Confira as datas e que o subject cobre todo nome que você serve, www incluído. E se você usa HSTS com um max-age longo, trate o certificado como a única coisa que precisa estar certa antes da virada, não depois dela — esse header é uma promessa que você já fez a todo visitante que retorna.

9. O corte: congele as escritas, delta final, vire o registro

   Dez minutos de trabalho de verdade, e a única parte com um relógio correndo. Faça isso de manhã, no seu próprio fuso horário, num dia em que você não esteja ocupado com outra coisa. Nunca numa sexta-feira.

   Congele. Coloque a aplicação antiga em modo de manutenção ou somente leitura. Pare os workers, os consumidores de fila e os cron jobs — qualquer coisa que escreva sem um navegador atrelado. A partir daqui, nada novo é escrito na máquina antiga, o que é o que torna tudo depois disso seguro:

   # on the OLD server
   systemctl stop app-worker.service
   systemctl stop cron
   touch /var/www/maintenance.flag

   Delta final. Mais um rsync, agora com --delete para que o destino bata exatamente, e mais um dump. Com a primeira passada feita dias atrás, isso move muito pouco e leva segundos:

   rsync -aHAXx --numeric-ids --delete --exclude-from=/root/mig/excludes \
     -e 'ssh -i /root/.ssh/id_migrate' /var/www/ root@newbox:/var/www/
   mysqldump --single-transaction --quick --routines --triggers --events \
     --default-character-set=utf8mb4 --databases appdb | zstd -T0 \
     | ssh -i /root/.ssh/id_migrate root@newbox 'zstd -dc | mysql'

   Verifique. Contagem de linhas dos dois lados, mais uma passada pela aplicação usando o truque do arquivo hosts, e tire a flag de manutenção da máquina nova.

   Vire. Mude o registro A para o IP novo. Mude o registro AAAA também — esta é a forma mais comum de um corte funcionar só pela metade. Confirme a partir de um resolvedor que você não controla:

   dig +short example.com A @1.1.1.1
   dig +short example.com AAAA @1.1.1.1

   Depois observe as duas máquinas. O tráfego deve aparecer na nova dentro de um ou dois minutos e desaparecer da antiga ao longo dos cinco minutos seguintes:

   tail -f /var/log/nginx/access.log        # on both, side by side

   Deixe a aplicação antiga em modo de manutenção em vez de desligá-la. Um retardatário que chegar até ela vê uma página educada em vez de um erro de conexão, e você mantém a máquina disponível para o rollback que você provavelmente não vai precisar.

10. Observe por uma semana, depois desative direito

    A migração não está terminada quando o DNS resolve. Ela está terminada quando um ciclo completo de cobrança e cron passou sem nenhuma surpresa.

    Nas primeiras horas, observe as taxas de erro em vez do uptime — um servidor pode estar perfeitamente no ar e retornando 500 para um terço das requisições:

    journalctl -u nginx -u php8.4-fpm -f
    awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

    Depois percorra uma lista curta, porque essas são as coisas que realmente quebram depois de uma mudança e nenhuma delas se anuncia: cron jobs e timers do systemd rodando na máquina nova (systemctl list-timers contra o inventário que você fez no passo dois); e-mail de saída chegando e não caindo no spam; backups agendados apontando para o servidor novo em vez de ainda arquivar o antigo; qualquer terceiro com o seu endereço IP numa allowlist — um processador de pagamentos, uma API, o firewall de um parceiro; e o job mensal que só se prova no primeiro dia do mês.

    Deixe o servidor antigo rodando, em modo de manutenção, intocado, por pelo menos uma semana. Ele é o seu rollback e a sua cópia de referência, e vale mais do que os poucos dólares que custa. Depois encerre-o em ordem: rotacione todo segredo que ele podia ter lido, faça um último arquivo criptografado para um terceiro local, sobrescreva os diretórios da aplicação e do banco de dados, rode a rotina de destruição ou reinstalação do provedor, e só então cancele — depois de conferir a data de renovação, porque um mês extra de seguro de rollback costuma ser a troca melhor.

    Por último, coloque o TTL de volta em 3600 agora que você não precisa mais de reversibilidade de cinco minutos, e atualize qualquer documentação que você mantenha com o endereço novo. Você do futuro, em alguma 2h da manhã mais adiante, vai ficar extremamente grato que o runbook bate com o servidor.

O e-mail não migra junto com o resto#

Revertendo sem piorar as coisas#

Desativação: rotacione, apague, verifique, depois cancele#

Uma linha do tempo que funciona#

Perguntas frequentes#