Prepare e teste primeiro o novo servidor, copie os dados com um método de consistência suportado pela aplicação, defina uma janela de cutover e preserve o ambiente antigo. O rollback tem de ter em conta as escritas aceites no novo servidor, e não apenas uma alteração de DNS.
Inventariar o serviço antes de mover a máquina
Uma migração inclui mais do que os ficheiros da aplicação. Enumere bases de dados, uploads, tarefas agendadas, workers de filas, certificados, domínios, segredos e integrações de saída. Registe as versões de software e os pressupostos operacionais que importam, como permissões de ficheiros e caminhos de armazenamento. Um servidor dedicado novo pode expor uma dependência esquecida que foi instalada discretamente anos antes no ambiente antigo.
Atribua um responsável pela decisão de cutover e defina o que significa sucesso. Inclua verificações visíveis ao utilizador, consistência de dados e a capacidade de recuperar o acesso. Confirme que a nova configuração é entregue e utilizável antes de anunciar uma data de migração. Uma confirmação de encomenda ou uma especificação de hardware listada não é o mesmo que um destino funcional pronto para receber dados de produção.
Construir o destino como um ambiente separado
Instale a stack necessária, estabeleça a administração e configure a firewall pretendida. Mantenha os segredos privados e defina as permissões dos serviços de forma deliberada. Verifique o hostname esperado pela aplicação e o comportamento do certificado antes de o tráfego público mudar. A documentação de virtual hosts da Apache ilustra por que o encaminhamento por hostname é uma decisão de configuração separada do endereço do servidor. Uma página predefinida funcional não prova que o host correto da aplicação está configurado.
Utilize um conjunto de dados restaurado representativo para o ensaio, com email de saída, pagamentos e tarefas agendadas desativados ou redirecionados para sistemas de teste seguros. Isto impede que o ambiente de teste atue sobre utilizadores reais. Exercite o login, os uploads, o trabalho em segundo plano e a restauração. Registe o procedimento e a sua duração para que a janela real se baseie num processo observado e não no otimismo.
Escolher um limite de dados consistente
Utilize um método de backup ou replicação suportado pela base de dados e pela aplicação. A PostgreSQL distingue dumps SQL, backups do sistema de ficheiros e arquivo contínuo, cada um com os seus próprios pressupostos. A sua orientação sobre dumps observa que os dumps de base de dados podem ser internamente consistentes, enquanto as funções à escala do cluster e outros detalhes precisam de tratamento separado. Leia os requisitos para o sistema exato que executa em vez de copiar ficheiros de dados abertos indiscriminadamente.
Planeie como a base de dados se relaciona com os uploads e o estado das filas. Se um registo aponta para um ficheiro que foi copiado noutro momento, a aplicação restaurada pode ficar incompleta mesmo que ambas as cópias tenham sido bem-sucedidas individualmente. Decida se deve pausar brevemente as escritas, usar um esquema de replicação testado ou realizar uma exportação específica da aplicação. Mantenha essa decisão de consistência explícita no runbook.
| Fase | Evidência necessária | Decisão |
|---|---|---|
| Ensaio | A aplicação e os dados restaurados passam as verificações | O destino pode ser considerado para cutover |
| Sincronização final | Ponto de recuperação consistente definido | Prosseguir apenas com as alterações restantes compreendidas |
| Mudança de tráfego | Encaminhamento e comportamento de certificado corretos | Monitorizar ambos os destinos |
| Rollback | Localização de todas as escritas recentemente aceites | Reconciliar os dados antes de devolver o tráfego |
Preparar o encaminhamento de tráfego sem prometer alterações instantâneas
O time-to-live da DNS controla durante quanto tempo os registos podem ser colocados em cache, como explicado na documentação DNS da Cloudflare. Reveja o TTL desde cedo se o DNS fizer parte da migração e deixe os registos em cache existentes expirar segundo a definição anterior. Alterar o valor no momento do cutover não consegue encurtar retroativamente todas as respostas em cache. Diferentes clientes podem chegar a destinos diferentes durante a transição.
Mantenha o ambiente antigo disponível enquanto as alterações de encaminhamento assentam, com uma política deliberada sobre se ainda pode aceitar escritas. Evite executar consumidores de filas ou tarefas agendadas duplicados, a menos que a aplicação tenha sido concebida para isso. Monitorize os pedidos de ambos os lados e confirme o hostname pretendido, o certificado TLS e a versão da aplicação a partir de clientes independentes.
Definir rollback depois de começarem as escritas
Antes de o novo sistema aceitar alterações, o tráfego de retorno pode ser relativamente simples. Depois, uma reversão de DNS por si só pode perder trabalho ou criar dois históricos em conflito. Defina como os registos e carregamentos criados recentemente seriam preservados ou reconciliados. Se a aplicação não os conseguir fundir em segurança, um período de manutenção controlado pode ser preferível a um regresso improvisado à cópia antiga.
Defina as condições que exigem pausar a migração e mantenha o responsável pela decisão contactável. Preserve registos e evidências úteis segundo as regras de retenção do projeto. Não elimine a máquina antiga nem a sua cópia de recuperação independente apenas porque a página inicial carregou uma vez. O período de retenção deve cobrir as necessidades acordadas de verificação e reversão.
Encerrar a migração com verificações operacionais
Após a transição, verifique cópias de segurança, alertas, renovação de certificados, tarefas agendadas e recuperação de acessos. Confirme que o anfitrião monitorizado é o novo destino e que não permanecem integrações de teste em produção. Reveja erros da aplicação e tempos visíveis ao utilizador sob tráfego normal. Atualize o inventário e o manual de operações para que o próximo administrador não tenha de inferir o que mudou.
As famílias dedicadas da SwissOctet oferecem diferentes configurações físicas, mas o trabalho de migração e a assistência gerida têm de ser confirmados para o serviço escolhido. Use o catálogo para selecionar recursos adequados e depois construa uma mudança testada em torno dos dados da sua aplicação. Uma migração está concluída quando o serviço e o seu processo de recuperação funcionam no destino, não apenas quando os ficheiros foram transferidos.
A sua lista de verificação prática.
- Inventarie dados, tarefas, segredos e integrações.
- Verifique o destino entregue antes de agendar.
- Ensaiar com integrações externas seguras.
- Defina a consistência da base de dados e dos carregamentos.
- Planeie a transição de encaminhamento e a prevenção de tarefas duplicadas.
- Especifique a reversão para novas escritas.
- Verifique cópias de segurança e monitorização após a transição.
Os detalhes que importam.
Posso migrar copiando o diretório da aplicação?+
Apenas se isso capturar tudo o que o serviço necessita e preservar a consistência. Bases de dados, carregamentos, tarefas, segredos e configuração normalmente exigem atenção separada.
Reduzir o TTL de DNS torna a transição instantânea?+
Não. As respostas previamente em cache podem permanecer até ao fim do seu tempo de vida anterior, e os clientes podem atualizar em momentos diferentes.
A reversão consiste apenas em apontar DNS para o servidor antigo?+
Não depois de o novo servidor aceitar escritas. Tem de contabilizar esses registos e ficheiros antes de devolver o tráfego.
Vá à fonte.
Estas referências sustentam os conceitos técnicos deste guia. Siga a documentação atual antes de alterar um sistema de produção.
- PostgreSQL: Cópia de segurança e restauro www.postgresql.org
- PostgreSQL: Consistência e restauro de dumps SQL www.postgresql.org
- Apache: Documentação de Virtual Host httpd.apache.org
- Cloudflare DNS: Time to Live developers.cloudflare.com
Orientação editorial da SwissOctet. Os exemplos são ilustrativos. As especificações de serviço, as opções disponíveis e as condições contratuais devem ser verificadas separadamente.