Please enable JS

Perda de Dados e Ações Pós Incidente

Criado em 19/11/2019, por Hosco. Atualizado em 14/10/2021.

Introdução

Após duas décadas observando a reação de empresas diante de desastres com perda de dados, ficou evidente a adoção de alguns procedimentos em comum - mesmo entre instituições que não têm qualquer relacionamento. Tanto em incidentes causados por danos em hardware, quanto em desastres ocorridos em nível lógico, as repostas poderiam ser aprimoradas para evitar maiores prejuízos e proporcionar uma recuperação satisfatória.

Erros Comuns

Incidentes com perda de acesso a dados críticos exigem reações rápidas e precisas. No entanto, há uma certa morosidade inerente às políticas usualmente adotadas, assim como o uso de práticas que apresentam riscos para os ambientes a serem recuperados.

Em empresas de pequeno e médio porte, danos em storage e perda de dados são frequentemente indentificados pelos usuários que acessam os recursos comprometidos - quando deveriam ter sido detectados por um administrador. É comumm haver lentidão entre chamados e reuniões, até que alguma resposta efetiva seja realizada. Por outro lado, instituições de grande porte têm equipes responsáveis pela monitoração de storages e recursos de armazenamento. Na maioria dos casos, as equipes de backup e disaster recovery fazem com que a reação seja imediata e eficiente. No entanto, procedimentos invasivos de verificação e tentativas "arriscadas" de restabelecimento dos recursos afetados podem ocorrer em empresas de todos os portes.

Um exemplo dessas práticas inadequadas está no fato de muitos analistas forçarem rebuilding em RAID com drives (HDs, SSDs, etc.) corrompidos, o que pode quebrar a consistência de metadados e danificar conteúdos. Assim como há certos riscos quando se configura controladoras para fazerem auto-rebuilding.

Escaneamento de setores ou blocos, constitui outro procedimento indevido quando realizados em HDs com mal funcionamento. No entanto, comandos como chkdsk /f, sfc /scannow, fsck -f, entre outros, são muito usados por analistas que equivocadamente acreditam poder "reparar" discos danificados com esses utilitários (que não foram desenvolvidos para esse propósito). Essas ferramentas podem causar danos se utilizadas em circunstâncias erradas. Infelizmente, os próprios desenvolvedores de algumas delas incentivam seu uso em drives que podem estar com dano físico.

Principalmente em empresas de porte menor é comum que tarefas as quais deveriam ser realizadas por uma equipe de data recovery, serem executadas por um analista interno e sem treinamento nesse segmento.

Consequências

Em pequenas e médias coorporações note-se uma morosidade em detectar e reagir às falhas em storages. O mesmo ocorre em perda de dados causada por acidentes (exclusão de arquivos, tabelas de partição, etc.) e ações dolosas (espionagem industrial, vandalismo digital, etc.). Mas mesmo nas instituições de maior porte, procedimentos arriscados em drives avariados ocorrem com certa frequência, podendo agravar o incidente e dificultar a recuperação do conteúdo alocado.

Não estamos falando, necessariamente, de ações absurdas como violação de discos ou uso de programinhas "milagrosos" que prometem regenerar um HD. Chamamos atenção para procedimentos que parecem inofensivos, mas com potencial de destruir discos em estado precário ou causar inconsistência permanente em volumes e/ou sistemas de arquivos.

Dispositivos de armazenamento (HD, SSD, flash drive, etc.) danificados precisam ser preservados e tratados como objetos de perícia. Em ambientes com informações críticas, eles devem ser desativados assim que constatado qualquer sinal de mal funcionamento, principalmente nos desastres que impedem o acesso aos dados alocados.

Controladoras de storage realocam setores (em nível de firmware de drive) ou blocos (em nível de volume ou sistema de arquivos), quando encontram áreas danificadas nas mídias de armazenamento. Qualquer operação de leitura ou gravação em drive avariado é suficiente para disparar essas rotinas. Isso toma proporções gigantescas em escaneamentos de setores ou blocos, através de programas como HDtune ou utilitários como chkdsk e fsck. O primeiro problema causado por essas ações invasivas é a perda dos dados contidos nos setores que foram realocados. O segundo problema é o agravamento do dano físico em HDs, degradando cabeças de leitura, pratos magnéticos e causando problemas em módulos de firmware. Portanto, esses procedimentos podem ocasionar perda irreversível de dados, inviabilizando, até mesmo, um trabalho de recuperação profissional.

Melhores Práticas

Verificando volume corrompido

O SMART é um excelente aliado dos usuários, técnicos e analistas. Essa tecnologia caracteriza-se por um conjunto de rotinas contidas no sistema do próprio drive de armazenamento, que reporta o seu estado de funcionamento. Programas como o Gsmartcontrol conseguem interpretar os logs do SMART, mostrando detalhes sobre o status do dispositivo.

A verificação do estado de saúde de uma mídia de storage (HD, SSD, flash drive, etc.) através da leitura do SMART é uma prática bastante recomendada por não ser invasiva. Além disso, é uma ação simples que pode ser realizada por um analista nivel 1, diminuindo os tempos de resposta.

Em ambientes Linux e Unix, a libata é um importante marcador na detecção desses problemas. É uma biblioteca no kernel, responsável por gestão de erros nos discos usados pelo sistema operacional. Basta verificar se a saída do comando dmesg apresenta mensagens (geradas pelo kernel) de erros de leitura ou escrita. Trata-se de uma análise passiva segura e totalmente confiável.

Os sistemas de arquivos também emitem sinais claros quando existem drives com mal funcionamento. Em plataformas Windows, é comum o gerenciador de tarefas indicar uso de disco em 100%. Em plataformas Unix, serão observados picos de processamento com threads de I/O (kworker, jdb2, etc.).

Em empresas maiores é incomum a verificação das formas citadas acima. São usadas soluções de monitoramento presentes em servidores e storages de grandes vendors, como Oracle HMP, IBM TSM, Dell OpenManage, Supermicro SuperDoctor, etc. Estas ferramentas entregam as informações de modo que o administrador não precisa se preocupar em entneder parâmetros de SMART ou analisar logs da libata.

Os incidentes com perda de dados por dano lógico, geralmente, emite sinais são claros por si só. Salvo casos de violação de sistemas.

Conclusão

O tempo de resposta e o tipo de resposta são muito importantes na recuperação de um ambiente com conteúdo indisponível. Burocracia, políticas arcaicas, ausência de planos de recuperação de desastre e ações invasivas, são os maiores agravadores de desastres com perda de dados.

Diante de tais circunstâncias deve-se adotar ações rápidas, eficientes e não invasivas. O mais importante é desativar, rapidamente, os dispositivos de armazenamento envolvidos, para evitar realocação de setores e corrompimento de metadados. Em ambientes com informações críticas, recomenda-se consultar uma empresa especializada em recuperação de dados.

É importante lembrar que a melhor prevenção contra perda de dados continua sendo a implementação de sistemas eficientes de backup. A substituição periódica das mídias de armazenamento também deve fazer parte do plano de prevenção de qualquer empresa.

#recuperaçãodedados #incidentecomputacional #disasterrecovery #datarecovery #incidentresponse