ti-enxame.com

Melhores práticas para verificação de backup?

É uma situação comum, quando o administrador faz sistema de backup automático e esquece. Somente depois que um sistema falha avisos de administrador, esse sistema de backup quebrou antes ou os backups são sem restrições por causa de alguma falha e ele não tem backup atual para restaurar ... Então, quais são as melhores práticas para evitar tais situações?

21
Kazimieras Aliulis

Executar brocas de incêndio ... a cada par de meses é uma boa ideia dizer que o sistema XYZ está para baixo ... então, na verdade, passar pelos movimentos de trazê-lo de volta on-line para um novo VM etc etc . Isso mantém as coisas honestas e ajudam você a pegar erros.

27
trent

modo de caixa de sabão: em

Eu diria que é tão simples que os backups que não são testados regularmente é inútil.

Um meu trabalho anterior, tivemos uma política que todos os sistemas (produção, teste, monitoramento de desenvolvimento etc.) devem ser testados a cada 6 meses.

Este também foi o trabalho do administrador mais júnior para que a documentação estava atualizada. Júnior sendo definido por quanto trabalho ele/ela tinha don no sistema específico, em algum momento (muitas vezes realmente) foi o "gerente de grupo" que fez isso

Tivemos hardware especial dedicado a isso (uma caixa Intel e uma IBM/AIX) que foi baixa especificação para tudo, mas não precisamos correr nada real no hospedeiro restaurado.

Muito trabalho, o primeiro par de rodadas, mas nos levou a agilizar o processo de restauração que é a parte importante do backup.

10
Mr Shark

Como você parece se referir ao fato de que o administrador não percebe que o trabalho de backup "quebra", e não tanto que um backup de trabalho não funcionou direito, eu sugeriria construir algum tipo de scripts de monitoramento em torno dos backups.

Ao construir uma solução de backup em casa, eu faria algo assim:

  • Construa um script para fazer backup de seus dados.
  • Realize restauração de teste para garantir que o script funcione corretamente.
  • No script, ou através de alguns outros meios, implemente uma maneira de rastrear o status dos backups (sucesso, falha, correu, não funcionou).
  • Tem esse status de rastreamento monitorado (e-mail, banco de dados, algo)

Uma vez que tudo isso é feito, você deve estar bem. Uma coisa extra a fazer seria realizar restaurações regulares de teste. Se você tem hardware extra para doar para a causa que é.

Onde trabalho temos um local quente, uma vez por mês, escolhemos aleatoriamente um sistema ou banco de dados e vemos para o nosso local quente e realizamos um exercício de restauração de teste no metal desencapado para garantir a capacidade de recuperar nossos dados.

Honestamente, se vocês dados forem muito importantes para você, seria de seu interesse investir em algum software para gerenciar seus backups para você. Há centenas de produtos para isso, a partir do barato e simples, à classe empresarial.

Se você estiver confiando em um conjunto de scripts escritos à mão em execução no crontab para os backups de suas empresas, mais cedo ou mais tarde você provavelmente será queimado.

7
WerkkreW

Temos 60% - versões de 'referência' de nossos sistemas de "produção", usamos-os para testes finais de alterações, restauramos os backups de 'produção' para esses sistemas - Testes que o backup mais garante que ambos os ambientes estejam em sintonia entre si .

4
Chopper3

Ao realizar a restauração do teste, não me sinto confortável no ponto "Parece bom, os arquivos são restaurados, parece que nenhum arquivo está faltando, até mesmo os tamanhos correspondem", ou no ponto "isso parece bom, comecei a minha inscrição. .. não falha, exibe alguns dados decentes ".

Eu quero restaurar o servidor/cluster a partir do zero e, em seguida, para realmente usá-lo para produção. Não por um minuto, não por uma hora, mas permanentemente. Se você reivindicar que sua restauração foi bem sucedida, então não há absolutamente nenhuma razão para não iniciar uma produção. Este não é um sistema "sujo", que deve ser esquecido. Este é o sistema que você enfrentará depois de um verdadeiro desastre. Então, se passa "parece bom", viva com ele. De volta na próxima noite. Esqueça o original. Você provavelmente Will descobrir algumas falhas usando essa abordagem e você será forçado a consertar todos eles. A próxima restauração do mesmo sistema tem uma chance decente de ser 100% bem sucedida.

Isso inclui seu software e servidor de backup. Sim, você precisa restaurar isso também.


Não tem orçamento para comprar hardware dedicado para restauração?

  • Faça questão de que você absolutamente precisa de um orçamento. Em todas as ocasiões, lembre-se dos tomadores de decisão que um teste de restauração válido ainda não aconteceu. (E sim, reunir as evidências para cobrir sua bunda. Mundo resistente)
  • Na maioria das organizações, ocasionalmente, uma empresa precisa migrar algum sistema para outro hardware, então use a oportunidade. Sempre escolha o método "restaurar do backup" para migração, fingindo que você acabou de perder o hardware original. Sim, significa mais tempo de inatividade, desculpe por isso. Pelo menos você terá confiança de que seu backup é útil.
  • Nenhuma migração? Talvez você possa emprestar algum hardware por duas semanas e realizar dois testes de restauração (restauração para hardware emprestado, espere mais de uma semana, restaurar de emprestado ao original, viva com ele). Normalmente, se houver um novo hardware comprado para algum novo sistema e você organizará as coisas corretamente, você pode facilmente pedir emprestá-lo - oferecendo para testá-lo exaustivamente por duas semanas. Se o novo hardware não for 100% idêntico ao antigo, isso tornará o seu teste ainda melhor. Como você sabe se você tem hardware idêntico em caso de desastre real?
  • Qualquer novo sistema está sendo implementado por você no momento? Você pode testar a restauração agora? Não use hardware adicional, basta sobrescrever o novo sistema, pois você tem um novo conhecimento como implementá-lo rapidamente. Isso funciona se ainda não tiver dados significativos. Mais uma vez, vá para a produção na versão restaurada, não na versão recém-instalada.
1
kubanczyk
  1. Exercícios contra incêndio.
  2. Uma política de testar todos os backups a cada 6 meses é uma ideia muito boa
  3. Quando se trata de testar, você precisa analisar cada aplicativo ou sistema seu backup. Idealmente, o que constitui um backup "bem-sucedido" ou "recuperável" deve ser listado na descrição do serviço ou SOP (documentação operacional) para o seu backup, juntamente com outros detalhes, como tempo de retenção, Bladibla.

Você provavelmente descobrirá que alguns tipos de backup podem ser facilmente testados por scripts (como bancos de dados), enquanto outros precisam de alguma entrada manual (Restauração do Active Directory). Automatize o máximo que puder disso, certifique-se de que algum tipo de relatório esteja no lugar, e certifique-se de "alguém" executa os testes manuais em intervalos regulares também. Um ambiente isolado (cópia do downscaled do Prod) facilitará a realização de testes de restauração.

1
Trondh

Uma abordagem é script um trabalho de "recuperação" para ser executado periodicamente, por exemplo, que pegue um arquivo de texto específico do backup mais recente e envie seu conteúdo. Se for possível, isso deve - pelo menos às vezes - ser feito usando uma caixa diferente da que criada ou backup dos dados, apenas para garantir que funcione se você precisar fazer isso. A vantagem é que você pode ter certeza de que suas criptografia/descriptografia, compressão e mecanismos de armazenamento estão funcionando.

Isso é um pouco mais envolvido para backups especializados, como servidores de e-mail e banco de dados, embora realizando algum tipo de recuperação de pequena escala de um pequeno backup de caixa de correio de DB ou nível de tijolo e verificando o conteúdo é certamente possível, apenas um pouco mais envolvido.

Essa abordagem também não deve substituir uma restauração completa periódica para garantir que você possa recuperar dados no caso de uma emergência - apenas permite que você seja um pouco mais confiante sobre a integridade do seu trabalho de backup do dia-a-dia.

1
nedm

Enquanto não testamos backups, temos a verificação de backup centralizada e o componente de relatórios no sistema que desenvolvemos BackUpradar.com. Sinta-se à vontade para verificar se isso ajuda com esse componente. Ele anexa uma cópia dos e-mails de sucesso/falha à diretiva de backup e ele também anexará screenshots se o software de backup também for capaz de enviar aqueles também.

Obrigado, Patrick.

0
Patrick Leonard