# Um runbook de migração de servidor dedicado que protege os dados | SwissOctet Insights https://swissoctet.com/pt/insights/dedicated-server-migration-runbook/ SwissOctet / Informações / Dedicado e GPU Dedicado e GPU Aplicado · 6 min de leitura Um runbook de migração de servidor dedicado que protege os dados Ensaiar a mudança, estabelecer um limite de dados consistente e definir o que significa rollback depois de o novo sistema aceitar escritas. Por SwissOctet Editorial Guardar guia Copiar ligação NESTA PÁGINA 01 Inventariar o serviço antes de mover a máquina 02 Construir o destino como um ambiente separado 03 Escolher um limite de dados consistente 04 Preparar o encaminhamento de tráfego sem prometer alterações instantâneas 05 Definir rollback depois de começarem as escritas 06 Encerrar a migração com verificações operacionais A sua lista de verificação prática Fontes e leitura adicional Voltar à biblioteca A RESPOSTA DIRETA 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. 01 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. 02 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. 03 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 04 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. 05 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. 06 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. TRANSFORME ISTO EM AÇÃO 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. Descarregar lista de verificação PERGUNTAS FREQUENTES 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. REFERÊNCIAS PRIMÁRIAS 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. LIGUE O CONHECIMENTO Infraestrutura relacionada. Metal Atlas Suíça Metal Zenith Suíça Metal EPYC Suíça MANTENHA O FIO As suas próximas notas de campo. Explore todos os guias NOTA DE CAMPO / 01 + Dedicado e GPU Fundação VPS ou dedicado: escolha o limite que se adequa Compreenda o que uma máquina física altera, o que não altera e quando se torna um passo útil para a sua carga de trabalho. 4 min de leitura Leia o guia NOTA DE CAMPO / 02 + Operações do dia-a-dia Aplicado Construa uma cópia de segurança que consiga realmente restaurar Escolha um objetivo de recuperação, proteja uma cópia independente e pratique a restauração antes que um incidente force a questão. 4 min de leitura Leia o guia NOTA DE CAMPO / 03 + Dedicado e GPU Avançado Construir um orçamento de VRAM para GPU antes de escolher hardware Contabilize pesos, ativações, caches e buffers temporários e depois teste a carga de pico em vez de apenas o ficheiro do modelo. 6 min de leitura Leia o guia