Lista de verificação de migração de VPS: backups, DNS, TLS e reversão
Uma sequência prática de migração para um aplicativo auto-hospedado: inventário, backups consistentes, um destino testado, gravações controladas, corte em DNS e um caminho de restauração.
Visão geral
Uma migração controlada de VPS faz o inventário de serviços e dados, cria um backup consistente, verifica um destino restaurado, testa o hostname e o roteamento de TLS, coordena as gravações finais e o DNS e preserva uma reversão ciente dos dados. Nenhuma lista de verificação, por si só, garante zero tempo de inatividade.
Faça o inventário do aplicativo antes de movê-lo
Liste os serviços, as versões, as portas, as tarefas agendadas, os bancos de dados, os arquivos enviados e a configuração necessária para o aplicativo funcionar. Identifique onde ocorrem as gravações e de quais serviços externos ele depende. Um diretório web copiado não é uma migração completa quando os dados ficam em outro lugar.
Registre os nomes atuais de DNS, os registros ativos de IPv4 e IPv6, os métodos de renovação de certificado e um caminho de acesso para recuperação. Mantenha os segredos nas suas ferramentas privadas de implantação. Não coloque senhas, chaves privadas ou dumps de banco de dados em um diretório público nem em uma lista de verificação de migração compartilhada.
Crie um backup consistente e comprove que ele restaura
Use o mecanismo de backup compatível com o banco de dados, em vez de copiar arquivos arbitrários enquanto as gravações continuam. Para o SQLite, o Online Backup do API cria um instantâneo consistente do banco de dados. No modo WAL, o arquivo WAL participa do estado persistente do banco de dados, então copiar apenas o arquivo principal do banco pode omitir alterações já confirmadas.
Um backup consistente do banco de dados não é automaticamente consistente com uploads, filas ou arquivos armazenados separadamente. Coordene a captura deles com seu aplicativo. Restaure em um local de teste separado e verifique registros, referências de arquivos e o comportamento do aplicativo antes de considerar o backup utilizável.
Prepare o destino antes de alterar DNS
Crie os usuários, as permissões, as versões de runtime, os serviços e os diretórios do aplicativo pretendidos no novo servidor. Restaure o backup de teste em seu local de dados de destino, fora da raiz pública da web quando apropriado. Verifique a propriedade e o acesso usando a conta de serviço que realmente executará o aplicativo.
Preserve sites não relacionados em um servidor compartilhado. Use uma raiz de documentos, um host virtual e um runtime dedicados, valide a configuração do servidor web e prepare uma reversão que restaure apenas os arquivos e a configuração pertencentes a essa alteração.
Teste o hostname e o certificado reais no novo servidor
Uma requisição de navegador a um endereço IP puro não reproduz o roteamento baseado em hostname nem a validação de certificado. O curl --resolve permite que um teste use o hostname pretendido e um IP de destino escolhido, mantendo as verificações normais de hostname e TLS. Verifique também o status HTTP e o conteúdo esperado do aplicativo. O exemplo usa valores apenas de documentação; substitua-os pelo seu próprio domínio e destino verificados.
Um certificado válido e um caminho de rede permitido já devem existir para que esse teste passe. Nunca desative a verificação de certificado para declarar a migração pronta. A validação de ACME baseada em DNS pode validar um domínio sem alterar o endereço do seu servidor web; a validação baseada em HTTP tem requisitos de alcançabilidade diferentes. Teste a renovação separadamente da emissão inicial.
curl --fail-with-body --show-error --resolve example.com:443:203.0.113.10 https://example.com/Escolha um plano de controle de gravação e sincronização final
Agende um curto período de manutenção ou outro mecanismo de consistência apropriado ao aplicativo. Pare ou redirecione os agentes de gravação que você identificou, faça o backup final consistente do banco de dados, sincronize os arquivos mutáveis correspondentes e verifique o resultado. Workers de fila, webhooks e tarefas cron podem gravar mesmo quando a interface pública parece tranquila.
Faça uma execução de teste antes de uma sincronização de arquivos. Não adicione sinalizadores de exclusão nem copie diretórios inteiros do sistema como atalho. Mantenha o serviço antigo recuperável até ter verificado o novo aplicativo e estabelecido qual local é autoritativo para gravações.
Altere DNS e depois observe as duas famílias de endereços
Atualize os registros necessários para o serviço e leve em conta os caches de resolvedores existentes. Verifique as respostas autoritativas e vários caminhos normais de clientes. Se um registro AAAA obsoleto permanecer ativo, clientes IPv6 podem continuar chegando ao servidor antigo enquanto clientes IPv4 chegam ao novo.
Teste login, leituras, gravações, uploads, tarefas em segundo plano e callbacks externos no novo serviço. Evite executar duas cópias graváveis independentes do mesmo aplicativo durante a transição. Mantenha uma regra clara para lidar com o tráfego que ainda chega ao destino antigo.
Faça da reversão uma decisão de dados, bem como uma decisão de DNS
Defina as condições de falha que acionam uma reversão e quem controla o corte. Reverter apenas o DNS não é suficiente depois que novas gravações chegaram ao destino: você deve preservar ou reconciliar esses dados antes de retornar a uma cópia mais antiga.
Mantenha a origem e os backups por um período de recuperação apropriado. Remova acessos antigos e desative recursos somente depois de verificar o destino, os backups, a renovação e o monitoramento. A retenção e a exclusão devem seguir a política real do serviço, não um número fixo genérico de horas.