Da VPS para o dedicado: quando e como fazer a troca

Os sinais de que chegou a hora#

Quase ninguém migra por vontade de trocar de hardware. Migra porque alguma coisa começou a doer com regularidade. O problema é que os sintomas de VPS no limite se parecem muito com os sintomas de aplicação mal otimizada, e trocar de máquina sem esse diagnóstico significa pagar mais caro para sentir a mesma dor alguns meses depois.

Quatro sinais apontam para limite de infraestrutura e não de código. Eles têm peso diferente e nenhum decide sozinho.

• Steal time consistente. A sua máquina virtual pediu processador e não recebeu, porque o host estava atendendo outra carga. Isso não é algo que você conserta de dentro da VPS. É o sinal mais direto de disputa de recurso.
• Pico batendo no teto de vCPU. Uso próximo do máximo por períodos longos, não por segundos. Quando o gráfico fica achatado no topo durante a hora de maior movimento, a máquina virou o limite.
• Io wait alto. Processos parados esperando disco durante backup, importação de dados ou reconstrução de índice. Aparece como lentidão geral inexplicável, com processador ocioso.
• Soma das mensalidades. O sinal menos técnico e às vezes o mais decisivo. Quando você mantém seis, sete ou oito instâncias e a conta total já passou do valor de um dedicado, o custo de administrar todas elas é pura perda.

Confirmar o diagnóstico com números#

Impressão não serve para decidir um gasto mensal na faixa de um dedicado. Colete dados por pelo menos duas semanas, cobrindo os dias de maior movimento, e olhe para as métricas abaixo. O guia de monitorar recursos da VPS com htop e netdata cobre as ferramentas.

Duas semanas de coleta não é exagero. Um servidor de jogo tem comportamento diferente entre semana e fim de semana, e uma loja virtual tem dias de campanha. Se você olhar apenas uma terça-feira tranquila, vai concluir que está tudo bem. Se olhar apenas o sábado de um evento, vai concluir que precisa do maior dedicado disponível. O que interessa é o padrão repetido, e ele só aparece com histórico.

Inventário do que roda hoje#

Esta é a etapa que mais economiza tempo depois e a que mais gente pula. O objetivo é escrever, em um documento único, tudo que existe no ambiente atual. Migração dá errado quase sempre por causa de algo que ninguém lembrava que estava ali: um script agendado, uma regra de firewall antiga, um certificado emitido manualmente, uma integração que só funciona a partir daquele endereço IP.

• Lista de todos os serviços em execução e a porta de cada um.
• Versões exatas de sistema, banco de dados, runtime da aplicação e bibliotecas críticas.
• Tarefas agendadas, incluindo as que rodam uma vez por mês.
• Regras de firewall e listas de endereços liberados.
• Certificados em uso, com data de validade e método de renovação.
• Integrações externas que dependem do endereço IP atual.
• Licenças atreladas a hardware ou a endereço IP.
• Volume real de dados a mover, medido e não estimado.
• Usuários, chaves de acesso e quem tem credencial de cada serviço.
• Todos os registros de DNS que apontam para o servidor atual.

Preste atenção especial ao endereço IP. Gateways de pagamento, servidores de correio e APIs de parceiros costumam liberar acesso por endereço. Cada um desses precisa de solicitação de atualização antecipada, e alguns levam dias úteis para processar. Descobrir isso na noite do corte é o cenário clássico de migração que vira madrugada.

Preparar o dedicado em paralelo#

A regra de ouro é que o dedicado precisa estar inteiro, funcionando e testado antes de receber o primeiro usuário real. Você paga os dois ambientes por alguns dias, e esse custo é barato perto do preço de uma migração malfeita. Com a máquina dedicada ativa, reconstrua o ambiente na ordem abaixo.

1. Instale o sistema operacional na mesma versão principal que roda hoje na VPS. Mudar de distribuição e de máquina ao mesmo tempo dobra as variáveis de um problema futuro.
2. Aplique o endurecimento de segurança antes de qualquer serviço: chave SSH, firewall, usuário sem privilégio administrativo e bloqueio de acesso direto pelo usuário root.
3. Suba os serviços nas versões exatas do inventário e confira cada arquivo de configuração comparando com o original, não de memória.
4. Restaure uma cópia recente dos dados e valide a integridade. Este é o primeiro teste real da sua rotina de backup.
5. Teste a aplicação inteira pelo endereço IP do dedicado, editando o arquivo de hosts da sua máquina para simular o domínio já apontado.
6. Configure o monitoramento apontando para o novo servidor antes da virada, para ter linha de base de comparação.

Aproveite que a máquina é inteira para reorganizar o que estava espalhado. Se hoje você tem banco de dados em uma VPS e aplicação em outra, no dedicado os dois passam a conversar pela rede local da própria máquina, o que elimina uma viagem de rede em cada consulta.

Mover dados e baixar o TTL#

A cópia de dados acontece em duas etapas. A primeira é a carga completa, feita com calma dias antes, sem pressa e sem parar nada. A segunda é a sincronização incremental na hora do corte, que move só o que mudou desde a primeira carga. Essa divisão é o que transforma uma janela de horas em uma janela de minutos.

Baixe o TTL dos registros de DNS que vão mudar para um valor curto pelo menos 48 horas antes da virada. O TTL diz aos resolvedores do mundo inteiro por quanto tempo eles podem guardar a resposta antiga em cache. Se ele estiver em 24 horas no momento do corte, parte dos seus usuários continuará chegando no servidor velho durante um dia inteiro, gravando dados em um lugar que você já considerou aposentado.

O procedimento genérico de virada de provedor, com mais detalhe sobre a parte de DNS e propagação, está em como migrar um servidor sem downtime. Aquele guia trata de trocar de casa mantendo o mesmo tipo de hospedagem. Este aqui trata do que muda quando o destino é uma máquina física inteira, que é onde entram licenças atreladas a hardware, consolidação de serviços que antes estavam separados e o dimensionamento diferente de disco e memória.

A janela de corte#

Escolha o horário de menor movimento real do seu público, medido no seu próprio monitoramento, e não o horário que parece calmo. Avise os usuários com antecedência, com data e duração estimada. Tenha a equipe disponível durante e depois, porque o momento crítico não é o corte, é a hora seguinte.

1. Congele mudanças na aplicação antiga. Nada de implantação nova nas horas anteriores.
2. Coloque a aplicação antiga em modo de manutenção ou somente leitura.
3. Rode a sincronização incremental final dos dados e confira a contagem de registros nos dois lados.
4. Suba a aplicação no dedicado e teste pelo endereço IP, ainda sem mexer no DNS.
5. Altere os registros de DNS para o novo endereço.
6. Acompanhe o log do servidor novo e o do antigo em paralelo até o tráfego migrar por completo.

Uma coisa que ajuda muito é escrever essa sequência como roteiro, com o comando exato de cada passo, e ensaiar em um ambiente de teste antes. Durante o corte ninguém deveria estar pensando em qual é a próxima etapa, e sim executando uma lista já conhecida. Se duas pessoas participam, defina antes quem executa e quem confere, porque improvisar a divisão de tarefas no meio da janela é como boa parte dos erros acontece.

Validação e plano de volta#

Validação não é abrir a página inicial e ver que carregou. É percorrer os caminhos que geram valor e os que geram receita, um por um, na primeira hora depois do corte.

• Login, cadastro e recuperação de senha funcionando ponta a ponta.
• Fluxo de pagamento testado com uma transação real de valor baixo.
• Envio de e-mail transacional chegando na caixa de entrada, não no spam.
• Tarefas agendadas executando no horário previsto do novo servidor.
• Certificado válido em todos os domínios e subdomínios.
• Integrações externas respondendo a partir do novo endereço IP.
• Monitoramento externo confirmando disponibilidade pelo novo endereço.
• Backup do dedicado já rodando e com primeira cópia concluída.
• Tempo de resposta comparado com a linha de base da VPS antiga.

O plano de volta precisa existir por escrito antes do corte, não ser improvisado no meio dele. Ele tem três condições: a VPS antiga continua ligada e intocada, o TTL continua baixo, e existe um ponto definido de não retorno, que é o momento em que dados novos já foram gravados só no dedicado. Antes desse ponto, voltar é reverter o DNS e esperar. Depois dele, voltar exige trazer os dados novos de volta, o que é bem mais trabalhoso.

Deixe claro para a equipe quem decide a reversão e com base em qual critério. Uma regra simples funciona melhor que julgamento no calor do momento: se o serviço principal não estiver estável em um prazo definido, reverte, investiga com calma e remarca. Uma segunda janela custa menos que uma madrugada inteira tentando consertar no escuro.

Depois de duas ou três semanas estáveis, desligue a VPS antiga, guarde uma cópia final do estado dela e atualize a documentação do ambiente. Se a conclusão do seu diagnóstico tiver sido que a VPS ainda dá conta, continuar na VPS Ryzen e revisar a capacidade no trimestre seguinte é uma decisão igualmente válida. O guia de quando usar servidor dedicado ajuda a rever esse ponto.