Cliffhanger: Os backups estão corretos… aqui… certo?

28

No meu trabalho, os backups têm uma prioridade surpreendentemente baixa. A estratégia de backup foi implementada há algum tempo e, desde então, supõe-se que os backups estejam bem. Se você perguntar aos administradores, eles dirão que tudo foi feito em backup.

Mas, quando você solicita um backup específico, metade do tempo eles não estão lá:

  • O disco ficou cheio
  • A fita falhou
  • Parece que alguém desativou o trabalho de backup
  • A conexão de rede teve tempo de inatividade
  • Pedimos esse disco anos atrás, mas o departamento financeiro não aprovou o pedido de compra
  • Os arquivos estão corrompidos
  • Arquivo contém banco de dados incorreto
  • Apenas backups de log de transações (inúteis sem um completo)

Algumas semanas atrás, o desastre chegou bem perto, já que um dos servidores perdeu muitos discos de ataque. Felizmente, um disco ainda era gentil o suficiente para copiar os dados, se você tentasse várias vezes.

Mas mesmo depois desse quase desastre, não consigo convencer os administradores a melhorar a situação. Então estou me perguntando, alguma dica para abrir os olhos das pessoas? Parece-me que estamos andando na beira de um penhasco.

    
por Andomar 16.05.2009 / 15:18

7 respostas

24

Você sempre precisa consertar essas coisas de cima para baixo.

A atual estratégia de backup é apoiada e entendida pela gerência? Se não, é inútil.

A gerência executiva precisa saber sobre os problemas e quais riscos estão envolvidos (perder dados financeiros que você precisa trazer legalmente para sobreviver, ou dados de clientes que levaram anos para coletar?) e pesar isso na decisão sobre ações, ou decidir deixar alguém (como você) agir.

Se você não puder chegar à gerência, experimente controladores de negócios ou outras posições financeiras em que a recuperação de dados e sua integridade sejam de grande importância para os relatórios da empresa. Eles, por sua vez, podem "iniciar a tempestade" se necessário ...

    
por 16.05.2009 / 15:32
14

Por onde começar? Isso é um desastre esperando para ocorrer. Uma função de trabalho principal de Sysadmins é garantir o backup e a recuperação de dados. Tudo o mais é secundário. Não, se não é, mas é.

Aqui estão algumas coisas que você pode fazer:

  1. Rastreie KPIs para restaurações. Deve ser possível produzir um relatório mostrando quantas solicitações de restauração foram bem-sucedidas. Qualquer coisa menor que 100% deve ser investigada minuciosamente. Relatórios de amor de gestão e esta é uma evidência difícil.

  2. Deve haver procedimentos documentados para todas as operações de backup e restauração, incluindo todos os sistemas e sua estratégia de backup, rotações de fita, agendamentos, caminhos de escalonamento, restaurações de teste, etc. Peça para vê-los.

  3. Fale com o gerente dos administradores do sistema e expresse suas preocupações. Vá armado com a prova de que as restaurações não estão funcionando. Se nenhuma alegria for maior.

Sério, faça barulho. Coisas assim podem destruir uma empresa.

    
por 16.05.2009 / 16:09
5

Propor (no mínimo) testes anuais de recuperação de desastres. O trabalho necessário para executar com sucesso o teste deve revelar falhas.

    
por 16.05.2009 / 19:27
5

Onde eu trabalho, temos um departamento de TI muito bom, todos os anos eles se reúnem em todos os escritórios da Europa e fazem uma 'restauração festiva' em servidores alugados em um datacenter, simulando efetivamente o que aconteceria se o pessoal viesse trabalhar um dia e encontrou o escritório queimado durante a noite.

Pegue o grande chefe envolvido, lembre-o de que, se um desastre acontecer, ele não terá mais um bônus naquele ano (ou pior!) e talvez seja prudente organizar um exercício semelhante de recuperação de desastre. Não deve demorar muito ou custar muito - os administradores são mandados embora com fitas de backup externas e informados para criar um ambiente de escritório idêntico a eles.

Depois, sente-se e veja a TI melhorar - assim que a gerência perceber que os dados da empresa estão perigosamente perto de ficarem permanentemente perdidos, surgem faíscas (dos foguetes que serão colocados estrategicamente nos administradores)

    
por 03.06.2009 / 21:42
4

É fácil culpar os administradores - no entanto, Oskar está certo: essas coisas são dirigidas de cima para baixo. Se a gerência não gastar dinheiro para fazer backups uma prioridade, então os administradores de sistemas geralmente estão sem sorte e fazem o melhor que podem com os recursos que possuem.

A chave, se você é um desses administradores infelizes - e eu tenho estado neste barco para alguns compromissos com clientes - é que você garante que a gestão seja informada, repetidamente, e de forma confirmada, que isso é um risco para o negócio.

Minha estratégia é criticar constantemente os problemas. Se você fizer isso, às vezes os problemas serão resolvidos, mas é principalmente para que qualquer pessoa que eu relate não possa se esconder atrás da desculpa "Eu nunca fui informado". Como consultor, geralmente posso ir melhor. Posso fazer meus chefes informarem mais a gerência sênior do que eu que existe uma vulnerabilidade. Isso espalha a culpa, ou pelo menos se concentra em um nível maior do que eu.

Ao mesmo tempo, você precisa ser criativo e trabalhar duro para minimizar os riscos com quaisquer recursos que o cliente possa fornecer.

Embora em alguns casos os administradores possam ser culpados, a gerência é sempre responsável: por conhecer o risco e não fazer o suficiente para mitigá-lo, ou contratar pessoas que não os alertam para esses riscos.

    
por 07.06.2009 / 05:40
3

Eu sou responsável por cerca de 200 servidores espalhados por todo o noroeste do Reino Unido, e isso é obviamente muito para verificar manualmente.

Configurei o backup para que, na conclusão, ele execute um script (VBScript) que examine o log de backup, determine se o backup funcionou ou não e grave um registro em um banco de dados central com o resultado do backup. Em seguida, na matriz, eu executo um script que consulta esse banco de dados e me apresenta uma lista de sites em que o backup relatou um erro ou não havia nenhum relatório do site.

O resultado final é que, quando me sento na minha mesa, tenho uma lista de todos os sites em que preciso verificar o backup.

O ponto de tudo isso é que a suposição padrão é que o backup falhou, e o backup é considerado como tendo funcionado apenas se o meu VBScript não detectou nenhum erro e escreveu esta conclusão para o meu banco de dados. Isso garante que falhas de backup não passem despercebidas.

Alguns dos servidores usam o Backup Exec, alguns NTBackup e alguns apenas copiam seus arquivos para outro servidor na rede. Não importa o tipo de backup que os servidores fazem, pois é fácil ajustar meu VBScript para verificar se há erros. Meu script é realmente muito básico, ele apenas abre o relatório de backup como um arquivo de texto e greps para frases como "falhou em montar", "fita cheia", "erro CRC" etc, etc. Tenho certeza que um programador profissional faria um trabalho mais vago. No entanto, a coisa toda é simples e robusta, e é proativa no sentido de que vejo a falha do backup reportar se quero ou não, e só deixaria de perceber um erro se eu conscientemente decidir ignorar o relatório.

JR

PS 99% das falhas de backup são porque os usuários se esqueceram de alterar a fita de backup. Você não ama apenas lusers: -)

    
por 17.05.2009 / 09:51
2

Um backup que não foi testado não é nenhum backup.

    
por 17.05.2009 / 10:12