resultados de imagem ddrescue do GNU - 116 erros muito?

2

Um pouco sobre isso.

É uma unidade SSD de 256 GB com o Windows SP3 de 32 bits e é criptografada com a criptografia de disco inteiro do PGP. O sistema de arquivos está corrompido e ilegível.

Primeiramente eu executei o Clonezilla para clonar a unidade com -q1 (clone de setor) e o Clonezilla não pôde iniciar o processo de clone porque ele disse que a unidade está fisicamente danificada (isso determina isso usando o SMART ou observando a G-List? ). Em seguida, fiz check-off -rescue (ignora setores defeituosos) e foi clonado.

Eu queria uma imagem / clone melhor, então encontrei o Live Rescue Remix do Ubuntu e executei o GNU ddrescue. Eu criei uma imagem da unidade SSD usando a seguinte sintaxe: sudo ddrescue -r 5 -v -d {unidade de origem} {dest drive / imgfile} logfile (retries setores defeituosos 5 vezes; saída detalhada para a tela; modo de acesso direto para pular o cache do kernel).

Terminou em 2: 30-3: 00 horas. A taxa média de transferência ficou em torno de (25,88 MB / s) (usei eSATA e SATA, respectivamente, para transferir dados). Também lista "erros: 116" e "errsize: 470 kB". Para o registro, o programa lista "Tamanho do setor: 512 bytes" e "Tamanho do bloco de cópia: 128 setores".

(não posso postar uma imagem porque sou novo.)

Duas coisas:

  1. Os resultados indicam que 116 erros (setores ou blocos?) totalizando 470 kB foram encontrados e transferidos ou encontrados e não transferidos? Se você notar, o programa diz que está prestes a copiar 256052 MB e diz que resgatou 256052 MB. Então, eu não tenho certeza.
  2. Os 116 erros são considerados muito e indicativos de danos físicos?

No momento, posso confirmar que, no mínimo, mais de 99% dos dados foram transferidos. Eu diria que é muito bom. Na verdade, o cálculo aproximado é: 1 - (470 kB / 256 GB) = ~ 0,9999981640625 - > 0,9999981640625 * 100 ~ 99,9998%.

Mais uma vez, o Clonezilla não conseguiu clonar, a princípio, porque relatou que a unidade está fisicamente danificada. No entanto, enquanto o GNU ddrescue relatou 116 erros, pelo menos a maioria dos dados foi visualizada. Eu sei que existem erros lógicos na unidade. Mas esta unidade está fisicamente danificada com base em 116 erros, totalizando 470 kB?

Por fim, o que é um erro? Esse número de blocos, setores ou alguma outra coisa é ruim? E é tudo relacionado a errsize. No meu caso, são 116 erros e errsize de 470 kB. Mas eu vi outras varreduras na Internet com 1 erro e 500 GB errsize. Então, não tenho certeza de qual é a correlação.

Atualizar

Não recebi resposta, por isso vou atualizar e esperar que alguém mais inteligente do que eu responda com algumas respostas.

Eu executei o GNU ddrescue mais uma vez, com novas tentativas de leitura aumentadas de 5 para 20. O restante é o mesmo, incluindo os resultados (demorou um pouco mais para a imagem do que a primeira vez, devido ao aumento de tentativas de leitura). Sim, a contagem de erros e o tamanho do erro (ainda não entendi o relacionamento deles ou o que um erro significa neste programa) são 116 e 470 kB, exatamente o mesmo da primeira vez em que gravei este programa. O que isso poderia significar? Coloque uma arma na minha cabeça, eu diria que esta unidade SSD não está fisicamente danificada. E se for, é leve. Eu ainda não sei se 116 erros são muito, mas aqui está porque eu acho que não há nenhum dano físico. Se houvesse, a contagem de erros e o tamanho do erro não iriam subir na segunda vez em que eu visualizasse a unidade, especialmente com o aumento das tentativas de leitura para 20?

Eu queria que os erros diminuíssem, e é por isso que tentei criar imagens novamente. Eu não tenho muita experiência com SSDs. Mas talvez eles sejam diferentes dos discos mecânicos, pois, se você não conseguir ler um bloco ruim, provavelmente não conseguirá, não importa quantas vezes tente novamente. Estou assumindo que os serviços de recuperação de dados têm ferramentas de software e hardware imensamente superiores que podem ler blocos ruins de um SSD, no entanto.

Esta unidade SSD foi escrava algumas vezes para analisar e também tentar descriptografar. Eu clonei com ele o Clonezilla (que afirma que ele está fisicamente danificado), e então eu gravei duas vezes com o GNU ddrescue com um valor de parâmetro aumentado e os resultados da imagem são exatamente os mesmos. Alguém poderia pensar que, com tudo o que essa campanha passou, se ela estava falhando, levaria muito tempo para ler / escrever e o número de erros aumentaria. Mas nada disso aconteceu. Talvez eu esteja apenas com sorte e esteja fisicamente danificado. Mas se for, acho que é leve.

Mas eu perguntarei novamente: São 116 erros muito? Qual é a correlação de erros com o tamanho do erro, quando li contas de resultados de imagem com 1 erro e um tamanho de erro de muitos GBs? E é um erro aqui em termos de setores, blocos ou alguma outra medida?

Obrigado.

    
por user301234 20.02.2014 / 18:10

1 resposta

3

A seção Algoritmo do manual ddrescue descreve errsize e errors . errsize é a soma dos tamanhos dos "blocos" do setor defeituoso, onde um "bloco" é o termo do ddrescue para uma série de setores defeituosos contíguos. Por outro lado, errors é a contagem desses "blocos" do setor inválido.

Como o manual descreve, em cada passagem após a primeira, os "blocos" do setor defeituoso são repetidos e podem ser divididos. Como os setores defeituosos são lidos com êxito, errsize diminuirá e errors poderá aumentar ou diminuir (porque um bloco pode ser dividido por um bom setor ou todos os setores defeituosos em um bloco foram lidos com êxito, respectivamente).

Então, respondendo à sua pergunta, "os erros numéricos são muitos?", você precisa examinar o errsize em vez de errors . Em um SSD de 256GB, não acho que 470kB (menos de 0,0002% da unidade) são muitos erros.

Você também deve olhar para smartctl e os S.M.A.R.T. auto-testes para sentir a saúde da unidade. IMHO, uma vez que uma unidade começa a falhar nos testes pré-falha, geralmente não vale a pena o risco de perda de dados continuar usando a unidade.

    
por adborden 22.08.2015 / 22:38