# Um runbook de migração de servidor dedicado que protege os dados | SwissOctet Insights https://swissoctet.com/pt-br/insights/dedicated-server-migration-runbook/ SwissOctet / Insights / 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 que o novo sistema aceitar gravações. Por SwissOctet Editorial Salvar guia Copiar link 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 roteamento de tráfego sem prometer mudanças instantâneas 05 Definir rollback depois que as gravações começarem 06 Encerrar a migração com verificações operacionais Sua lista prática Fontes e leitura adicional Voltar para a biblioteca A RESPOSTA DIRETA Prepare e teste o novo servidor primeiro, copie os dados com um método de consistência compatível com a aplicação, defina uma janela de cutover e preserve o ambiente antigo. O rollback deve considerar as gravações aceitas no novo servidor, não apenas uma mudança de DNS. 01 Inventariar o serviço antes de mover a máquina Uma migração inclui mais do que os arquivos da aplicação. Liste bancos de dados, uploads, tarefas agendadas, workers de fila, certificados, domínios, segredos e integrações de saída. Registre as versões de software e as premissas operacionais relevantes, como permissões de arquivo e caminhos de armazenamento. Um servidor dedicado novo pode expor uma dependência esquecida que foi instalada silenciosamente anos antes no ambiente antigo. Atribua um responsável pela decisão de cutover e defina como é o sucesso. Inclua verificações visíveis ao usuário, consistência de dados e a capacidade de recuperar o acesso. Confirme que a nova configuração foi entregue e é utilizável antes de anunciar uma data de migração. Uma confirmação de pedido 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 o firewall pretendido. Mantenha os segredos em sigilo e defina as permissões de serviço deliberadamente. Verifique o hostname esperado pela aplicação e o comportamento do certificado antes que o tráfego público seja movido. A documentação de virtual-host da Apache ilustra por que o roteamento por hostname é uma decisão de configuração separada do endereço do servidor. Uma página padrão funcional não prova que o host correto da aplicação está configurado. Use um conjunto de dados restaurado representativo para o ensaio, com e-mail de saída, pagamentos e tarefas agendadas desativados ou redirecionados para sistemas de teste seguros. Isso evita que o ambiente de teste atue sobre usuários reais. Exercite login, uploads, trabalho em segundo plano e restauração. Registre o procedimento e sua duração para que a janela real se baseie em um processo observado, e não em otimismo. 03 Escolher um limite de dados consistente Use um método de backup ou replicação compatível com o banco de dados e a aplicação. A PostgreSQL distingue dumps SQL, backups de sistema de arquivos e arquivamento contínuo, cada um com suas próprias premissas. Sua orientação sobre dumps observa que os dumps de banco de dados podem ser internamente consistentes, enquanto funções de todo o cluster e outros detalhes precisam de tratamento separado. Leia os requisitos do sistema exato que você executa em vez de copiar arquivos de dados abertos indiscriminadamente. Planeje como o banco de dados se relaciona com uploads e o estado da fila. Se um registro aponta para um arquivo que foi copiado em outro momento, a aplicação restaurada pode ficar incompleta mesmo quando ambas as cópias tiveram êxito individualmente. Decida se deve pausar brevemente as gravações, usar um arranjo 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. Etapa Evidência necessária Decisão Ensaio Aplicação e dados restaurados passam nas verificações O destino pode ser considerado para cutover Sincronização final Ponto de recuperação consistente definido Prosseguir apenas com as mudanças restantes compreendidas Troca de tráfego Roteamento e comportamento de certificado corretos Monitorar ambos os destinos Rollback Localização de todas as gravações recém-aceitas Reconciliar os dados antes de devolver o tráfego 04 Preparar o roteamento de tráfego sem prometer mudanças instantâneas O DNS time-to-live controla por quanto tempo os registros podem ser armazenados em cache, conforme explicado na documentação de DNS da Cloudflare. Revise o TTL cedo se o DNS fizer parte da migração e permita que os registros em cache existentes expirem sob a configuração anterior. Alterar o valor no momento do cutover não pode encurtar retroativamente todas as respostas em cache. Clientes diferentes podem chegar a destinos diferentes durante a transição. Mantenha o ambiente antigo disponível enquanto as mudanças de roteamento se estabilizam, com uma política deliberada sobre se ele ainda pode aceitar gravações. Evite executar consumidores de fila ou tarefas agendadas duplicados, a menos que a aplicação tenha sido projetada para isso. Monitore as requisições em 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 que as gravações começarem Antes que o novo sistema aceite mudanças, devolver o tráfego pode ser relativamente simples. Depois, uma reversão apenas de DNS pode perder trabalho ou criar dois históricos conflitantes. Defina como os registros e uploads recém-criados seriam preservados ou reconciliados. Se a aplicação não puder mesclá-los com segurança, um período de manutenção controlado pode ser preferível a um retorno improvisado à cópia antiga. Defina as condições que exigem pausar a migração e mantenha o responsável pela decisão acessível. Preserve logs e evidências úteis de acordo com as regras de retenção do projeto. Não exclua a máquina antiga ou 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 rollback. 06 Encerrar a migração com verificações operacionais Após o cutover, verifique backups, alertas, renovação de certificado, trabalho agendado e recuperação de acesso. Confirme que o host monitorado é o novo destino e que nenhuma integração de teste permanece em produção. Revise erros da aplicação e tempos visíveis ao usuário sob tráfego comum. Atualize o inventário e o runbook para que o próximo administrador não precise 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 gerenciada devem ser confirmados para o serviço escolhido. Use o catálogo para selecionar recursos adequados e, em seguida, construa uma mudança testada em torno dos dados da sua aplicação. Uma migração está concluída quando o serviço e seu processo de recuperação funcionam no destino, não simplesmente quando os arquivos foram transferidos. TRANSFORME ISSO EM AÇÃO Sua lista prática. ✓ Inventariar dados, tarefas, segredos e integrações. ✓ Verificar o destino entregue antes de agendar. ✓ Ensaiar com integrações externas seguras. ✓ Definir a consistência do banco de dados e dos uploads. ✓ Planejar a transição de roteamento e a prevenção de tarefas duplicadas. ✓ Especificar o rollback para novas gravações. ✓ Verificar backups e monitoramento após o cutover. Baixar lista PERGUNTAS COMUNS Os detalhes que importam. Posso migrar copiando o diretório da aplicação? + Somente se isso capturar tudo o que o serviço precisa e preservar a consistência. Bancos de dados, uploads, tarefas, segredos e configuração geralmente exigem atenção separada. Reduzir o TTL de DNS torna o cutover instantâneo? + Não. Respostas anteriormente em cache podem permanecer até o fim de seu tempo de vida anterior, e os clientes podem atualizar em momentos diferentes. O rollback é apenas apontar o DNS para o servidor antigo? + Não depois que o novo servidor aceita gravações. Você deve considerar esses registros e arquivos antes de devolver o tráfego. REFERÊNCIAS PRINCIPAIS Vá à fonte. Estas referências apoiam os conceitos técnicos deste guia. Siga a documentação atual antes de alterar um sistema em produção. PostgreSQL: Backup e Restauração www.postgresql.org PostgreSQL: Consistência e restauração de dump 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. Especificações de serviço, opções disponíveis e condições contratuais devem ser verificadas separadamente. CONECTE O CONHECIMENTO Infraestrutura relacionada. Metal Atlas Suíça Metal Zenith Suíça Metal EPYC Suíça MANTENHA O FIO 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 encaixa Entenda o que uma máquina física muda, o que ela não muda e quando ela se torna um passo útil para sua carga de trabalho. 4 min de leitura Leia o guia NOTA DE CAMPO / 02 + Operações do dia dois Aplicado Construa um backup que você realmente possa restaurar Escolha um alvo 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 Construa um orçamento de VRAM para GPU antes de escolher o hardware Considere pesos, ativações, caches e buffers temporários e, em seguida, teste a carga de pico em vez de apenas o arquivo do modelo. 6 min de leitura Leia o guia