Como migrar uma VPS sem downtime com segurança

Resposta direta

Para migrar uma VPS sem downtime, prepare o novo servidor em paralelo, copie os arquivos com sincronização incremental, replique ou congele brevemente as escritas do banco de dados e teste a aplicação antes de alterar o DNS. O corte final deve acontecer somente depois de confirmar versões, permissões, certificados, filas, tarefas agendadas e conectividade. Reduza o TTL do DNS com pelo menos 24 horas de antecedência e mantenha a VPS antiga disponível para rollback. Em sistemas simples, a interrupção pode ficar restrita a poucos segundos durante a última sincronização. Em aplicações com sessões locais, uploads frequentes ou bancos muito ativos, downtime zero exige replicação, armazenamento compartilhado ou balanceamento de tráfego. Sem esses componentes, a meta realista é uma interrupção curta, controlada e reversível.

Resumo rápido

• Faça inventário de serviços, portas, versões, dados persistentes e integrações externas.
• Prepare a nova VPS sem desligar a antiga e aplique hardening antes do corte.
• Use rsync em duas etapas para copiar arquivos e depois apenas as diferenças.
• Migre o banco por replicação quando houver escrita constante ou use uma curta janela de manutenção.
• Reduza o TTL do DNS antes da migração, não minutos antes da troca.
• Teste o destino com arquivo hosts ou curl --resolve antes de receber usuários.
• Mantenha rollback, métricas e logs ativos até confirmar a estabilidade do novo ambiente.

Planeje a migração antes de copiar qualquer arquivo

Uma migração segura começa com um inventário, não com um comando de cópia. Registre sistema operacional, versão do kernel, servidor web, runtime, banco de dados, extensões, portas, certificados, tarefas cron, workers, filas e serviços externos. Uma aplicação PHP pode depender de PHP 8.2, Redis, MariaDB, ImageMagick e um worker executado pelo Supervisor. Copiar apenas /var/www para uma máquina limpa não recria esse conjunto.

Mapeie dependências e dados persistentes

Separe dados que podem ser recriados daqueles que precisam ser preservados. Imagens enviadas por usuários, volumes Docker, bancos, certificados, arquivos .env e chaves de integração exigem tratamento controlado. Cache de aplicação, arquivos temporários e dependências instaláveis geralmente podem ser regenerados. Segredos não devem aparecer em scripts, logs ou repositórios. Transfira arquivos sensíveis por SSH e restrinja suas permissões para 600 quando apropriado.

Use comandos de leitura para montar o inventário. systemctl --type=service --state=running lista serviços ativos, ss -lntup mostra portas em escuta, crontab -l revela tarefas do usuário e docker compose config --services identifica contêineres definidos. Em uma pilha com Docker, examine também volumes com docker volume ls e bind mounts no arquivo Compose. Se a origem veio de hospedagem compartilhada, o processo tem diferenças de acesso e permissões discutidas em migração de hospedagem compartilhada para VPS.

Escolha uma estratégia compatível com a aplicação

O método depende de quanto estado muda durante a cópia. Um site institucional com uploads desativados pode ser migrado com duas passagens de rsync. Uma loja com pedidos em tempo real precisa preservar cada transação, o que favorece replicação de banco ou uma curta pausa nas escritas. Uma API distribuída pode deslocar tráfego gradualmente por balanceador, desde que as duas versões sejam compatíveis com o mesmo banco e o mesmo esquema.

Perfil da aplicação	Arquivos	Banco de dados	Corte recomendado	Interrupção esperada
Site estático	rsync ou artefato de build	Não se aplica	Troca de DNS ou proxy	Próxima de zero
WordPress com pouco tráfego	Duas passagens de rsync	Dump final com modo manutenção	DNS após validação	Segundos a poucos minutos
E-commerce ativo	Uploads sincronizados continuamente	Replicação ou bloqueio controlado	Proxy ou DNS com TTL baixo	Segundos, conforme arquitetura
API crítica	Deploy idêntico nos dois servidores	Replicação e migrações compatíveis	Balanceamento gradual	Próxima de zero com redundância

Defina ainda o objetivo de recuperação. Um RTO de cinco minutos indica quanto tempo a equipe aceita para restaurar o serviço. Um RPO de zero exige que nenhuma gravação confirmada seja perdida. Esses números determinam se um dump é suficiente ou se a migração precisa de replicação contínua.

Prepare a nova VPS para receber a aplicação

A VPS de destino deve estar operacional antes da primeira cópia. Escolha uma distribuição suportada, ajuste hostname, fuso horário e sincronização NTP, crie um usuário administrativo e atualize os pacotes. Para uma aplicação pequena, uma base razoável pode ter 2 vCPUs, 4 GB de RAM e 60 GB de SSD. Se origem usa 45 GB e cresce 3 GB por mês, provisionar apenas 50 GB cria um problema imediato. Reserve espaço para logs, dumps temporários e crescimento, preferencialmente com 25% a 40% de folga.

Reproduza o ambiente sem copiar problemas antigos

Compare versões antes de instalar serviços. php -v, nginx -v, psql --version, mysql --version e docker version ajudam a identificar incompatibilidades. Uma atualização simultânea de sistema operacional, PHP e banco aumenta o número de variáveis. Quando possível, primeiro reproduza a versão funcional e atualize os componentes em uma etapa posterior.

Em servidores Nginx, exporte a configuração efetiva da origem com sudo nginx -T e revise os blocos antes de adaptá-los. Não copie caminhos antigos cegamente. O certificado pode estar em outro diretório, o socket do PHP-FPM pode mudar entre versões e uma regra de proxy pode depender de uma porta local. Para Docker Compose, fixe imagens por versão, como postgres:16.4, em vez de usar apenas latest. Isso torna o ambiente reproduzível e reduz mudanças inesperadas durante o corte.

Teste capacidade com df -h, free -h e nproc. Se a aplicação consumia 2,8 GB de RAM na origem, uma VPS de 2 GB provavelmente entrará em swap durante importações ou picos. Bancos, workers e cache precisam ser somados ao processo web. Em uma configuração de 4 GB, por exemplo, pode-se reservar aproximadamente 1,5 GB para o banco, 1 GB para processos web e o restante para sistema, cache e margem operacional. São referências iniciais, não garantias de desempenho.

Proteja o servidor antes de expô-lo

Configure o firewall para liberar somente portas necessárias, normalmente 22, 80 e 443. Restrinja o SSH por chave, desative login direto de root quando a operação permitir e instale proteção contra tentativas repetidas. Bancos não devem escutar publicamente apenas para facilitar a migração. Use uma rede privada, um túnel SSH ou regras temporárias limitadas ao IP da origem.

Antes do corte, valide atualizações automáticas, rotação de logs e alertas de disco. Um teste simples com sudo nginx -t, systemctl status e uma requisição local para 127.0.0.1 detecta erros sem envolver DNS. Também confirme saída SMTP, APIs externas e allowlists. Quando um gateway de pagamento reconhece somente o IP antigo, a aplicação pode abrir normalmente e falhar justamente na etapa de cobrança.

Sincronize arquivos sem perder alterações recentes

O método mais prático para arquivos em servidores Linux costuma ser o rsync, pois ele preserva metadados e transfere apenas diferenças nas execuções seguintes. A primeira passagem acontece enquanto a aplicação antiga continua atendendo. Para copiar /var/www/app por SSH, um exemplo é rsync -aHAX --numeric-ids --info=progress2 /var/www/app/ usuario@destino:/var/www/app/. As opções de ACL e atributos estendidos só devem ser usadas quando os dois sistemas oferecem suporte compatível.

Faça uma cópia inicial com rsync

Comece com --dry-run para enxergar o que seria transferido. Confira origem e destino das barras finais, pois /app/ copia o conteúdo, enquanto /app pode criar outro nível de diretório. Exclua caches, logs descartáveis e dependências recriáveis, como node_modules, quando o processo de build está documentado. Uma aplicação com 80 GB de uploads e link efetivo de 200 Mbit/s pode exigir perto de uma hora em condições ideais, mas latência, criptografia e muitos arquivos pequenos aumentam esse tempo.

Evite --delete na primeira execução. Essa opção remove no destino arquivos ausentes na origem e pode apagar configurações preparadas manualmente. Se ela for necessária na passagem final, use antes --dry-run e mantenha backup. Valide propriedade com stat, compare o total com du -sh e procure falhas no log do rsync. Quantidades semelhantes em bytes não garantem que permissões e links simbólicos estejam corretos.

Arquivos de configuração merecem uma estratégia separada. O código pode vir de Git ou de um artefato de CI, enquanto uploads seguem por rsync. O .env deve ser criado no destino com valores apropriados, sem exposição no histórico do shell. Endereços internos, credenciais de banco, URLs de callback e nomes de filas podem mudar entre servidores.

Execute a sincronização incremental

Pouco antes do corte, faça uma segunda passagem. Como a maior parte dos arquivos já existe, apenas alterações recentes serão enviadas. Em um WordPress, mantenha uploads sincronizados e coloque o painel em manutenção por alguns segundos na etapa final. Em uma API que recebe documentos, direcione temporariamente novos uploads para armazenamento de objetos ou suspenda apenas o endpoint de gravação, mantendo consultas disponíveis.

Volumes Docker exigem cuidado extra. Não copie os arquivos internos de um banco em execução com rsync, pois páginas podem mudar durante a transferência e produzir uma cópia inconsistente. Use ferramentas nativas do banco, replicação ou backup coordenado. Para volumes de uploads, pare somente o contêiner que escreve nesses dados durante a passagem final, se a arquitetura não oferecer armazenamento compartilhado.

Ao terminar, compare amostras com sha256sum, teste leitura pelo usuário do servidor web e confirme contextos de segurança quando SELinux estiver ativo. Três verificações simples, abrir uma imagem, gerar um upload e executar um build, encontram problemas que a contagem de arquivos não mostra.

Migre o banco de dados com consistência

O banco é a parte mais sensível porque continua mudando enquanto usuários fazem pedidos, publicam conteúdo ou atualizam cadastros. Copiar o diretório de dados de um processo ativo não é uma migração segura. O método deve usar mecanismos compatíveis com o banco, como dump lógico, backup físico coordenado ou replicação. A escolha depende do volume, da taxa de escrita e do RPO definido no planejamento.

Escolha entre replicação e janela de escrita

Para bancos pequenos, um dump final durante uma breve pausa nas gravações costuma ser suficiente. Em PostgreSQL, pg_dump gera uma cópia lógica consistente de um banco, e o formato customizado permite restauração com pg_restore. Em MySQL ou MariaDB, mysqldump --single-transaction reduz bloqueios para tabelas transacionais, mas não transforma tabelas não transacionais em consistentes. As credenciais devem ser fornecidas por mecanismos seguros do cliente, nunca escritas diretamente em scripts compartilhados.

Considere um banco de 8 GB que leva quatro minutos para exportar e seis para importar. Se a aplicação ficar somente leitura durante todo o processo, a janela de escrita será próxima de dez minutos, além da validação. Para reduzir esse intervalo, faça a carga inicial antes e use replicação para aplicar alterações posteriores. PostgreSQL oferece streaming replication e replicação lógica. MySQL possui replicação baseada em log binário. A configuração exige versões compatíveis, conectividade restrita, monitoramento de atraso e entendimento do ponto exato de promoção.

A sequência de corte com replicação costuma ser objetiva: interromper novas escritas, esperar o atraso chegar a zero, confirmar a posição do log, promover ou apontar a aplicação para o destino e executar testes de gravação. Não permita que os dois bancos aceitem escritas independentes sem um desenho multimestre adequado. Essa condição cria divergências difíceis de reconciliar.

Confirme usuários, extensões e sequências

O conteúdo das tabelas é apenas parte do ambiente. Migre roles, permissões, extensões, collations, eventos agendados e funções armazenadas. Em PostgreSQL, compare extensões com \dx e revise sequências depois da restauração. Uma sequência abaixo do maior identificador pode causar colisão no próximo INSERT. Em MySQL, confirme triggers, procedures e eventos, pois algumas opções de dump podem não incluí-los da forma esperada.

Execute testes que escrevam e leiam dados reais de validação. Crie um registro descartável, atualize-o e remova-o. Em uma loja, simule carrinho e pedido em ambiente controlado. Em um SaaS, crie um tenant temporário e rode uma tarefa assíncrona. Compare contagens de tabelas críticas e procure erros de encoding, fuso horário ou precisão decimal.

Se a aplicação usa Redis para sessões, decidir ignorá-lo pode desconectar todos os usuários. Isso talvez seja aceitável em um blog, mas não em um checkout. Migre sessões, use um Redis externo compartilhado ou aceite explicitamente a reautenticação. Filas também precisam ser drenadas ou compartilhadas para evitar tarefas duplicadas e mensagens abandonadas.

Troque DNS e tráfego com interrupção mínima

DNS não move arquivos nem garante que todos os usuários troquem de servidor ao mesmo tempo. Ele apenas publica o novo endereço, sujeito a caches recursivos e locais. Reduza o TTL do registro A ou AAAA com antecedência, idealmente pelo menos 24 horas antes. Se o TTL atual é 86.400 segundos, alterá-lo para 300 segundos cinco minutos antes do corte não invalida respostas que já foram armazenadas por um dia.

Reduza o TTL com antecedência

Um TTL de 300 segundos costuma ser útil durante a transição, mas não elimina caches fora do padrão. Mantenha a VPS antiga respondendo após a mudança, de preferência por 24 a 48 horas, conforme o tráfego observado e o TTL anterior. Não encerre o servidor assim que o painel DNS mostrar o novo IP. Consulte diferentes resolvedores e acompanhe acessos no log da origem.

Antes do corte, confira todos os registros relacionados. O domínio principal pode usar A, enquanto www é um CNAME e a API aponta para outro endereço. Registros IPv6 esquecidos fazem parte dos clientes chegar à infraestrutura antiga. MX, SPF e DKIM normalmente não precisam mudar quando o serviço de e-mail permanece externo, mas aplicações que enviam mensagens pelo IP da VPS podem exigir atualização de SPF e DNS reverso.

Teste o destino antes do corte

Use o arquivo hosts em uma estação de teste ou execute curl --resolve exemplo.com:443:203.0.113.20 https://exemplo.com/. Assim, a requisição chega ao novo IP com hostname e SNI corretos, sem alterar o DNS público. Teste página inicial, login, upload, envio de formulário, checkout, webhooks e rotas de API. Verifique o certificado com o nome real do domínio, não apenas pelo IP.

Se houver um proxy reverso ou balanceador, o tráfego pode ser deslocado gradualmente. Comece com uma pequena parcela, observe erros e aumente. Isso depende de sessões compartilhadas, banco compatível e versão da aplicação capaz de operar nos dois servidores. O artigo sobre VPS para alta disponibilidade e failover aprofunda arquiteturas em que a troca não depende apenas de DNS.

Durante a convivência, evite que a origem e o destino gravem uploads localmente em diretórios separados. Use armazenamento compartilhado, sincronização contínua ou direcione todas as escritas a um único nó. Também preserve o IP real do cliente no proxy e atualize listas de proxies confiáveis. Sem isso, logs, limites de requisição e mecanismos antifraude podem registrar somente o endereço do balanceador.

Depois que a troca estiver estável, retorne o TTL a um valor operacional, como 3.600 ou 14.400 segundos, conforme a estratégia do serviço. TTL permanentemente baixo aumenta consultas e não substitui failover automatizado.

Valide a migração e mantenha um rollback viável

Uma resposta HTTP 200 não comprova que a migração terminou. Validação precisa cobrir aplicação, banco, filas, integrações e comportamento sob carga. Observe taxa de erros, latência, uso de CPU, memória, disco, conexões e espaço livre. Compare esses indicadores com a origem. Se a API respondia em 180 ms e passa a levar 900 ms, investigue consultas, DNS interno, cache e distância do banco antes de declarar sucesso.

Monitore a aplicação durante o corte

Acompanhe logs em tempo real com journalctl -f, logs do servidor web e a ferramenta de observabilidade usada pela equipe. Procure erros 500, timeouts, falhas de conexão e permissões negadas. Execute testes sintéticos a cada minuto para login, leitura e escrita. Em um WordPress, publique um rascunho e envie uma imagem. Em uma API, crie um recurso temporário e processe uma tarefa na fila. Em um e-commerce, simule o fluxo de pedido sem concluir uma cobrança real.

Verifique ainda cron e workers. A cópia pode deixar o agendador ativo nas duas VPS, executando cobranças, e-mails ou relatórios em duplicidade. Durante a transição, escolha um único servidor para tarefas programadas. Faça o mesmo com consumidores de filas que não toleram processamento concorrente. Depois do corte, confirme que os serviços iniciam automaticamente após reboot.

Snapshots podem acelerar a recuperação de uma alteração ruim, mas não substituem backup independente. Eles normalmente pertencem ao mesmo ambiente administrativo e podem capturar dados em estado inconsistente se a aplicação não for coordenada. A análise sobre snapshots para recuperação rápida em VPS explica onde esse recurso ajuda e onde ele não cobre riscos de exclusão ou falha do provedor.

Defina critérios objetivos para voltar

O rollback precisa ter gatilhos claros. Exemplos incluem taxa de erro acima de 2% por dez minutos, perda de gravações, fila crescendo continuamente ou latência três vezes maior que a linha de base. Sem critérios, a equipe pode insistir em corrigir o destino enquanto usuários enfrentam falhas.

Para voltar, reverta o roteamento e confirme onde ocorreram novas escritas. Se o novo banco já recebeu pedidos, simplesmente apontar para o banco antigo perde dados. Esse é o ponto mais difícil do rollback. Uma estratégia segura mantém replicação reversa, suspende escritas antes da volta ou possui procedimento para reconciliar registros. Preserve a origem intacta, mas bloqueie alterações administrativas acidentais nela.

Desative a VPS antiga somente depois de verificar propagação DNS, backups, métricas e integridade por um período definido. Remova chaves temporárias, regras de firewall e usuários criados para a transferência. Por fim, documente duração, incidentes e comandos usados. Esse registro reduz risco na próxima migração.

Recomendações por perfil

A estratégia deve acompanhar a criticidade do serviço. Nem todo projeto precisa de balanceador, replicação contínua e duas regiões. Também não faz sentido tratar uma loja ativa como um site estático. A melhor decisão combina orçamento, volume de escrita, capacidade da equipe e impacto de alguns minutos sem alterações.

Desenvolvedor solo

Para um blog, portfólio ou aplicação pequena, prepare a VPS nova, faça um primeiro rsync, importe uma cópia do banco e teste pelo arquivo hosts. No corte, ative modo somente leitura, execute o dump final, rode o segundo rsync, importe o banco e altere o DNS. Uma configuração de 2 vCPUs, 4 GB de RAM e 60 GB de SSD costuma ser um ponto inicial razoável para pilhas leves, desde que o consumo real seja medido. Mantenha a origem por pelo menos 24 horas e salve um backup externo. O objetivo não é montar uma arquitetura complexa, mas reduzir uma parada que poderia durar horas para uma janela previsível de poucos minutos.

Equipe de produto

Uma equipe que opera SaaS, WordPress movimentado ou e-commerce deve automatizar a preparação com Ansible, Terraform ou imagens versionadas. Sincronize uploads continuamente, replique o banco e use um ambiente de homologação baseado no destino. Antes do corte, teste login, pagamentos, webhooks, filas e tarefas agendadas. Defina responsáveis para DNS, banco, aplicação e comunicação, mesmo que uma pessoa acumule funções. Use métricas de erro e latência como critérios de aprovação. A VPS antiga permanece disponível para rollback, mas sem executar cron duplicado. Se o sistema recebe 50 gravações por minuto, um dump com dez minutos de duração pode deixar centenas de alterações fora da cópia, o que justifica replicação ou bloqueio de escrita.

Produção crítica

Serviços com receita direta, acordos de disponibilidade ou operações 24 horas precisam tratar a migração como mudança de produção. Mantenha dois nós funcionais, banco replicado, sessões externas e armazenamento compartilhado ou de objetos. Direcione tráfego por balanceador em etapas, como 5%, 25%, 50% e 100%, observando cada fase. Migrações de esquema devem ser compatíveis com a versão antiga e a nova, usando expansão antes da remoção de colunas. Defina RTO, RPO, ponto de retorno e autoridade para abortar. Faça um ensaio com cópia mascarada dos dados e registre tempos reais. Downtime próximo de zero surge dessa redundância e coordenação, não apenas da troca rápida de DNS.