Analise o espaço alocado na partição Ext4 para melhorar a eficiência da recuperação de dados

Analise o espaço alocado na partição Ext4 para melhorar a eficiência da recuperação de dados

Estou tentando usar o Lubuntu para recuperar o máximo de dados possível de uma unidade de disco rígido de 4 TB com falha.

Segundo o GParted a partição principal, formatada em Ext4, contém apenas 553GB de dados. Eu tentei fazer um clone completo comHDDSuperClone, um software GUI para Linux, semelhante à ferramenta de linha de comando ddrescueem finalidade e funcionalidade. No início estava funcionando bem, com poucos erros/setores ignorados e uma boa taxa média de cópia (~60MB/s). Mas, no meio do caminho, começou a haver problemas mais graves, com algumas áreas nem sendo lidas, formando um padrão em listras alternadas de leituras boas e leituras ruins, o que normalmente indica que um cabeçote está com defeito. Nesse ponto parei a recuperação.

Eu tinha recuperado cerca de 1,7 TB e ele estava copiando apenas 00s por um bom tempo, então pensei que todos os dados relevantes já estariam protegidos na unidade de recuperação. Mas acontece que a partição principal não pode ser montada (embora ainda possa ser montada na unidade de origem, embora com dificuldade), e software de recuperação de dados de renome (R-Studio, DMDE) não consegue reconstruir a estrutura de diretório original ou recuperar nomes de arquivos originais. E ao abrir a unidade de recuperação no WinHex posso ver que ela está totalmente vazia além de 438GB, o que significaria que faltam cerca de 115GB - embora eu não entenda como isso seria possível, já que os sistemas de arquivos devem gravar dados no disco mais externo. áreas disponíveis, onde a velocidade de leitura/gravação é melhor, para otimizar o desempenho dos HDDs.

Agora, para aproveitar ao máximo o que resta, considerando que a condição da unidade pode se deteriorar rapidamente na próxima tentativa séria de recuperação, estou procurando qualquer método que possa analisar as estruturas de metadados e relatar o espaço alocado/não alocado, para que eu poderia direcionar a recuperação para essas áreas relevantes, em vez de perder um tempo precioso lendo gigabytes de zeros. Um pequeno programa de linha de comando desenvolvido há alguns anos pelo autor do HDDSuperClone, ddru_ntfsbitmap(parte de ddr_utility), pode fazer isso automaticamente com partições NTFS: ele analisa o $Bitmaparquivo e gera um “mapfile” para ddrescueo qual restringe efetivamente a cópia aos setores marcados como alocados (desde que este arquivo de sistema possa ser lido na íntegra); ele também pode gerar um “mapfile” para recuperar o $MFTprimeiro, o que é tremendamente útil (o MFT contém todos os metadados dos arquivos e informações sobre a estrutura de diretórios, se estiver corrompido ou perdido, apenas o tipo de recuperação “raw file carving” é possível). Mas mesmo este indivíduo altamente competente não sabe fazer o mesmo com partições Linux, como respondeu emeste tópico HDDGuru.

Portanto, mesmo que não seja totalmente automatizado, eu precisaria de um procedimento que pudesse analisar uma partição Ext4, de forma rápida e eficiente, para não desgastar ainda mais a unidade no processo, e relatar essas informações como um registro de texto ou como uma apresentação gráfica. . Talvez um programa de desfragmentação resolvesse o problema?

E de modo geral, onde estão as estruturas de metadados importantes (“inodes” se não me engano) localizadas em uma partição Linux? Existe um único arquivo equivalente ao NTFS $Bitmapou as informações sobre alocação de arquivos/setores são determinadas através de uma análise mais complexa? (Se isso for relevante, a unidade estava em um gabinete de rede WDMyCloud, configurada de fábrica e rodando com um sistema operacional Linux.)

Análise GParted da unidade de origem.

Em cerca de 47% da recuperação, problemas sérios começam a aparecer, as listras alternadas de leituras boas (verde) e leituras ruins (cinza) indicam que um cabeçote falhou.

informação relacionada