Defina a perda de dados aceitável e o tempo de recuperação, mantenha uma cópia independente consistente e teste a restauração da aplicação real em isolamento. Uma tarefa de cópia de segurança concluída ou uma verificação de integridade, por si só, não provam que todas as dependências necessárias à recuperação estão presentes.
Comece pela recuperação de que necessita
Um plano de cópia de segurança começa com duas perguntas práticas: quanto trabalho recente poderia perder e quanto tempo poderia o serviço permanecer indisponível? Essas respostas determinam o calendário, os dados a incluir e o método de restauração. Uma cópia diária pode servir um site raramente alterado, mas deixar um intervalo demasiado grande para uma aplicação movimentada.
Liste o que faz o serviço funcionar, não apenas a sua pasta maior. Os dados da aplicação, o conteúdo da base de dados, a configuração, os ficheiros carregados e as informações necessárias para reconstruir o ambiente podem ser todos importantes. Mantenha um inventário privado de dependências e chaves de recuperação. A cópia de segurança deve suportar um sistema funcional, não apenas produzir um arquivo cujo propósito é esquecido.
Mantenha uma cópia fora do limite de falha
Um segundo diretório na mesma máquina pode ajudar a recuperar uma edição errada, mas continua exposto à perda dessa máquina. As capturas de estado locais podem ser valiosas para reversão rápida e ainda exigem uma cópia independente para incidentes mais amplos. Escolha um destino de recuperação separado e decida que acesso deve poder ler, escrever ou remover a cópia de segurança.
Se as credenciais de produção puderem eliminar todas as cópias de recuperação, uma conta de aplicação comprometida pode derrotar toda a estratégia. Separe o acesso sempre que possível e proteja as credenciais de armazenamento. A encriptação ajuda a proteger o conteúdo armazenado, mas o processo de recuperação também depende de manter a sua chave em segurança fora do ambiente danificado.
Capture um estado consistente da aplicação
Copiar ficheiros de base de dados abertos sem um método adequado pode capturar um estado inutilizável. Utilize uma abordagem de cópia de segurança suportada pela aplicação ou base de dados e compreenda se requer uma captura de estado consistente, uma exportação lógica ou uma breve pausa nas escritas. Coordene os dados relacionados para que um diretório de carregamentos e as suas referências na base de dados descrevam o mesmo ponto no fluxo de trabalho.
Documente as exclusões deliberadamente. As caches e os ficheiros de compilação temporários podem ser reproduzíveis; os carregamentos dos clientes normalmente não são. Reveja a lista após adicionar uma funcionalidade ou mover um diretório. Uma tarefa de cópia de segurança bem-sucedida não pode preservar um caminho que nunca foi incluído.
Teste a restauração num ambiente isolado
Restaure dados representativos para um local separado e verifique se abrem corretamente. Para uma aplicação, teste o serviço recuperado, bem como os ficheiros. Desative o correio eletrónico de saída, as tarefas agendadas e as integrações externas no ambiente de teste para que o ensaio não atue sobre utilizadores reais nem duplique tarefas de produção.
As verificações de integridade do repositório e um teste de restauro respondem a perguntas diferentes. Uma ferramenta pode verificar as estruturas e os dados armazenados enquanto a aplicação continua a precisar de configuração em falta ou de uma chave esquecida. Registe quanto tempo a recuperação demora, que passos manuais são necessários e onde o procedimento precisa de melhorias. Repita o exercício após alterações significativas.
Um cenário prático: ensaiar a recuperação antes do lançamento
Considere uma aplicação com uma base de dados, carregamentos de utilizadores e um pequeno conjunto de ficheiros de configuração privados. O proprietário cria um inventário de recuperação e escolhe um método de consistência suportado pela base de dados. Um destino de cópia de segurança separado armazena as cópias necessárias, enquanto a chave de recuperação é mantida fora da máquina de produção. O primeiro teste começa com um ambiente isolado vazio, para que dependências ocultas não possam ser emprestadas do servidor em funcionamento.
O proprietário restaura os dados e a configuração e, em seguida, verifica o início de sessão, um registo representativo e um ficheiro carregado. O correio eletrónico de saída, as tarefas agendadas e as ações externas permanecem desativados durante o ensaio. Se a base de dados arrancar mas faltar um caminho de carregamento ou um segredo, o teste encontrou uma lacuna que uma tarefa de arquivo bem-sucedida não revelaria. O proprietário corrige o inventário e repete a verificação de recuperação afetada.
Por fim, o proprietário registra o tempo de restauração e os passos manuais. O agendamento e a política de retenção são comparados com a quantidade de trabalho recente que poderia ser perdida e com o tempo que o serviço poderia permanecer indisponível. Estas são decisões específicas do projeto e não garantias fornecidas por um rótulo de armazenamento. Um procedimento testado torna uma cópia de segurança opcional ou um produto de armazenamento útil como parte de uma estratégia de recuperação mais ampla.
| Evidência de recuperação | O que verifica | Questão pendente |
|---|---|---|
| Tarefa de cópia de segurança concluída | A tarefa reportou sucesso | Foram incluídos todos os caminhos necessários? |
| Verificação de integridade do repositório | Verificações das estruturas ou dos dados armazenados | A aplicação tem todas as dependências? |
| Restauro isolado da aplicação | Uma recuperação representativa funciona | O tempo observado cumpre o seu objetivo? |
Torne a falha visível e a retenção intencional
Uma cópia de segurança que para silenciosamente é uma surpresa futura. Monitorize a conclusão das tarefas, a capacidade disponível e a idade do ponto de recuperação utilizável mais recente. Mantenha histórico suficiente para recuperar de um problema descoberto mais tarde e compreenda como a limpeza afeta esse histórico. Reveja as operações de eliminação com cuidado, porque erros de retenção podem remover a única versão útil.
Leia o âmbito de qualquer opção de cópia de segurança no serviço SwissOctet escolhido e confirme o processo de restauração. O Vault Storage pode ser considerado como um componente de capacidade, mas um produto de armazenamento por si só não é uma política de recuperação completa. Decida o que precisa de restaurar, mantenha a cópia independente e comprove o procedimento antes que o serviço se torne crítico.
A sua lista de verificação prática.
- Defina a perda de dados e o tempo de recuperação aceitáveis.
- Inclua bases de dados, carregamentos e informações de reconstrução.
- Mantenha uma cópia independente e chaves de recuperação separadas.
- Restaure em isolamento e teste a aplicação.
- Monitorize a idade, a capacidade e a retenção das cópias de segurança.
Os detalhes que importam.
Um segundo diretório no mesmo servidor é uma cópia de segurança independente?+
Não. Continua exposto à perda desse servidor, embora possa ajudar a recuperar um erro local.
Uma verificação de integridade substitui um ensaio de restauro?+
Não. Um repositório válido pode ainda omitir configuração, chaves ou dados exigidos pela aplicação.
Porque desativar as integrações durante um teste de restauro?+
Para impedir que o ambiente de teste envie correio eletrónico a utilizadores reais, repita tarefas ou desencadeie ações de produção.
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.
- restic: Restaurar a partir de cópia de segurança restic.readthedocs.io
- restic: Trabalhar com repositórios restic.readthedocs.io
- PostgreSQL: Cópia de segurança e restauro www.postgresql.org
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.