Como Migrar um VPS para um Novo Host sem Indisponibilidade

A maioria das migrações não falha durante a cópia. Elas falham nos vinte minutos depois da mudança de DNS, quando metade da internet ainda está falando com o servidor antigo e a outra metade já seguiu em frente — e as duas máquinas estão aceitando escritas. Os arquivos chegaram intactos, o site carrega, e ainda assim os pedidos estão caindo em dois bancos de dados que nunca serão reconciliados. Evitar isso tem quase nada a ver com velocidade de transferência e quase tudo a ver com sequência: o que você muda primeiro, o que você congela, e o que você mantém rodando até ter certeza.

O que "sem indisponibilidade" realmente significa

Vale a pena ser preciso, porque a frase cobre duas promessas bem diferentes, e elas custam quantidades de esforço bem diferentes. Decidir qual delas você está comprando é a primeira decisão de verdade da migração.

Se você precisar sacrificar um dos dois, sacrifique a disponibilidade. Uma página de manutenção por quatro minutos é algo que dá para explicar. Dados divergentes são algo que você não consegue consertar, porque não sobra nenhuma autoridade para dizer qual cópia estava certa.

Faça o inventário antes de fazer a cópia

Um servidor acumula coisas que ninguém documentou: uma tarefa de cron adicionada durante um incidente, uma regra de firewall para o endereço de um parceiro, uma chave de API colada dentro de um arquivo de serviço. A cópia não vai carregar essas coisas, e você vai encontrá-las uma de cada vez ao longo da quinzena seguinte. Meia hora de inventário agora elimina quase tudo isso.

Escreva isso em um arquivo que você mantém em controle de versão, não no histórico de rolagem do terminal. Você vai ler esse arquivo três vezes durante a virada, uma delas em um momento em que não está pensando com clareza.

Escolha o destino com base no que você não consegue mudar depois

Especificações são ajustáveis; algumas poucas propriedades não são, e essas valem a pena ser decididas deliberadamente enquanto você ainda tem escolha livre. Já que você vai migrar de qualquer forma, esse é o momento mais barato que você jamais vai ter para corrigir uma restrição com a qual você vinha convivendo.

• Localização, porque tanto a latência até os seus usuários quanto a lei aplicável são fixadas por ela. /locations lista as regiões e as características de ida e volta de cada uma; escolha uma que falhe de forma independente de onde quer que você esteja saindo.
• Base legal, se o motivo da mudança for que o seu provedor atual encaminha reclamações mais rápido do que encaminha pacotes. /offshore-hosting explica o que a jurisdição realmente controla e o que ela não controla.
• Identidade de cobrança, porque um host que exige documentos antes de aceitar o pagamento já tem, por construção, um arquivo sobre você. /no-kyc-vps e /pay-with descrevem a alternativa — um saldo recarregado em cripto, sem cartão, sem nome vinculado à máquina.
• Margem de folga, porque migrar duas vezes é o resultado que ninguém planeja. /vps lista os planos, e /guides tem o método de dimensionamento, caso a máquina atual nunca tenha sido de fato medida.
• IPv6 e um IPv4 limpo, já que um endereço reciclado pode chegar carregando a reputação de outra pessoa — verifique isso antes que vire um problema de e-mail.

Baixe o TTL do DNS primeiro, dias antes

Este é o único passo de preparação que não pode ser apressado no fim, porque o seu efeito é regido por um relógio que você não controla. O TTL dos seus registros diz aos resolvedores por quanto tempo guardar uma resposta em cache. Se ele estiver configurado para um dia, um resolvedor que perguntou uma hora atrás vai continuar mandando usuários para o servidor antigo pelas próximas vinte e três horas, não importa o que você publique.

1. 1

   Leia o TTL atual

   dig +noall +answer yourdomain.com mostra o tempo de cache restante; consultar diretamente o seu nameserver autoritativo com dig @ns1.example.net yourdomain.com mostra o valor configurado. Anote esse valor — ele define a duração do seu período de espera.

2. 2

   Baixe para 300 segundos

   Baixe o TTL em todo registro que vai mudar: A, AAAA, e qualquer MX ou CNAME que aponte para o host. Cinco minutos é curto o suficiente para tornar a virada tranquila e longo o suficiente para não sobrecarregar os seus nameservers.

3. 3

   Espere o TTL antigo passar, depois espere de novo

   O novo TTL curto só chega a um resolvedor depois que o antigo, longo, expira. Espere pelo menos um período inteiro do TTL antigo — um dia, se era um dia — antes de tratar o TTL baixo como real. Começar isso cedo não custa nada e é o que dá à virada inteira a sua margem.

Construa o servidor novo, não clone o antigo

O instinto é tirar uma imagem do disco atual e restaurá-la em outro lugar. É o movimento errado, pelo mesmo motivo que é errado em uma restauração: um clone em nível de bloco reproduz fielmente o desvio de configuração, os pacotes órfãos, o serviço meio configurado que alguém abandonou, e qualquer persistência que um invasor anterior tenha deixado para trás. Também prende você à versão antiga da distribuição.

Construa a máquina nova a partir de uma imagem base atual, instale os serviços a partir de um script, e copie somente os dados. O script é o verdadeiro entregável — é ele que transforma a próxima migração em uma tarde em vez de uma quinzena, e que permite reconstruir depois de um incidente sem arqueologia.

• Provisione, atualize e reforce a segurança antes que qualquer outra coisa toque nela: SSH somente com chave, um firewall que nega tudo por padrão, atualizações de segurança automáticas. /guides tem a versão de uma hora desse checklist.
• Instale as mesmas versões principais do runtime e do banco de dados que estão em produção. Uma migração é uma péssima hora para também atualizar o PostgreSQL 14 para o 17 — faça uma mudança de cada vez, para que uma falha tenha exatamente uma explicação.
• Recrie usuários e grupos com os mesmos IDs numéricos antes de copiar os arquivos, ou corrija o dono deles manualmente depois. Transferir com --numeric-ids mantém os números intactos; mapeá-los de volta para os nomes certos é trabalho seu.
• Coloque o endereço novo em toda lista de permissão que hoje cita o antigo — APIs de parceiros, firewalls de bancos de dados gerenciados, gateways de pagamento, o seu próprio monitoramento — enquanto os dois endereços ainda são válidos.

Copie os arquivos em duas passagens

Uma única transferência de um sistema de arquivos em produção é um retrato de um alvo em movimento. Duas passagens resolvem isso de forma limpa: a primeira é longa e roda contra um sistema em produção, a segunda é curta e roda durante o congelamento, e só a segunda precisa ser rápida.

Rode a primeira passagem quando quiser — dias antes está ótimo. Ela carrega o grosso: o diretório de uploads, o spool de e-mail, os volumes de contêiner, os anos de mídia acumulada. Ela vai estar desatualizada até você fazer a virada, e é exatamente para isso que serve a segunda passagem.

• Use rsync -aAXH --numeric-ids --info=progress2 sobre SSH: -a para os atributos de sempre, -A para ACLs, -X para atributos estendidos, -H para hard links, que importam se alguma coisa na máquina faz deduplicação.
• Exclua o que não deveria viajar: /proc, /sys, /dev, /run, os diretórios temporários, o cache de pacotes e os logs de que você não precisa. Copiar interfaces do kernel, na melhor das hipóteses desperdiça tempo, e na pior, trava a transferência.
• Acrescente --delete somente na segunda passagem. Na primeira, é inofensivo; na segunda, remove arquivos que foram apagados na origem desde então, que é precisamente o desvio que você está tentando eliminar.
• Copie a configuração do sistema de forma seletiva, não por atacado. Você quer os vhosts do seu servidor web, os units dos seus serviços e a configuração da sua aplicação — não a tabela de sistema de arquivos, a configuração de rede ou o ID de máquina da máquina antiga.
• Gere uma chave SSH descartável para a transferência, autorize-a no destino, e remova-a quando a migração terminar. Uma chave de migração que fica por aí durante dois anos é uma credencial que ninguém lembra de ter emitido.

Entre as passagens, verifique em vez de presumir. Rodar a segunda passagem com --dry-run imprime exatamente o que seria alterado: uma lista de algumas centenas de arquivos recentes é saudável, e uma lista de quarenta mil significa que uma exclusão está errada ou que algo está reescrevendo timestamps sem motivo.

Mova o banco de dados sem perder escritas

É aqui que o orçamento de congelamento é gasto, e a técnica certa é inteiramente determinada pelo número que você anotou no início. As três opções abaixo estão corretas — cada uma para um número diferente.

Faça o dump do schema e dos dados separadamente quando o dataset for grande. Restaurar o schema primeiro permite verificar a estrutura, os índices e as permissões no host novo com antecedência, o que transforma a carga dos dados em uma única operação longa que você pode iniciar durante o congelamento já confiante de que ela vai dar certo.

Emita o certificado TLS antes da troca, não depois

O certificado no servidor novo precisa estar válido no instante em que o primeiro usuário chegar. Descobrir o contrário depois significa que todo visitante encontra uma tela de aviso do navegador, e se você envia cabeçalhos HSTS — o que você deveria fazer —, eles não conseguem simplesmente clicar para continuar. Há duas formas de ter um certificado funcionando antes de o DNS apontar para qualquer lugar novo.

• Copie o certificado existente. O diretório de estado do ACME inteiro, ou só o certificado e a chave de onde quer que o seu cliente os guarde. Ele é válido imediatamente, porque a validade não tem nada a ver com qual servidor guarda o arquivo, e a renovação retoma normalmente assim que o DNS mudar.
• Emita um novo com um desafio DNS-01, que prova o controle do domínio por meio de um registro TXT em vez de uma requisição HTTP ao endereço atual. Isso funciona antes da migração, antes da virada, e para wildcards, o que o HTTP-01 não consegue fazer de jeito nenhum.
• Não tente validação HTTP-01 no servidor novo antes da troca. O desafio é buscado pela porta 80 no nome de domínio, o domínio ainda resolve para a máquina antiga, e a validação falha todas as vezes.

Verifique isso sem tocar no DNS, resolvendo o hostname para o endereço novo em um único comando: curl -sI --resolve yourdomain.com:443:198.51.100.10 https://yourdomain.com/ — substituindo pelo endereço real. Essa única linha é a verificação de maior valor de toda a migração. Ela exercita o vhost real, o certificado real e a stack de aplicação real na máquina nova, e é assim que você encontra a má configuração enquanto encontrá-la ainda não custa nada.

Se o servidor envia e-mail, comece mais cedo

E-mail é a parte de uma migração que falha dias depois, silenciosamente, e leva a culpa em outra coisa. Um endereço novo não tem reputação de envio e pode ter herdado a de outra pessoa, e todo registro de autenticação que você publica está atrelado ao endereço que você está deixando.

• Verifique o endereço novo nas principais listas de bloqueio antes de se comprometer com ele. Um IP reciclado com histórico vale a pena ser trocado enquanto trocá-lo ainda é de graça.
• Configure o registro de DNS reverso do endereço novo para o seu hostname de e-mail. Servidores receptores conferem se a resolução direta e a reversa concordam, e a simples ausência de um PTR já é suficiente para ser classificado como spam.
• Acrescente o endereço novo ao SPF antes da virada e remova o antigo depois — os dois listados durante a sobreposição, para que o e-mail se autentique a partir de qualquer um dos dois servidores que efetivamente o enviou.
• Copie as chaves privadas do DKIM em vez de gerar novas, para que o seletor já publicado no DNS continue validando. Gerar novas chaves significa republicar, e republicar tem o seu próprio atraso de propagação.
• Aqueça o endereço novo gradualmente, se você envia algum volume de mensagens. Um servidor que não enviou nada durante toda a sua existência e de repente emite dez mil mensagens é, para quem recebe, indistinguível de um host comprometido.

A virada

Tudo o que veio antes foi preparação para que esta parte seja curta, ordenada e reversível. Faça isso no seu mínimo de tráfego genuíno, em vez de às 3 da manhã por superstição — confira as suas próprias métricas. Tenha o plano de reversão escrito antes de começar, porque o momento em que você precisar dele é o momento em que menos vai querer estar redigindo-o.

1. 1

   Congele as escritas no servidor antigo

   Modo de manutenção, um usuário de banco de dados somente leitura, ou um erro nos caminhos de escrita no proxy reverso. As leituras continuam sendo servidas pela máquina antiga o tempo todo — é isso que mantém o site no ar enquanto os dados se movem.

2. 2

   Desative todo timer no servidor antigo

   Comente as crontabs, pare os timers, pare os workers de fila. A partir deste ponto, a máquina antiga não pode processar mais nada, ou as tarefas vão rodar duas vezes: duas faturas, dois e-mails, duas entregas de webhook.

3. 3

   Rode o delta final

   A segunda passagem de arquivos com --delete, depois o dump final do banco de dados ou a atualização final da réplica. Essa é a passagem curta, minutos no máximo, porque a primeira passagem já moveu o volume.

4. 4

   Verifique o servidor novo pelo seu hostname real

   Usando o truque do --resolve acima, exercite uma página que lê do banco de dados, um login, e um caminho de escrita. Confirme que a contagem de linhas bate com a origem. Faça tudo isso antes de o DNS mudar, enquanto reverter ainda não custa absolutamente nada.

5. 5

   Troque o DNS e inicie os serviços

   Atualize A e AAAA para o endereço novo, depois habilite e inicie a aplicação e os seus timers no servidor novo. O tráfego começa a chegar dentro de um TTL e continua migrando ao longo da hora seguinte.

6. 6

   Mantenha o servidor antigo servindo leituras

   Deixe-o no ar, somente leitura, por pelo menos vinte e quatro horas. Clientes com caches desatualizados ainda vão cair nele, e um servidor antigo somente leitura retorna páginas um pouco desatualizadas em vez de uma conexão recusada — a diferença entre uma migração invisível e uma visível.

As primeiras 48 horas

A migração não termina quando o site carrega. Ela termina quando nada mais depende da máquina antiga, e encontrar essas dependências é um exercício ativo, não um jogo de espera.

• Observe o log de acesso do servidor antigo. Toda requisição que ainda chega ali é uma dependência não migrada — um endereço fixo em uma integração de parceiro, um cliente mobile com um cache desatualizado, uma sonda de monitoramento que não tem dono. O log é a lista de tarefas.
• Confirme que os timers realmente rodaram no host novo. Não que estão habilitados — que eles rodaram, no horário esperado, com a saída esperada. Uma tarefa de cron que silenciosamente não faz nada parece exatamente igual a uma tarefa de cron que funciona.
• Teste a renovação do certificado de verdade com um dry run, em vez de descobrir daqui a sessenta dias que o seu cliente ACME vinha renovando contra um servidor que não recebe mais o desafio.
• Verifique o fluxo de e-mail de ponta a ponta nas duas direções, incluindo tudo o que a aplicação envia automaticamente. A redefinição de senha é a vítima clássica, porque ninguém a testa até um usuário precisar de uma.
• Faça um backup do servidor novo e restaure-o em algum lugar. Uma máquina nova sem um backup verificado é uma posição pior do que aquela que você deixou; /guides tem a versão completa desse argumento.
• Restaure o TTL do DNS ao seu valor normal assim que você estiver confiante. Deixá-lo em 300 segundos para sempre é um pequeno custo permanente em consultas e latência, sem benefício remanescente nenhum.

Desativando o servidor antigo

O último passo é o que costuma ser pulado, e é o único com consequência de privacidade. O disco antigo guarda as suas chaves, o seu banco de dados, os dados dos seus clientes e os seus logs, e cancelar o serviço não apaga nada disso — ele libera o volume de volta para um pool, onde o próximo inquilino recebe o que quer que a política de apagamento do provedor tenha deixado para trás.

• Espere o log de acesso antigo ficar quieto antes de tocar em qualquer coisa. Cancelar enquanto um provedor de pagamento ainda está postando webhooks para o endereço antigo é assim que uma migração vira um incidente uma semana depois.
• Rotacione em vez de simplesmente apagar: toda credencial que o servidor antigo guardava — chaves de API, senhas de banco de dados, chaves de deploy, a chave temporária de migração. Presuma que qualquer coisa que morou em uma máquina que você não controla mais está comprometida, porque, eventualmente, está.
• Sobrescreva os dados antes de liberar o volume. Destrua os diretórios sensíveis com segurança, ou preencha o espaço livre com um único arquivo aleatório grande e apague-o. Imperfeito em um disco virtualizado, e imensamente melhor do que nada.
• Faça um arquivo final de qualquer coisa que você possa querer como referência — logs, configuração, o histórico do shell que documenta o que foi realmente feito — e guarde-o criptografado em algum lugar que não seja nenhum dos dois servidores.
• Cancele o serviço só depois de o novo ter sobrevivido a um ciclo de cobrança completo e a um teste completo de backup e restauração. Esse mês de sobreposição é o seguro mais barato de todo o processo.

Uma linha do tempo que você pode copiar

Nada aqui é difícil isoladamente. O motivo pelo qual as migrações dão errado é que os passos são comprimidos em uma única noite, na qual o TTL não expirou, o certificado não foi testado e o plano de reversão não foi escrito. Espalhado ao longo de uma semana, cada dia é vinte minutos de trabalho.

Como as migrações realmente dão errado

Não pela cópia. Pelas coisas que nunca estiveram no disco, e pelas coisas que rodaram duas vezes.

• Os dois servidores escrevendo ao mesmo tempo — a janela de split-brain, e a única falha aqui sem uma correção limpa. Ela é evitada por ordenação, não por ferramenta: pare o antigo, depois inicie o novo.
• Timers rodando nas duas máquinas, que é como os clientes recebem duas cópias de tudo. Desative os antigos antes da sincronização final, não depois.
• Um TTL que nunca foi baixado, transformando uma virada de cinco minutos em uma cauda de um dia inteiro sem ninguém escalado para cobrir.
• A posse dos arquivos saindo errada porque os IDs numéricos diferem entre as máquinas, então a aplicação inicia e depois não consegue escrever no seu próprio diretório de upload.
• Um certificado que ia ser resolvido depois da troca, encontrando um cabeçalho HSTS que não deixa os visitantes com nenhuma forma de continuar.
• Um endereço fixo em algum lugar que você não controla — uma integração de parceiro, uma regra de firewall, um registro de DNS para um subdomínio que você tinha esquecido que existia.
• Cancelar o servidor antigo no dia da mudança, o que remove o caminho de reversão exatamente no momento em que as estatísticas dizem que você tem mais chance de precisar dele.