Como migrar VPS de outro provedor pra Hostini sem downtime
Guia técnico pra migrar VPS de Vultr, DigitalOcean ou Contabo pra Hostini com rsync, DNS TTL baixo e cutover sem janela de indisponibilidade.
Migrar uma VPS entre provedores parece arriscado quando você tem aplicação em produção, mas a operação é determinística quando segue um runbook. O risco real não está nos comandos — está em pular validações ou subestimar o TTL do DNS. Este tutorial cobre o processo completo pra mover sua VPS de Vultr, DigitalOcean, Contabo ou similares pra Hostini, com janela de downtime medida em segundos.
A abordagem usa rsync incremental pra sincronizar arquivos enquanto a aplicação antiga continua servindo tráfego, reduz o TTL do DNS pra acelerar a propagação no cutover, e valida tudo via /etc/hosts local antes de tornar a mudança pública. Persona-alvo: você tem uma VPS rodando Linux (Ubuntu/Debian/Rocky) com aplicação web, banco de dados, e talvez um stack tipo Nginx + PHP-FPM, Node.js ou Docker.
Tempo estimado: 2-4 horas, sendo 30-45 minutos de execução ativa e o resto esperando rsync e propagação de DNS. A janela de indisponibilidade percebida pelo usuário final fica tipicamente abaixo de 2 minutos.
Pré-requisitos
Acesso SSH com sudo na VPS de origem (provedor atual) e na VPS Hostini de destino. Painel de controle do seu DNS (Cloudflare, Registro.br, etc) pra ajustar TTL e registros A. Lista do que está rodando: serviços systemd, portas abertas, paths de dados (web root, banco, configs).
Antes de tocar em qualquer servidor, documente o estado atual. Rode systemctl list-units --type=service --state=running na origem e salve. Anote versões: nginx -v, php -v, mysql --version, node -v. Liste cron jobs com crontab -l e ls /etc/cron.d/. Esse inventário é o que você vai replicar.
60s 24h antes 30s-2min rsync incremental Provisione a VPS de destino na Hostini
A VPS nova deve espelhar o sistema operacional da origem na mesma versão maior. Se a origem roda Ubuntu 22.04, escolha Ubuntu 22.04 — pular versão de SO no meio da migração adiciona variáveis de incompatibilidade (libs, paths de config) que você não precisa carregar.
No painel da Hostini, contrate a VPS com specs iguais ou superiores à origem. Mesma família de SO (Ubuntu/Debian/Rocky) e mesma versão LTS. Anote o IP público novo.
ssh root@IP_NOVO_HOSTINIConfirme conectividade e troque pra um usuário não-root pra trabalho subsequente.
Instale na nova VPS exatamente os mesmos pacotes da origem. Numa Ubuntu/Debian, use a lista que você documentou:
sudo apt update
sudo apt install -y nginx mysql-server php8.3-fpm php8.3-cli redis-serverPra Rocky/AlmaLinux, ajuste pra dnf install. Garanta versão exata do PHP, Node, ou qualquer runtime crítico — uma diferença de minor version pode quebrar dependências da aplicação.
Configure o firewall com as mesmas portas da origem. Se você usa UFW:
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enableNão esqueça de portas custom (ex: 8080 pra um app, 6379 pra Redis exposto). Comparar com ss -tlnp na origem é a fonte da verdade.
Reduza o TTL do DNS
Esse passo deve ser feito 24 horas antes do cutover. O TTL atual do seu registro A determina quanto tempo resolvers de DNS pelo mundo vão cachear o IP antigo após você apontar pro IP novo. TTL padrão de 3600s (1 hora) ou 86400s (1 dia) significa downtime medido em horas pra parte dos visitantes.
No seu provedor de DNS (Cloudflare, Registro.br, Route53, etc), edite os registros A e AAAA do domínio. Mude o TTL pra 60 segundos.
Se você usa Cloudflare com proxy laranja ativo, o TTL é controlado pelo Cloudflare (não pelo seu valor) — mas mesmo assim ajuste pra “Auto” e desabilite o proxy temporariamente no dia do cutover pra ver propagação real.
Reduzir TTL não tem efeito imediato — os resolvers só vão pegar o valor novo após o TTL antigo expirar. Se o registro tinha TTL 3600s, espere pelo menos 1 hora. Pra TTL antigo de 86400s, espere 24h pra garantir.
Sincronize dados com rsync
rsync com aplicação rodando é seguro pra arquivos estáticos (web root, uploads, configs), mas exige cuidado com bancos de dados — sincronize arquivos de banco com mysqldump/pg_dump, não com cópia direta dos arquivos de tabela.
Da VPS de origem, transfira o web root e configs do nginx pra Hostini:
rsync -avz --progress \
/var/www/ \
root@IP_NOVO_HOSTINI:/var/www/
rsync -avz --progress \
/etc/nginx/ \
root@IP_NOVO_HOSTINI:/etc/nginx/A flag -a preserva permissões, owners e timestamps. -v mostra progresso. -z comprime durante transferência — útil pra arquivos texto, neutro pra binários já comprimidos.
Pra banco MySQL/MariaDB, use dump + restore (nunca copie /var/lib/mysql diretamente entre servidores diferentes):
mysqldump --single-transaction --routines --triggers \
--all-databases > /tmp/backup.sql
rsync -avz /tmp/backup.sql root@IP_NOVO_HOSTINI:/tmp/Na VPS nova:
ssh root@IP_NOVO_HOSTINI
mysql < /tmp/backup.sqlA flag --single-transaction evita lock de tabelas durante o dump em engines transacionais (InnoDB), permitindo a aplicação continuar respondendo.
Copie certificados TLS do Let’s Encrypt mantendo permissões originais:
rsync -avz --progress \
/etc/letsencrypt/ \
root@IP_NOVO_HOSTINI:/etc/letsencrypt/Os certificados continuam válidos no IP novo porque são vinculados ao domínio, não ao IP. Após cutover, instale certbot na Hostini e o cron de renovação assume normalmente.
Habilite e inicie os serviços na VPS nova com a configuração migrada:
sudo systemctl enable --now nginx php8.3-fpm mysql
sudo systemctl status nginxVerifique logs de cada serviço com journalctl -u nginx --since "5 min ago" pra confirmar que nada explodiu no boot.
Valide antes do cutover
Esse é o passo que separa migração tranquila de migração caótica. Você vai testar a VPS nova como se ela já fosse produção, sem mexer no DNS público — só no seu /etc/hosts local.
No seu computador (não no servidor), edite /etc/hosts adicionando uma linha que aponta seu domínio pro IP novo:
sudo nano /etc/hostsAdicione no final:
IP_NOVO_HOSTINI seudominio.com.br www.seudominio.com.brAgora seu navegador vai resolver seudominio.com.br pro IP novo só pra você. Abra o site num navegador anônimo, teste login, navegação, formulários. Se algo quebrar, você ainda tem a produção antiga rodando intacta.
Teste em Chrome, Firefox e Safari. Cada um cacheia DNS de forma diferente. Em mobile, configure o /etc/hosts via apps tipo “Hosts Editor” no Android ou conexão SSH local pra validar a UX real.
Cutover: aponte o DNS pro novo IP
Esse é o momento de transição. Antes do switch, rode um rsync final pra capturar mudanças desde a última sincronização. Idealmente, coloque a aplicação em modo manutenção por 30-60 segundos durante esse rsync final pra garantir consistência.
Rsync incremental final dos arquivos que podem ter mudado:
rsync -avz --delete --progress \
/var/www/ \
root@IP_NOVO_HOSTINI:/var/www/A flag --delete remove arquivos no destino que não existem mais na origem — útil se você apagou caches ou logs.
Dump final do banco com aplicação em manutenção:
mysqldump --single-transaction --routines --triggers \
--all-databases > /tmp/final.sql
rsync -avz /tmp/final.sql root@IP_NOVO_HOSTINI:/tmp/
ssh root@IP_NOVO_HOSTINI "mysql < /tmp/final.sql"No painel de DNS, mude o registro A do domínio pra apontar pro IP da Hostini. Salve. Remova a linha do /etc/hosts local que você adicionou pra teste — agora você quer ver propagação real.
Acompanhe a propagação:
dig +short seudominio.com.br @8.8.8.8
dig +short seudominio.com.br @1.1.1.1Quando os dois retornarem o IP novo, a maioria dos visitantes já está chegando na VPS Hostini.
Verificação pós-cutover
Confirme que tudo está respondendo na infraestrutura nova e nada continua dependendo do servidor antigo.
curl -I https://seudominio.com.brA resposta deve incluir Server: nginx (ou o que você configurou) e o IP do TCP socket deve ser o da Hostini. Verifique com curl -v pra ver o handshake TLS e confirmar que o certificado tá correto.
Monitore logs por algumas horas:
sudo tail -f /var/log/nginx/access.logTráfego entrando = cutover funcionou. Se logs continuam vazios após 30 minutos, a propagação de DNS pode estar lenta — alguns ISPs ignoram TTL.
Resolução de problemas
Certificado TLS dá erro após migração
Verifique se o caminho do certificado no nginx ainda aponta pra /etc/letsencrypt/live/seudominio.com.br/. Se você renomeou diretórios durante a migração, ajuste ssl_certificate e ssl_certificate_key no config. Teste com sudo nginx -t antes de recarregar.
Aplicação não conecta no banco
Confirme que o usuário do banco existe na VPS nova com as mesmas senhas. mysqldump exporta dados mas não importa usuários do mysql.user por padrão — adicione --all-databases (já incluído nos comandos acima) ou faça dump separado de mysql.user. Verifique /etc/mysql/my.cnf pra garantir que bind-address está correto.
Tráfego continua chegando na VPS antiga
Resolvers que ignoram TTL podem cachear por horas. Mantenha a VPS antiga ligada por 48-72 horas pós-cutover como rede de segurança. Configure ela pra fazer 301 redirect pro IP novo via Nginx — assim mesmo visitantes em cache antigo chegam onde precisam.
Próximos passos
Com a migração concluída, foque em consolidar a operação na nova infraestrutura:
- Configure backups automáticos da VPS nova — snapshots agendados protegem contra erros operacionais
- Atualize monitoramento (UptimeRobot, Better Stack) pra apontar pros novos endpoints
- Documente o runbook executado pra próxima migração — ele evolui com cada execução
- Após 7 dias estáveis na Hostini, cancele a VPS antiga e remova os redirects de segurança
- Restaure o TTL do DNS pra um valor padrão (3600s ou 86400s) — manter 60s permanentemente aumenta carga nos resolvers
Se você está colocando carga de produção em VPS, uma VPS Hostini oferece SSD NVMe, IPv6 nativo e rede com proteção contra ataques volumétricos — vale rodar benchmarks comparativos durante a janela de paralelismo dos dois servidores pra confirmar ganho real de performance.
Perguntas frequentes
Quanto tempo de downtime é esperado numa migração bem-feita?
Com TTL de DNS reduzido pra 60 segundos 24h antes do cutover e os serviços já replicados, o downtime real fica entre 30 segundos e 2 minutos. A maior parte é a propagação de DNS pros resolvers que respeitaram o TTL — alguns ISPs ignoram e cacheiam por mais tempo, mas a janela vista pela maioria dos usuários é curta.
rsync ou snapshot completo? Qual o método mais seguro?
rsync é mais seguro pra migração entre provedores diferentes porque você sincroniza arquivos no mesmo sistema operacional, sem importar imagens de disco incompatíveis. Snapshot/imagem só funciona bem quando os dois lados usam o mesmo formato (raw/qcow2) e versão de kernel compatível. Pra Vultr → Hostini ou DigitalOcean → Hostini, rsync ganha.
Preciso parar a aplicação durante o rsync inicial?
Não. O primeiro rsync copia o estado atual com a aplicação rodando — pode pegar arquivos inconsistentes (banco de dados, sessões), mas é só pra mover o volume de bytes. Você faz rsyncs incrementais subsequentes que reconciliam diferenças, e o último (com aplicação parada por 30-60s) garante consistência final.
Como evitar que o IP novo seja bloqueado por reputação ruim?
IPs de VPS recém-criados às vezes herdam reputação do dono anterior. Antes do cutover, teste em ferramentas como MXToolbox e Spamhaus. Se o IP estiver em blacklist, abra ticket pedindo troca antes de migrar — leva minutos e evita problemas de entrega de email pós-migração.
Posso testar a nova VPS sem mexer no DNS?
Sim. Adicione uma linha no seu /etc/hosts local apontando o domínio pro IP novo da Hostini. Seu navegador vai resolver pra esse IP só pra você, enquanto o resto do mundo continua acessando o servidor antigo. Permite validar TLS, aplicação e banco antes de fazer o switch público.
Como lido com certificados Let's Encrypt na transição?
Copie /etc/letsencrypt/ inteiro via rsync — inclui chaves privadas e certificados ativos. Eles continuam válidos até a data de expiração e podem ser usados nos dois servidores em paralelo. Após o cutover, instale o certbot na VPS nova e deixe a renovação automática assumir o ciclo.