Medo, frustração, desespero, frio na espinha… Muitos sentimentos podem surgir a partir da constatação de que seus backups não podem ser restaurados, mas certamente nenhum deles será agradável. Afinal, o backup é justamente a cópia dos dados que mantemos a salvo para ser nosso porto seguro caso algo dê errado. Pense nele como uma apólice de seguros para os seus dados. No caso de um seguro, se a apólice não cobrir o tipo de dano sofrido, você terá que arcar inteiramente com o prejuízo, independentemente do valor investido nela. Da mesma forma, se uma cópia de segurança não puder ser restaurada quando precisarmos, há grandes chances de que determinados dados serão permanentemente perdidos.
Infelizmente essa situação é mais comum do que muitos imaginam. Nosso mais recente relatório sobre a proteção de dados (Veeam Data Protection Report 2021), que consultou mais de 3 mil decisores em TI, constatou que 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. Se considerarmos também outra estatística alarmante detectada pelo estudo, de que 37% dos backups realizados apresentaram falhas ou não foram completados dentro da janela estabelecida, podemos concluir que em mais da metade das situações nas quais uma restauração for necessária, ela não será possível, seja por não ter um backup válido disponível ou por falhas na conclusão do próprio processo de restauração.
Em um mundo em que os dados têm se tornado o novo petróleo, um incidente que resulte na perda deles pode se traduzir em prejuízos que vão muito além de uma simples indisponibilidade. Apesar de o custo atual estimado por hora de indisponibilidade ser de USD 84.650, 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 organização e minar a confiança dos clientes na marca. Também são comuns os impactos à moral dos colaboradores e a utilização emergencial de recursos que seriam investidos em projetos críticos ou iniciativas de longo prazo. E, por fim, ainda podem incorrer sobre a empresa multas ou processos judiciais no caso do descumprimento de regulamentações e exigências legais.
E, no meio desse furacão, todo estresse e pressão recairão sobre a equipe de TI, com constantes ligações acaloradas por parte dos executivos de negócios, horas extras intermináveis e um grande esforço para tentar normalizar a operação.
Mas afinal, o que está por trás dessas falhas de restauração? Como a Veeam pode me ajudar?
A realidade é que muitas podem ser as causas de uma falha de restauração. Algumas vezes o problema pode até ser causado por uma combinação de múltiplos fatores aparentemente irrelevantes quando analisados individualmente, ou por mera falta de experiência ou conhecimento na ferramenta de backup utilizada, que resulte em uma proteção incompleta ou ineficiente dos dados. Independentemente da situação, a 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. Pensando nisso, relacionamos a seguir as causas mais frequentes de incidentes de falhas de restauração, juntamente com nossas recomendações para eliminá-las.
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. A Veeam prega inclusive uma evolução dessa regra para o modelo 3-2-1-1-0, onde recomenda-se ainda que 1 das mídias utilizadas seja imutável ou possua uma barreira de inacessibilidade (air gap) quando não estiver em uso, e que os backups sejam validados periodicamente para assegurar 0 erros no caso de uma eventual recuperação.
Para auxiliar nossos clientes a manter a conformidade com essa regra, a Veeam oferece diversas opções, como:
- Suporte abrangente a dispositivos de fitas, que ainda são uma ótima maneira de manter uma cópia off-site e off-line dos dados;
- Tarefas de cópia de backups, inclusive com suporte a repositórios em provedores de serviços de nuvem baseados no Veeam Cloud Connect; e
- Cópia automática e transparente dos backups para armazenamentos de objetos imutáveis, baseados em S3, por meio de Capacity Tier dos repositórios Scale-Out.
Falhas decorrentes de erros de firmware
Essa categoria é especialmente relevante 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. Caso essa cópia sofra uma corrupção, os backups dos 300 servidores serão comprometidos simultaneamente. Assim como ocorre nas falhas de hardware, esse tipo de situação pode passar desapercebida 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.
Para ajudar a detectar e corrigir esse tipo de situação antes que seja tarde, a Veeam oferece um recurso chamado Storage-Level Corruption Guard, o qual pode ser ativado nas configurações das tarefas de backup para, periodicamente, ler todos blocos necessários à restauração dos backups mais recentes. Esse processo será então feito de forma totalmente automatizada e identificará quaisquer falhas de acesso aos dados. Caso sejam detectados dados corrompidos, esse processo também irá repará-los automaticamente, obtendo uma nova cópia dos dados comprometidos a partir do ambiente produtivo.
Perda do catálogo ou de metadados necessários para a recuperação
A imensa maioria das soluções de backup tradicionais foi desenvolvida originalmente para gerenciar backups armazenados exclusivamente em dispositivos de fitas. Em tais circunstâncias, 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, nada poderá ser restaurado.
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.
Por ser uma solução moderna, projetada desde o início para gerenciar o armazenamento de backups em disco, a Veeam não requer ou sequer possui um catálogo no sentido tradicional para tais backups. Ao invés disso, cada arquivo de backup gerado pela Veeam contém dentro de si próprio os metadados necessários para identificar e restaurar seu conteúdo. Isso faz com que seja possível transportar os arquivos de backups livremente e restaurá-los rapidamente em qualquer outra instalação do Veeam Backup & Replication, inclusive da edição Community. Desse modo, em caso de um desastre que afete o servidor de backup original e seu banco de dados de configurações, basta realizar uma nova instalação e adicionar novamente ao console as informações sobre o local onde se encontram os backups, e eles serão imediatamente reconhecidos e estarão prontos para uma restauração, seja ela completa ou granular.
E o melhor: ao passar a suportar a nuvem como destino secundário para os backups, a Veeam manteve esse princípio intacto. Isso significa que em um desastre mais sério, em que todo o site tenha sido perdido, basta adicionar o bucket ou conta da nuvem contendo os backups a uma nova instalação da ferramenta e começar a restaurar imediatamente.
Ah sim… caso você esteja se perguntando sobre as implicações de segurança, sempre é possível adicionar criptografia aos backups para que seja exigida uma senha, antes de permitir sua restauração em uma instalação desconhecida.
Ransomware
Não poderia deixar de incluir na lista essa ameaça que hoje parece tão onipresente. O termo ransomware, ao contrário do que muitos imaginam, não se limita a uma categoria de vírus ou worms que atuam criptografando os dados alheios e exigindo um resgate. A realidade é que esse componente da equação, o chamado cryptolocker, hoje tem um papel, de certa forma, secundário em todo o processo. Cada vez mais o que se observa é uma articulação elaborada, conduzida por um ou mais indivíduos de maneira direcionada e diligente, com o objetivo de obter credenciais e burlar as defesas existentes para vazar e sequestrar dados das organizações numa escala muito maior, exigindo quantias exorbitantes de dinheiro, na forma de bitcoins ou outras criptomoedas, para, supostamente, devolver o acesso aos dados. Mas a realidade é que não há qualquer garantia de que, ao fazer o pagamento solicitado, a promessa será cumprida. Por essa razão, o backup é seu maior aliado e sua última defesa contra essa ameaça. E o problema é que esses indivíduos também sabem disso…
Em um ataque direcionado desse tipo, mais do que simplesmente tentar criptografar os backups, os invasores tentarão removê-los ou inutilizá-los, por vezes usando a própria solução de backup para isso. Em boa parte das soluções presentes hoje no mercado, um pedido de exclusão executado por um usuário operador da ferramenta será fatal, e os backups serão destruídos, ainda que a mídia em que eles se encontrem não possa ser criptografada diretamente.
Foi justamente por conta desse novo modo de operação que a Veeam incorporou a recomendação pelo segundo “1” da regra 3-2-1-1-0, que expliquei anteriormente. Um backup off-line, imutável ou com um air gap, não poderá ser destruído ainda que o invasor tome o controle da solução e solicite sua exclusão.
Pensando nisso, a Veeam, além do suporte a fitas incorporado na versão 7 do Veeam Backup & Replication, vem concentrando-se em recursos de imutabilidade para os backups armazenados. Já há algum tempo, oferecemos a funcionalidade Insider Protection, para preservar os backups armazenados em um repositório alocado em um provedor de serviços de nuvem da Veeam, ainda que a cópia local seja excluída.
Na versão 10, trouxemos suporte ao recurso de Object Lock, oferecido pelo Amazon S3 e alguns outros provedores compatíveis, para assegurar total imutabilidade para as cópias secundárias de backup armazenadas nesse tipo de storage de objetos. Isso significa que, ainda que a exclusão dos backups seja solicitada por meio da própria solução, os dados permanecerão seguros.
E mais recentemente, com a versão 11, adicionamos suporte à imutabilidade também para as cópias primárias de backup, por meio do novo repositório Linux seguro, para que você tenha acesso a esse tipo de proteção sem ficar preso a qualquer hardware proprietário que custe os olhos da cara.
Os dados de origem já estavam comprometidos quando o backup foi feito
E para concluir, vamos a 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.
Um exemplo clássico desse tipo de situação são as atualizações do sistema operacional. Às vezes, tais atualizações podem exigir uma reinicialização para serem concluídas, o que nem sempre pode ser feito de imediato, passando-se então alguns dias. Ao finalmente reiniciar o servidor, depara-se com a temível tela azul ou um kernel panic. 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.
Outro exemplo comum é o de infecção por malware. O malware pode permanecer em um estado dormente por semanas, sem qualquer sinal aparente de atividade, similar a 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.
Ambas as situações são muito difíceis de se detectar em soluções de backup tradicionais, uma vez que a simples validação da integridade dos backups, por meio de checksum ou abordagens similares, não identificará problema algum, visto que o conteúdo do backup está idêntico à cópia original. A única maneira efetiva de identificar o problema nesses casos é realizar testes de recuperação, o que pode demandar tempo e recursos preciosos.
Para resolver essa questão, o Veeam Backup & Replication conta com o SureBackup, um tipo de tarefa que simplifica o processo de validação do conteúdo dos backups por meio de testes automatizados de recuperação, baseados no conceito do Instant VM Recovery®, iniciando, em instantes, um ou mais servidores virtuais diretamente das imagens de backup armazenadas no repositório. Durante esse processo, os servidores iniciados para os testes permanecem isolados do ambiente produtivo, formando um laboratório virtual. Então, o Veeam valida a correta inicialização do sistema operacional e aplicações dentro de cada máquina virtual, podendo ainda executar testes personalizados por meio de scripts. Também é possível realizar a varredura de vírus durante esse processo, caso desejado. Ao concluir o teste com sucesso, é emitido um relatório completo sobre os resultados, evidenciando a recuperabilidade do backup.
Falhas de restauração são comuns, mas não precisam ser
Infelizmente, os cenários de perda de dados devido a falhas de backup ou recuperação ainda são muito comuns, como demonstrou nosso estudo. No entanto, essa realidade não precisa ser a da sua empresa. A recuperabilidade e a confiabilidade dos backups devem ser encaradas com a devida relevância ao escolher uma solução de backup e recuperação que será encarregada de proteger seus dados, visto que os impactos de uma decisão errada podem ser desastrosos. Por isso, conte com a Veeam para garantir que você está coberto contra toda e qualquer situação inesperada e vá curtir a vida com tranquilidade, afinal, ela é curta demais para ter que ficar se preocupando com backup e recuperação.
