Práticas recomendadas para verificação de backup?

21

É uma situação comum, quando o administrador cria um sistema para backup automático e esquece-o. Somente após um sistema falhar, o sistema de backup quebrou antes ou backups são inacessíveis por causa de alguma falha e ele não tem backup atual para restaurar a partir de ... Então, quais são as melhores práticas para evitar tais situações ??

    
por Kazimieras Aliulis 06.05.2009 / 00:29

9 respostas

27

Execute simulações de fogo ... a cada dois meses é uma boa idéia dizer que o sistema XYZ está inativo ... então, na verdade, é necessário voltar a colocá-lo online em uma nova VM, etc etc. Ele mantém as coisas honestas e ajuda a detectar erros.

    
por 06.05.2009 / 00:33
10

modo de caixa de sabão: ON

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

Em meu trabalho anterior, tínhamos uma política para que todo sistema (produção, teste, monitoramento de desenvolvimento etc.) fosse restaurado a cada 6 meses.

Este também era o trabalho do administrador mais jovem, de modo que a documentação estava atualizada. Junior sendo definido por quanto trabalho ele fez no sistema específico, em algum momento (quase sempre na verdade) foi o "gerente do grupo" que fez isso

Tínhamos um hardware especial dedicado a isso (uma caixa da Intel e outra da IBM / AIX) que tinha pouca especificação para tudo, exceto espaço em disco, já que não precisávamos executar nada real no host restaurado.

Muito trabalho nas primeiras rodadas, mas isso nos levou a otimizar o processo de restauração, que é a parte importante do backup.

    
por 14.05.2009 / 13:55
7

Como você parece estar se referindo ao fato de que o administrador não percebe que o trabalho de backup "quebra", e nem que um backup funcional funcionou corretamente, sugiro que você crie algum tipo de script de monitoramento os backups.

Ao criar uma solução de backup doméstica, eu faria algo assim:

  • Crie um script para fazer backup de seus dados.
  • Realize a restauração do teste para garantir que o script funcione corretamente.
  • No script, ou por outros meios, implemente uma maneira de rastrear o status dos backups (sucesso, falha, execução, execução).
  • Tenha esse status de rastreamento monitorado (email, banco de dados, algo)

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

Onde eu trabalho, temos um warm-site, uma vez por mês escolhemos aleatoriamente um sistema ou banco de dados e acessamos nosso aquecido site e realizamos um exercício de restauração de testes em metal puro para garantir a capacidade de recuperar nossos dados.

Honestamente, se os dados forem muito importantes para você, seria interessante investir em alguns softwares para gerenciar seus backups para você. Existem centenas de produtos por aí, desde os mais baratos e simples até os de classe empresarial.

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

    
por 13.05.2009 / 18:53
4

Temos versões de 'Tamanho' de 60% de nossos sistemas de 'Produção', os usamos para testes finais de alterações, restauramos backups de 'Produção' para esses sistemas - testa o backup e garante que ambos os ambientes estejam em andamento uns com os outros.

    
por 06.05.2009 / 00:37
1

Uma abordagem é roteirizar uma tarefa de "recuperação" para ser executada periodicamente, por exemplo, uma que capture um arquivo de texto específico do backup mais recente e envie por e-mail seu conteúdo. Se for possível, isso deve - pelo menos às vezes - ser feito usando uma caixa diferente daquela que criou ou fez o backup dos dados, apenas para garantir que funcionará se você precisar fazer isso. A vantagem é que você pode ter certeza de que seus mecanismos de criptografia / descriptografia, compactação e armazenamento estão funcionando.

Isso é um pouco mais complicado para backups especializados, como servidores de e-mail e bancos de dados, embora seja possível recuperar algo em pequena escala de um banco de dados pequeno ou em um nível de bloco e verificar o conteúdo é certamente possível. 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ê tenha um pouco mais de confiança sobre a integridade do seu trabalho de backup diário .

    
por 11.05.2009 / 08:30
1
  1. exercícios de incêndio.
  2. Uma política para testar todos os backups a cada 6 meses é uma boa ideia
  3. Quando se trata de teste, você precisa examinar cada aplicativo ou sistema de backup. Idealmente, o que constitui um backup "bem-sucedido" ou "recuperável" deve estar listado na Descrição do serviço ou no SOP (documentação operacional) do backup, junto 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, verifique se algum tipo de relatório está em vigor e certifique-se de que "alguém" realize os testes manuais em intervalos regulares também. Um ambiente isolado (cópia reduzida do prod) facilitará a execução do teste de restauração.

    
por 18.10.2013 / 12:05
0

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

Eu quero restaurar o servidor / cluster do zero e usá-lo para produção . Nem por um minuto, nem por uma hora, mas permanentemente . Se você alegar que sua restauração foi bem-sucedida, 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á após um desastre real. Então, se passar do estágio "parece legal", viva com isso. Faça o backup na noite seguinte. Esqueça o original. Você provavelmente irá descobrir alguns problemas usando essa abordagem, e você será forçado a consertar todos eles . A próxima restauração do mesmo sistema tem uma boa chance de ser 100% bem-sucedida.

Isso inclui seu software de backup e servidor. Sim, você precisa restaurá-los também.

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

  • Deixe claro que você precisa de um orçamento. Em todas as ocasiões, lembre aos tomadores de decisão que um teste de restauração válido e completo ainda não aconteceu. (E sim, junte as evidências para cobrir o seu traseiro. Mundo difícil.)
  • Na maioria das organizações, ocasionalmente, é necessário que uma empresa migre algum sistema para outro hardware, portanto, aproveite a oportunidade. Escolha sempre o método "restaurar a partir 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á certeza de que seu backup é útil.
  • Sem migração? Talvez você possa emprestar algum hardware por duas semanas e executar duas restaurações testes (restaure ao hardware pedido, espere mais de uma semana, restaure do emprestado ao original, viva com ele). Normalmente, se há um novo hardware adquirido para algum novo sistema e você organiza as coisas corretamente, você pode facilmente emprestá-lo - oferecendo-se para testá-lo exaustivamente por duas semanas. Se o novo hardware não for 100% idêntico ao antigo, isso tornará seu teste ainda melhor. Como você sabe se obtém 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, apenas sobrescreva o novo sistema, pois você tem novos conhecimentos sobre como reimplementá-lo rapidamente. Isso funciona se ainda não tiver dados significativos. Novamente, vá para a produção na versão restaurada, não na versão recém-reinstalada.
por 16.06.2009 / 00:42
0

Apesar de não testarmos os backups, temos o componente centralizado de verificação e relatório de backup 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 à política de backup e também anexará capturas de tela se o software de backup também for capaz de enviá-las.

Obrigado Patrick

    
por 30.09.2015 / 21:28
-1

Certifique-se de que a atividade de backup está registrada e, em seguida, escreva algo (em perl, é claro) que analise os logs que estão procurando falhas, destile-as e envie-as como um email diário.

    
por 06.05.2009 / 00:37