Revisado · Recursos do Hosmio
Antes de começar
Escolha um destino descartável e um escopo de teste por escrito. Confirme o acesso ao código do aplicativo, às versões de software necessárias e ao material de backup aprovado. Mantenha o alvo separado da produção, com notificações de saída, tarefas agendadas e gravações externas desativadas até serem deliberadamente testadas.
01
Liste o que deve migrar e o que deve ser recriado.
Inclua o runtime, banco de dados, arquivos enviados, configuração, tarefas agendadas, certificados, propriedade de DNS e integrações externas. Registre quem controla cada dependência e como o acesso pode ser recuperado se o VPS atual estiver indisponível. Identifique qualquer recurso específico do fornecedor que precise de substituição em vez de uma cópia de arquivo.
Anote as versões e extensões esperadas. Um comando de instalação que obtém o que for mais recente hoje pode não recriar o aplicativo que você opera. Faça referência ao armazenamento protegido de segredos para credenciais; um plano de recuperação deve explicar como uma pessoa autorizada as recupera sem colocar os segredos no próprio plano.
02
Escolha um método de exportação e restauração ciente dos dados.
No PostgreSQL, uma exportação lógica com pg_dump abrange um banco de dados, enquanto objetos globais, como roles, exigem tratamento separado. A ferramenta se recusa a fazer dump de um servidor de versão principal mais nova do que o cliente suporta. A documentação oficial também alerta contra tratar o pg_dump como uma estratégia universal de backup de produção regular. PostgreSQL: pg_dump ↗
Escolha o método adequado à sua aplicação e às suas necessidades de recuperação junto ao seu operador. Registre o que a exportação omite e como os arquivos são mantidos consistentes com as referências do banco de dados. Um comando que retorna com sucesso é uma primeira verificação útil, não a prova de que uma aplicação completa foi preservada.
03
Restaure em um alvo explicitamente separado.
Inspecione o arquivo e o destino antes de restaurar. A restauração de arquivos do PostgreSQL usa pg_restore; opções que limpam objetos existentes podem remover dados, e seu comportamento padrão pode continuar após erros de SQL. Planeje o tratamento de erros e inspecione o resultado em vez de presumir que todos os objetos foram restaurados. PostgreSQL: pg_restore ↗ Não execute um tutorial contra o banco de dados de produção simplesmente porque o nome dele é familiar.
Para backups de arquivos, selecione o snapshot desejado e um destino de teste vazio. A Restic documenta que a restauração pode sobrescrever arquivos existentes; uma sobrescrita interrompida pode deixar um resultado parcial. restic: restaurando a partir do backup ↗ Registre o snapshot de origem e o caminho de destino na nota do exercício. Estas são diretrizes de seleção de método, não comandos executados ou verificados em uma VPS Hosmio.
04
Verifique tarefas do usuário e efeitos colaterais ocultos.
| Verifique | Evidência a reter | Resultado |
|---|---|---|
| A aplicação inicia com as versões documentadas | Inventário de versões e resultado da inicialização | Ainda não testado |
| Registros e arquivos representativos concordam | Verificações de registros sintéticos e anexos | Ainda não testado |
| As permissões se comportam corretamente | Dois papéis de teste e acesso esperado | Ainda não testado |
| Os jobs não enviam trabalho externo duplicado | Ações de saída desabilitadas ou teste controlado | Ainda não testado |
| O operador substituto consegue seguir as notas | Passagem independente e lacunas | Ainda não testado |
Use contas sintéticas e registros de teste inofensivos sempre que possível. Verifique os limites de acesso, bem como as leituras bem-sucedidas. Uma aplicação que inicia mas concede as permissões erradas não é uma recuperação bem-sucedida. Mantenha as verificações com falha no registro, com um responsável pela correção.
05
Planeje o ponto em que novas escritas alteram a decisão.
Um ensaio deve orientar a sequência da movimentação futura: etapa final de consistência, verificações de destino, troca de tráfego, decisão de aceitação e desativação do serviço antigo. Decida quem pode parar ou reverter a operação. Se o destino tiver aceitado novas gravações, enviar os usuários de volta a uma cópia antiga pode perder ou dividir essas gravações; o rollback precisa de um plano de dados, não apenas de uma mudança de DNS.
Considere a sobreposição no orçamento. Pode ser necessário um segundo servidor, armazenamento independente, cobranças de tráfego, licenças e tempo do operador. Não presuma que um fornecedor rateie a VPS nem que os fundos pré-pagos sejam reembolsáveis. Os preços de período publicados pela Hosmio descrevem termos antecipados; eles não definem um serviço de migração ou reembolso.
06
Deixe evidências que outro operador possa usar.
Registre a data do exercício, as versões, os identificadores de cópia, o destino, o esforço decorrido e os resultados somente após o exercício ser realmente realizado. Até então, use “planejado” ou “não testado”. Mantenha a ficha de aceitação junto às notas de recuperação e liste as dependências que ainda impedem uma reconstrução independente.
Se o ensaio falhar, classifique a lacuna: dados ausentes, software incompatível, credenciais indisponíveis, uma dependência externa ou um procedimento pouco claro. Resolva o menor problema bloqueador e repita a verificação afetada. Não chame a aplicação de portátil enquanto uma tarefa crítica permanecer não testada.
Conecte o plano a responsabilidades operacionais nomeadas e o processo de aprovação de mudanças do cliente. O resultado pretendido é uma capacidade demonstrada de recuperar dentro de um escopo documentado, não uma promessa de zero interrupção ou uma migração entregue automaticamente.