Ninguém migra um site no ar por entretenimento. Isso acontece porque o host atual de repente quer uma foto do seu passaporte, ou repassa uma reclamação com prazo de 24 horas, ou porque o país onde fica o datacenter deixou de parecer um lugar sensato para manter seus dados. Seja qual for o motivo, a migração em si é a parte perigosa — é o único momento em que o site pode sair do ar, e o único momento em que um passo descuidado pode grudar o novo servidor na identidade que você estava tentando deixar para trás.
Os dois riscos têm a mesma cura, e não é uma ferramenta. É ordem. Uma migração feita na sequência certa não tem nenhuma janela em que o site fica inacessível, porque os dois servidores estão ativos ao mesmo tempo e o DNS é a última coisa a mudar. Uma migração feita na sequência errada produz uma queda e um rastro ao mesmo tempo. O que vem a seguir é essa sequência, escrita para quem está migrando para um host offshore sem KYC, e não trocando entre dois provedores tradicionais — a mecânica é a mesma, mas a limpeza depois não é.
O que "zero downtime" realmente significa
A expressão é usada de forma solta, e é nessa imprecisão que as pessoas se machucam. Servir HTTP a partir de duas máquinas ao mesmo tempo é fácil. Manter o estado consistente enquanto as duas máquinas servem ao mesmo tempo é a parte difícil, e é a única parte que chega a perder dados. Então, antes de planejar qualquer coisa, decida qual desses cenários você está realmente rodando, porque a resposta define o formato da noite inteira.
| O que você está migrando | A parte que realmente morde | Qual deve ser o plano |
|---|---|---|
| Site estático, site institucional, saída gerada | Nada. Não há estado para dividir | Copiar, verificar, virar a chave. Zero downtime de verdade |
| CMS com banco de dados — WordPress, Ghost, um fórum | Comentários, logins e posts caindo em dois bancos ao mesmo tempo | Um congelamento somente leitura medido em minutos, no seu horário mais tranquilo |
| Uma loja, ou qualquer coisa que receba pedidos | Um split brain perde pedidos pagos silenciosamente | Assuma a janela de manutenção curta. Sai mais barato que a reconciliação |
| Qualquer coisa com cron jobs ou workers em segundo plano | O mesmo job disparando nos dois servidores — e-mails em dobro, cobranças em dobro | Desative o agendamento no host antigo antes de o novo começar |
| E-mail no mesmo domínio | Registros MX expiram dos caches no próprio relógio deles, sem relação com o seu registro A | Migre o e-mail numa noite separada, e mantenha o MX antigo aceitando por uma semana |
Note que só a primeira linha é realmente gratuita. Em todo o resto, "zero downtime" significa "um congelamento de escrita tão curto que ninguém abre um chamado por causa dele". Dois minutos de somente leitura às 4h da manhã são um erro de arredondamento; duas horas de escritas divididas entre dois bancos de dados são um fim de semana de reconciliação. Escolha o congelamento.
Baixe o TTL do DNS dias antes de planejar a migração
Este é o único passo com prazo de antecedência, por isso é o primeiro e por isso é o que as pessoas pulam. Seu TTL — time to live — diz a cada resolver na internet por quanto tempo ele pode manter seu registro em cache antes de perguntar de novo. Se o seu registro A tem um TTL de 86400, um resolver que consultou há uma hora vai continuar entregando o IP antigo por mais 23 horas, não importa o que você mude no registrador.
O detalhe crítico é que baixar o TTL está, ele mesmo, sujeito ao TTL antigo. Os resolvers só ficam sabendo do valor novo, menor, quando a cópia antiga em cache expira. Então baixe o TTL para 300 segundos pelo menos um período inteiro do TTL antigo antes da virada — com um TTL de um dia, isso significa fazer isso de 24 a 48 horas antes. Aí o mundo converge para o seu novo registro em até cinco minutos após a mudança, e a virada deixa de ser um evento de suspense.
Volte o TTL para algo razoável alguns dias depois da migração. Um TTL de 300 segundos é uma ferramenta ótima e uma configuração permanente ruim: ele multiplica o volume de consultas e transforma seu provedor de DNS num ponto único de falha muito mais afiado.
Faça o inventário do que você está migrando, não do que você lembra
Toda migração fracassada tem o mesmo post-mortem: algo que ninguém listou não foi copiado. A raiz do site e o banco de dados são as duas coisas que todo mundo lembra; a lista abaixo é o resto, e vale a pena percorrê-la ao pé da letra em vez de confiar na memória.
- Trabalho agendado.
crontab -lpara cada usuário, mais os timers do systemd. Hooks de renovação e jobs noturnos se escondem aqui. - Definições de serviço. Units customizadas do systemd, os vhosts do servidor web, pools do PHP-FPM, qualquer configuração de supervisor.
- Segredos e ambiente. Arquivos
.env, chaves de API, senhas de banco de dados, salts da aplicação — e vale notar que eles devem ser rotacionados, não apenas copiados. - Material TLS. Certificados e, mais importante, a conta ACME e a configuração de renovação.
- Identidade de e-mail. Chaves privadas DKIM, registros SPF e DMARC. Uma incompatibilidade aqui não quebra de forma barulhenta; ela só manda seu e-mail para o spam, silenciosamente.
- Mídia enviada pelos usuários. Frequentemente fora da raiz do site, frequentemente a maior coisa que você possui.
- Tudo externo que confia no seu IP. Allowlists de gateway de pagamento, destinos de webhook, firewalls de banco de dados, APIs de terceiros com restrição de IP. Essa é a causa número um do "o site funciona mas o checkout está quebrado" às 3h da manhã.
- A lista de pacotes.
dpkg --get-selectionsou o equivalente, para que a máquina nova tenha as mesmas extensões e bibliotecas, e não quase as mesmas.
Anote a lista antes de começar a copiar. O inventário também é o seu plano de testes depois — cada linha dele é algo para verificar no novo servidor antes que o DNS saiba que ele existe.
Construa o novo servidor primeiro, e faça o hardening antes de ele guardar qualquer coisa
Contrate o destino com antecedência e deixe-o rodando vazio por um dia ou dois. Não há custo nenhum nessa sobreposição — um VPS offshore pequeno custa alguns dólares por mês — e há um grande valor em não fazer a construção sob pressão de tempo, com um banco de dados congelado esperando.
Combine com o ambiente antigo deliberadamente: a mesma distribuição e versão principal, a mesma versão principal do PHP, Node ou Python, a mesma versão principal do banco de dados. A tentação de modernizar tudo enquanto você está lá dentro é enorme e deve ser resistida por completo. Se o site quebrar depois da virada, você quer que exatamente uma variável tenha mudado. Atualize a stack duas semanas depois, numa tarde tediosa, com a capacidade de reverter.
Faça o hardening dele enquanto ainda está vazio. SSH somente com chaves, um firewall padrão-negar, atualizações de segurança automáticas — o checklist de hardening da primeira hora é exatamente essa lista, e é muito mais fácil de aplicar numa máquina sem nada rodando nela. Se o dado for sensível o bastante para você estar mudando de jurisdição por causa dele, este também é o momento certo para decidir sobre criptografia em repouso, porque aplicar isso depois significa outra migração.
Copie os dados duas vezes: uma passada lenta, depois uma rápida
O instinto é copiar tudo durante a janela de manutenção. Faça o oposto. Rode uma cópia completa dias antes, enquanto o site antigo ainda está servindo tráfego tranquilamente, depois rode uma segunda passada na virada que só move o que mudou. A primeira passada pode levar seis horas e ninguém percebe. A segunda leva 90 segundos, e esse é todo o seu orçamento de downtime.
Para arquivos, rsync -aHAX --numeric-ids preserva permissões, propriedade, hard links e atributos estendidos; a flag --numeric-ids importa porque os UIDs raramente coincidem entre duas máquinas recém-criadas. Rode uma vez com antecedência, depois de novo imediatamente antes da virada com os mesmos argumentos — a segunda execução transfere só o delta.
Bancos de dados precisam do mesmo tratamento em duas fases, mas com ferramentas diferentes. Um mysqldump --single-transaction ou pg_dump te dá um snapshot antecipado consistente para construir e testar. Na virada, ou você tira um segundo dump durante o seu breve congelamento de escrita, ou — para um banco de dados grande, onde até um congelamento curto dói — configura o novo servidor como réplica do antigo com dias de antecedência, deixa ele alcançar o estado atual, e então o promove. Replicação transforma o congelamento em segundos. Também transforma uma migração de duas horas num projeto de dois dias, então use isso só quando o tamanho realmente exigir.
Pull, não push, e nunca pelo seu laptop. Inicie a cópia a partir do novo servidor, para que a transferência rode de host a host na velocidade do datacenter. Rotear gigabytes pela sua conexão doméstica é lento, e coloca o seu IP residencial nos logs de acesso das duas máquinas — que é precisamente o vínculo que uma migração motivada por privacidade existe para evitar. Se até o host antigo descobrir o seu novo IP for inaceitável, não copie diretamente de jeito nenhum: em vez disso, restaure o novo servidor a partir do seu próprio backup externo criptografado, e as duas máquinas nunca chegam a se falar.
Teste o novo servidor antes que o DNS saiba que ele existe
Você pode servir o hostname real a partir do novo IP sem mudar um único registro público, e deveria fazer isso — é isso que torna a virada tranquila. Adicione uma linha ao seu /etc/hosts local apontando o domínio para o novo IP, ou pule isso e deixe o curl fazer isso para uma única requisição:
curl -I --resolve example.com:443:203.0.113.10 https://example.com/
Agora percorra o inventário. Carregue a página inicial e três páginas internas. Faça login. Envie um formulário. Suba um arquivo. Confira se a conexão com o banco de dados é a nova, local, e não ainda apontando para o host antigo pela internet — um erro que funciona perfeitamente até o momento em que você cancela o servidor antigo. Rode os cron jobs manualmente e leia a saída deles. Verifique os redirecionamentos e que uma URL inexistente ainda retorna 404 em vez de 200.
Emita o certificado TLS agora, antes da virada, não depois. Use um desafio DNS-01, que prova o controle do domínio por meio de um registro TXT e por isso funciona enquanto o registro A ainda aponta para o servidor antigo. Se você esperar a validação HTTP-01 depois da mudança de DNS, todo visitante inicial recebe um aviso de certificado durante essa lacuna — uma queda autoinfligida bem na janela que você estava tentando proteger.
A virada, em ordem
Neste ponto, o novo servidor já está construído, com o hardening feito, populado, testado sob o hostname real e com um certificado válido. A virada em si agora é uma lista curta e tediosa, que é exatamente o objetivo.
- Avise sobre a janela se mais alguém depende do site, depois coloque o site antigo em modo somente leitura ou manutenção.
- Desative o cron e os workers em segundo plano no host antigo. Faça isso antes de iniciá-los no novo, nunca depois.
- Rode a passada final de delta do
rsynce o dump final do banco de dados, e importe-o. - Inicie a aplicação no novo servidor e rode de novo seus smoke tests via
--resolve, contra os dados finais. - Mude os registros A e AAAA para o novo IP. Com um TTL de 300 segundos, o mundo acompanha em até cinco minutos.
- Ative o cron e os workers no host novo.
- Observe os dois logs de acesso lado a lado. O tráfego escoa do servidor antigo e aparece no novo; quando o antigo fica quieto, a virada está completa.
- Deixe o servidor antigo rodando, servindo, e intocado por uma semana. Ele é o seu rollback.
O passo oito é o que as pessoas cortam, e é o seguro mais barato da lista. Pelo preço de alguns dólares você mantém a capacidade de apontar o DNS de volta — uma recuperação de cinco minutos — pelo tempo que for preciso até ter certeza.
O que a migração deixa para trás
Aqui está a parte que os guias genéricos de migração omitem, e a parte que mais importa se você migrou por privacidade em vez de preço. Migrar um site não apaga a sua história. Vários registros públicos e semipúblicos do arranjo antigo sobrevivem à migração permanentemente, e saber quais são eles é a diferença entre um corte limpo e uma falsa sensação de um.
| O que registra a migração | Quem consegue ler isso | O que você realmente pode fazer |
|---|---|---|
| DNS passivo — registros A históricos | Qualquer pessoa, por meio de serviços comerciais de histórico | Nada. O IP antigo fica associado ao nome permanentemente. Planeje como se fosse público, porque é |
| Logs de Certificate Transparency | Qualquer pessoa, permanentemente, pesquisável por domínio | Todo certificado já emitido é listado — incluindo os subdomínios de nome interno que você esqueceu. Prefira um wildcard a nomes descritivos |
| Os registros de conta do host antigo | O host antigo, e qualquer um que possa obrigá-lo | Dados do cartão, e-mail de cadastro, IPs de login. Um destino sem KYC protege o futuro, não o passado |
| Histórico de WHOIS | Arquivos comerciais de histórico de WHOIS | Se o domínio já foi registrado com dados reais, aquele retrato foi capturado. Privacidade aplicada depois não o desfaz |
| Identificadores de analytics e anúncios | O fornecedor, e qualquer um que leia o código-fonte da sua página | Carregar o mesmo ID de rastreamento liga os dois sites de forma conclusiva. Emita um novo, ou remova-o |
| Dumps e backups deixados no disco antigo | Quem quer que receba aquele armazenamento em seguida | Apague e sobrescreva antes de cancelar. Em armazenamento compartilhado, assuma que a exclusão é uma sugestão, não uma garantia |
Cabeçalhos Received: no e-mail enviado | Todo destinatário, para sempre | Nada retroativo. Só o e-mail que você enviar depois da migração carrega o novo caminho |
| Suas próprias conexões durante a cópia | Seu provedor de internet, e os logs de acesso dos dois hosts | Esse aqui está inteiramente sob seu controle. Nunca acesse nenhuma das máquinas a partir de um IP que te identifique |
O resumo honesto é que uma migração não consegue reescrever o passado — ela só pode parar de adicionar coisas a ele. Isso ainda vale muito, mas muda a decisão: se o seu modelo de ameaça exige que nenhum observador consiga ligar o site novo ao antigo, migrar o mesmo domínio para um host novo não resolve isso, e nenhum cuidado durante a virada vai resolver. Esse caso precisa de um nome novo e um recomeço limpo, discutido a seguir. Se o seu objetivo é, em vez disso, parar de gerar registros identificáveis a partir de hoje, e mover o centro de gravidade legal para uma jurisdição que você escolheu, a migração faz exatamente isso. Nosso guia de OpSec de servidor cobre os hábitos que mantêm isso limpo depois.
A questão do domínio: levar junto, ou começar do zero?
O site e o domínio são decisões independentes, e confundir as duas é comum. Você pode migrar a hospedagem hoje e nunca mais mexer no registrador; nada na troca de servidor exige tocar no domínio. Se você deveria fazer isso depende inteiramente do que o domínio já sabe sobre você.
- Mantenha o domínio, troque o registrador. Sensato quando o domínio tem valor — links, rankings, um nome que as pessoas digitam. Isso resolve o futuro do registro WHOIS, não o seu histórico, e mantém todo sinal de ranking intacto. Essa é a resposta certa para a maioria dos sites comerciais.
- Mantenha o domínio, não mude nada além do host. Perfeitamente razoável quando você migrou por jurisdição, uptime ou postura de DMCA, e não por anonimato. A migração mais simples possível, com risco zero de SEO.
- Domínio novo, redirecionando o antigo. Preserva os rankings, e liga os dois nomes pública e permanentemente. Escolha essa opção por continuidade, nunca por privacidade — o redirecionamento é o vínculo.
- Domínio novo, corte limpo. A única opção que realmente rompe a associação, e custa todo ranking e link de entrada que você tinha. Registre-o de forma privada desde o início, porque um domínio só é tão anônimo quanto o seu primeiro registro. Nosso guia de registro anônimo de domínio com cripto cobre como fazer isso direito.
Escolha deliberadamente, e escolha antes da virada, não durante ela. Mudar de ideia sobre o domínio depois que o DNS já migrou significa fazer a parte delicada duas vezes.
Desative o host antigo corretamente
Uma semana ou duas depois da virada, quando os logs do novo servidor estiverem tediosos e os do antigo estiverem vazios, é hora de fechar a conta antiga. Faça isso nesta ordem, porque o atalho tentador — clicar em cancelar — é o que deixa seus dados no disco de outra pessoa.
- Confirme que nada mais aponta para o IP antigo: verifique endereços fixos em webhooks de terceiros, allowlists, monitoramento, e qualquer registro de DNS que você tenha esquecido, como um subdomínio perdido
mailoucpanel. - Rotacione todo segredo que já viveu naquela máquina — senhas de banco de dados, chaves de API, salts da aplicação, chaves DKIM, chaves SSH. Não as copie para a frente.
- Remova suas chaves públicas SSH e qualquer acesso de suporte do servidor antigo.
- Apague a aplicação, os dumps e os backups, depois sobrescreva o espaço livre para que uma leitura casual do volume reciclado não retorne nada.
- Só então encerre o serviço, e remova qualquer forma de pagamento salva da conta antiga.
Qualquer coisa que viveu num hardware que você não controla mais está comprometida por definição. Não porque o seu host antigo seja malicioso, mas porque aquele disco vai voltar para um pool e você nunca vai saber o que sobreviveu à limpeza. Rotacionar uma senha de banco de dados leva dois minutos. Descobrir meses depois que uma chave de um servidor desativado ainda abre alguma coisa leva consideravelmente mais tempo.
A sequência inteira, numa página só
Tirando o raciocínio, uma migração de host são nove passos, dos quais só dois têm alguma urgência:
- Dois dias antes: baixe o TTL do DNS para 300 segundos.
- Dois dias antes: contrate e faça o hardening do servidor de destino, casando a versão da stack antiga, versão por versão.
- Dias antes: escreva o inventário — cron, segredos, TLS, chaves de e-mail, mídia, allowlists de IP, pacotes.
- Dias antes: rode a primeira cópia completa dos dados, de host a host.
- Antes da janela: emita o certificado via DNS-01 e teste tudo através do
--resolve. - A janela (minutos): congele as escritas, desative o cron antigo, rode a cópia delta e o dump final, inicie a nova aplicação.
- A janela (segundos): mude o registro A, depois ative o cron no host novo.
- Na semana seguinte: mantenha o servidor antigo vivo como rollback, observe os dois arquivos de log, depois suba o TTL de novo.
- Depois: rotacione segredos, apague, cancele — e lembre do que a migração não conseguiu apagar.
Nada nessa lista é difícil. Todo passo que dói é um passo feito fora de ordem — um TTL baixado na própria noite, um certificado emitido depois da mudança de DNS, um cron job deixado ativo numa máquina que não é mais autoritativa. Acerte a sequência e a parte interessante de uma migração passa a ser escolher onde colocar o servidor, não a migração em si. Se você ainda não decidiu isso, o guia de jurisdições é o lugar para começar.