Cliffhanger: Os backups estão certos ... aqui ... certo?

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

Mas então, quando você pede 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 a tarefa de backup
• A conexão de rede teve tempo de inatividade
• Nós pedimos esse disco anos atrás, mas as finanças não aprovaram o pedido de compra
• Os arquivos estão corrompidos
• O arquivo contém o banco de dados errado
• Apenas backups de log de transações (inúteis sem um completo)

Algumas semanas atrás, o desastre chegou bem próximo, pois um dos servidores perdeu muitos discos RAID. Felizmente, um disco ainda teve a gentileza de copiar os dados, se você tentasse várias vezes.

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

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

A estratégia de backup atual é apoiada e compreendida pelo gerenciamento? Caso contrário, é inútil.

A gerência executiva precisa saber sobre os problemas e quais riscos estão envolvidos (perda de dados financeiros que você precisa apresentar legalmente para sobreviver ou dados de clientes que levaram anos para serem coletados?) E ponderar isso ao decidir sobre ações ou decidir sobre deixando alguém (como você) agir.

Se você não conseguir chegar ao gerenciamento, tente controladores de negócios ou outras posições financeiras nas quais a recuperação de dados e sua integridade sejam de grande importância para os relatórios da empresa. Eles, por sua vez, podem "começar a tempestade", se necessário ...

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

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

1. Acompanhe KPIs para restaurações. Deve ser possível produzir um relatório mostrando quantas solicitações de restauração foram bem-sucedidas. Qualquer coisa abaixo de 100% deve ser investigada minuciosamente. A gerência adora relatórios e isso é uma evidência concreta.

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 escalação, restaurações de teste etc. Peça para vê-los.

3. Fale com o gerente dos administradores do sistema e manifeste suas preocupações. Fique armado com a prova de que as restaurações não estão funcionando. Se nenhuma alegria for mais alta.

Sério - dê um alarido. Coisas assim podem destruir uma empresa.

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

Onde trabalho, temos um departamento de TI muito bom; todos os anos, eles se reúnem em todos os escritórios da Europa e realizam um 'festival de restauração' nos servidores alugados em um datacenter, simulando efetivamente o que aconteceria se a equipe viesse trabalhar um dia e encontrasse o escritório havia queimado durante a noite.

Envolva o grande chefe, lembre-o de que, se o desastre acontecesse, ele ficaria sem bônus naquele ano (ou pior!) E, portanto, talvez fosse 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 suas fitas de backup externas e instruídos a criar um ambiente de escritório idêntico a eles.

Em seguida, sente-se e observe a TI melhorar - uma vez que a gerência perceba que os dados da empresa estão perigosamente perto de serem perdidos permanentemente, faíscas voam (dos foguetes que serão estrategicamente colocados nos referidos administradores)

É fácil culpar os administradores - no entanto, Oskar tem razão: essas coisas são expulsas do topo. Se a gerência não gastar dinheiro para fazer dos backups uma prioridade, os administradores do sistema geralmente não têm sorte e fazem o melhor possível com os recursos que possuem.

A chave, se você é um daqueles administradores infelizes - e eu já estive neste barco para alguns compromissos com clientes - é garantir que o gerenciamento seja informado, repetidamente e de maneira confirmada por uma trilha de papel, um risco para os negócios.

Minha estratégia é martelar constantemente os problemas. Se você fizer isso, às vezes os problemas serão resolvidos, mas é principalmente para quem quer que eu reporte não possa se esconder atrás da desculpa "nunca fui informado". Como consultor, geralmente posso melhorar. Posso fazer com que meus chefes informem mais a gerência sênior do que eu que existe uma vulnerabilidade. Isso espalha a culpa, ou pelo menos a concentra em um nível mais alto 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: seja conhecendo o risco e não fazendo o suficiente para mitigá-lo, ou contratando pessoas que não os alertam sobre esses riscos.

Sou responsável por cerca de 200 servidores espalhados pelo noroeste do Reino Unido, e isso é obviamente demais para verificar manualmente.

Eu configuro o backup para que, após a conclusão, execute um script (VBScript) que analise o log de backup, verifique 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 sede, executo um script que consulta esse banco de dados e me apresenta uma lista de sites nos quais o backup relatou um erro ou não havia nenhum relatório do site.

O resultado final é que, quando me sento em 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 considera-se que o backup funcionou apenas se meu VBScript não detectou nenhum erro e escreveu esta conclusão no meu banco de dados. Isso garante que as falhas de backup não sejam despercebidas.

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

JR

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

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