restauração

Quando a restauração de backup falha

Já aconteceu da sua restauração de backup falhar?

Se sim, o sentimento de culpa por esse acontecimento é enorme.

Afinal, se uma cópia de segurança não puder ser restaurada quando precisamos, há grandes chances de que determinados dados serão permanentemente perdidos. 

Segundo o relatório da Veeam (Data Protection Report) de 2021, sobre a proteção de dados, cerca de um terço (34%) de todas as restaurações de dados, realizadas ao longo de 2020, não puderam ser completadas ou falharam em atingir o SLA esperado.  

Outro dado importante colhido pelo estudo é que 37% dos backups realizados apresentaram falhas ou não foram completados dentro da janela estabelecida. 

Podemos concluir que, seja por não ter um backup válido disponível ou por falhas na conclusão do processo de restauração, em mais da metade das situações nas quais uma restauração for necessária, ela não foi possível. 

Em um mundo em que os dados têm se tornado o novo petróleo, o impacto financeiro direto é apenas uma das variáveis a serem avaliadas, uma vez que esta situação pode resultar em danos irreversíveis para a imagem de uma empresa e minar a confiança dos clientes na própria.  

Pensando nisso, relacionamos a seguir as causas mais frequentes de incidentes de falhas de restauração e como a SManager pode lhe ajudar.

Quais as causas dessas falhas de restauração? 

Muitas podem ser as causas de uma falha de restauração.  

O problema pode até ser causado por uma combinação de vários fatores aparentemente irrelevantes quando analisados individualmente, ou por simples falta de experiência ou conhecimento na ferramenta de backup utilizada, que resulte em uma proteção incompleta ou ineficiente dos dados.  

Falhas associadas ao Hardware 

Corrupções de dados silenciosas podem ser causadas por erros de hardware, após interrupções abruptas no fornecimento de energia elétrica, falhas nos caches ou outros problemas mecânicos como o velho conhecido “bit rot”, que pode comprometer determinados blocos de dados armazenados em disco e torná-los ilegíveis, sem qualquer aviso. 

E da mesma maneira que esses eventos ameaçam os dados produtivos, os repositórios de backup baseados em disco, sejam eles quais forem, também podem ser afetados.  

Técnicas de redundância baseadas em RAID e verificações de integridade podem ajudar a mitigar o problema, mas a recomendação mais efetiva é empregar a regra 3-2-1, que consiste em manter ao menos 3 cópias dos dados, sendo uma original e 2 de backup, devendo estas últimas estarem armazenadas em mídias distintas, independentes uma da outra, e sendo 1 destas cópias enviada para outra localidade.  

Falhas decorrentes de erros de firmware 

Essa é válida quando o local de armazenamento dos backups é um equipamento do tipo appliance, uma vez que o firmware deles geralmente oferece um tratamento “inteligente” dos dados armazenados para otimizar o consumo de espaço por meio de desduplicação, ou técnicas equivalentes.  

Uma vez aplicada a desduplicação, especialmente quando esta é global entre todo o conteúdo armazenado, passa-se a depender-se de um conjunto limitado de blocos de dados para se recuperar uma grande quantidade de servidores.  

Um conjunto de blocos que façam referência a dados de um sistema operacional comum a 300 servidores do ambiente, por exemplo, pode ter uma única cópia armazenada no appliance.  

E no caso dessa cópia sofrer uma corrupção, os backups dos 300 servidores serão comprometidos simultaneamente.  

O pior é que esse tipo de situação pode passar desapercebido por muito tempo, até que se tente efetivamente fazer uma restauração que dependa dos blocos danificados, reforçando-se a importância de se manter mais de uma cópia dos dados. 

Perda do catálogo ou de metadados necessários para a recuperação 

A maioria das soluções de backup tradicionais foi desenvolvida originalmente para gerenciar backups armazenados exclusivamente em dispositivos de fitas.  

A presença de um catálogo centralizado, no qual fosse possível consultar os dados armazenados, sem necessariamente conhecer qual cartucho de fita continha esses dados, era fundamental.  

Porém, com a popularização dos backups em disco, impulsionada pela queda nos preços e por suas imensas vantagens em termos de desempenho, muitas dessas soluções simplesmente passaram a suportar esse tipo de mídia como destino para gravação de seus backups, sem antes reavaliar a relevância do uso de catálogos para gerenciar esse conteúdo.  

O resultado dessa decisão é que, nessas soluções, mesmo ao gravar backups em discos que estão continuamente disponíveis e que apresentam excelente velocidade de acesso aos dados, toda e qualquer operação de leitura desse conteúdo armazenado depende de um catálogo central gerenciado pelo software de backup, geralmente no formato de um banco de dados.  

Esse catálogo contém todos os metadados para identificação dos backups e as informações necessárias para recuperá-los. Caso esse catálogo seja danificado ou torne-se indisponível, ainda que os discos que contenham efetivamente os backups estejam online e acessíveis, a restauração não poderá ser realizada. 

Em algumas soluções a dependência de tal catálogo é tamanha que, caso este se perca, nada poderá ser feito, e os backups, ainda que disponíveis, estarão perdidos para sempre.  

Já outras soluções oferecem maneiras de reconstruir seu catálogo e inventariar os backups armazenados novamente. No entanto, em geral, esse processo é trabalhoso e demorado, e nenhum backup poderá ser restaurado até que o catálogo esteja novamente disponível. 

Os dados de origem já estavam comprometidos quando o backup foi feito 

Outra situação inesperada, mas que surpreendentemente é muito comum, em alguns casos uma recuperação pode falhar simplesmente porque os dados usados como origem para os backups já se encontravam corrompidos, sem que se tivesse dado conta anteriormente. 

Isso pode ocorrer quando não reiniciamos o sistema operacional após uma atualização e quando finalmente reiniciamos, aparece aquela tela azul. Recorre-se então ao backup mais recente, apenas para descobrir, ao fim da restauração, que a situação permanece a mesma. Afinal, o backup foi realizado em um momento em que os patches já estavam aplicados. 

Outra situação é quando há infecção por malware, já que este pode permanecer em estado dormente por semanas, como se fosse uma bomba-relógio. Quando o estrago for detectado, é provável que todos os backups recentes já estejam infectados e restaurá-los apenas reintroduzirá a infecção. 

A única maneira efetiva de identificar o problema nesses casos é realizar testes de recuperação, o que pode demandar tempo e recursos preciosos. 

Falhas de restauração não precisam ser comuns 

Infelizmente, os cenários de perda de dados devido a falhas de backup ou recuperação ainda são muito comuns, como podemos notar com os exemplos acima.  

Mas essa não precisa ser a realidade da sua empresa. 

Independentemente da situação, a SManager junto com a parceira Veeam, empresa líder em soluções de backup que fornecem gerenciamento de dados em nuvem (Cloud Data Management™), oferece meios para que você possa se prevenir e assegurar o sucesso em suas restaurações, quando, onde e como você precisar. 

Clique aqui e consulte nossos especialistas sobre soluções de backup e recuperação capaz de proteger seus dados, visto que os impactos de uma decisão errada podem ser desastrosos.