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

É uma situação comum, quando o administrador cria o sistema para backup automático e o esquece. Somente depois que um sistema falha nas notificações do administrador, esse sistema de backup foi interrompido antes ou os backups não podem ser restaurados por causa de alguma falha e ele não possui um backup atual para restaurar a partir de ... Então, quais são as práticas recomendadas para evitar essas situações?

Execute exercícios de combate a incêndio ... a cada dois meses, é uma boa idéia dizer que o sistema XYZ está inoperante ... e, na verdade, repita o processo de colocá-lo novamente online em uma nova VM, etc. Isso mantém as coisas honestas e ajuda você a entender erros.

modo soapbox: ON

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

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

Esse também era o trabalho do administrador mais jovem, para que a documentação estivesse atualizada. Junior sendo definido por quanto trabalho ele / ela tinha no sistema específico, em algum momento (na maioria das vezes na verdade) foi o "gerente do grupo" que o fez

Tínhamos hardware especial dedicado a isso (uma Intel e uma caixa IBM / AIX) com baixa especificação para tudo, menos o espaço em disco, pois 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.

Como você parece estar se referindo ao fato de o administrador não perceber que a tarefa de backup "quebra" e não tanto que uma cópia de segurança não funcionou corretamente, sugiro criar algum tipo de script de monitoramento em torno dos backups.

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

• Crie um script para fazer backup de seus dados.
• Execute a restauração de teste para garantir que o script funcione corretamente.
• No script, ou por outros meios, implemente uma maneira de rastrear o status dos backups (êxito, falha, execução, não execução).
• Monitorar esse status de rastreamento (email, banco de dados, algo assim)

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

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

Honestamente, se seus dados são muito importantes para você, seria do seu interesse investir em algum software para gerenciar seus backups para você. Existem centenas de produtos disponíveis para isso, desde o barato e o simples, até a classe corporativa.

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

Temos versões 'Reference' de 60% do tamanho de nossos sistemas de 'Produção', usamos para testes finais de alterações, restauramos backups de 'Produção' para esses sistemas - ele testa o backup e garante que os dois ambientes estejam em sintonia. .

Uma abordagem é criar um script para um trabalho de "recuperação" para executar periodicamente, por exemplo, um que captura um arquivo de texto específico do backup mais recente e envia por e-mail seu conteúdo. Se possível, isso deve ser feito - pelo menos algumas vezes - usando uma caixa diferente daquela que criou ou fez backup dos dados, apenas para garantir que funcione 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 banco de dados, apesar de executar algum tipo de recuperação em pequena escala de um pequeno backup de banco de dados ou de caixa de correio no nível de bloco e verificar se 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 em caso de emergência - apenas permite que você fique um pouco mais confiante sobre a integridade do seu trabalho de backup diário.

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

Quero restaurar o servidor / cluster a partir do zero e depois usá-lo para produção . Nem por um minuto, nem por uma hora, mas permanentemente . Se você afirmar 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 o estágio "parece legal", viva com ele. Faça backup na noite seguinte. Esqueça o original. Você provavelmente vai descobrir algumas falhas usando esta abordagem, e você será forçado a corrigir 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 restaurá-los também.

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

• Faça um ponto que você absolutamente precisa de um orçamento. Em todas as ocasiões, lembre aos tomadores de decisão que um teste válido de restauração ainda não aconteceu. (E sim, colete evidências para cobrir sua bunda. Mundo difícil.)
• Na maioria das organizações, ocasionalmente há uma necessidade comercial de migrar algum sistema para outro hardware, então aproveite a oportunidade. Sempre escolha o método "restaurar do backup" para migração, fingindo que acabou de perder o hardware original. Sim, isso 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 dois testes de restauração (restaure no hardware emprestado, aguarde mais de uma semana, restaure do emprestado para o original, viva com ele). Geralmente, se houver um novo hardware comprado para algum sistema novo e você organizar as coisas corretamente, poderá emprestá-lo facilmente - oferecendo-o 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 você obtém hardware idêntico em caso de desastre real?
• Algum novo sistema está sendo implementado por você no momento? Você pode testar a restauração agora? Não use hardware adicional, apenas substitua o novo sistema, pois você tem um novo conhecimento sobre como reimplementá-lo rapidamente. Isso funciona se ainda não tiver dados significativos. Mais uma vez, vá para produção na versão restaurada, não na versão reinstalada recentemente.

1. Exercícios de incêndio.
2. Uma política de teste de todos os backups a cada 6 meses é uma boa ideia
3. Quando se trata de teste, você precisa examinar cada aplicativo ou sistema que está fazendo backup. Idealmente, o que constitui um backup "bem-sucedido" ou "recuperável" deve ser listado na Descrição do Serviço ou no SOP (documentação operacional) do seu backup, juntamente com outros detalhes, como tempo de retenção, bladibla.

Você provavelmente descobrirá que alguns tipos de backup podem ser facilmente testados para restauração por scripts (como bancos de dados), enquanto outros precisam de alguma entrada manual (restauração do Active Directory). Automatize o máximo possível disso, verifique se há algum tipo de relatório e se "alguém" executa os testes manuais também em intervalos regulares. Um ambiente isolado (cópia reduzida do prod) facilitará a execução de testes de restauração.

Embora não testemos backups, temos o componente centralizado de verificação e geração de relatórios no sistema que desenvolvemos o BackupRadar.com. Sinta-se livre para conferir se isso ajuda com esse componente. Ele anexa uma cópia dos e-mails de êxito / falha à política de backup e também anexa capturas de tela se o seu software de backup também é capaz de enviá-las.

Obrigado Patrick

Verifique se a atividade de backup está registrada e, em seguida, escreva algo (em perl, é claro) que analise os logs que procuram falhas, descreva-os e envie-os como um email diário.