DDRescue Log File corrompido após 6 semanas de recuperação

Question

Eu tenho runnning DDRescue em uma unidade de 3Tb por quase 2 meses e eu tinha recuperado cerca de 2,8 TB quando o sistema caiu e o arquivo de log que eu estava usando saiu corrupto. Consegui recuperar parte desse arquivo de log, mas há uma lacuna nos setores no log recuperado que faz com que o DDRescue retorne um erro quando eu o inicio novamente. Aqui está um link do wetransfer para ver o arquivo de log: link

Eu tentei editar o arquivo de log para remover os dados corrompidos, mas como isso cria uma 'lacuna' na cronologia dos setores, o DDRescue não parece gostar disso.

Obrigado por qualquer ajuda, eu realmente gostaria de evitar ter que re-executar o DDRescue por mais dois meses para salvar esta unidade ...

    

Answer 1

Para tornar esta resposta pelo menos parcialmente útil para outros usuários com problemas semelhantes, vamos citar as partes cruciais do seu log aqui:

# Rescue Logfile. Created by GNU ddrescue version 1.18.1
# Command line: ddrescue -f -d -R -r3 /dev/sde /dev/sdf /mnt/somedir/logfiles/log3.log
# Start time:   2017-08-14 10:22:44
# Current time: 2017-08-14 12:13:09
# Copying non-tried blocks... Pass 1 (backwards)
# current_pos  current_status
0x27BF0520000     ?
#      pos        size  status
0x00000000  0x02870000  +
0x02870000  0x001A0000  *
0x02A10000  0x00010200  +
0x02A20200  0x0005FE00  *
# ...                          many lines here
0x2BA92360000  0x00040000  ?
0x2BA923A0000  0x00010000  *
#                              binary garbage here
0xE4E1710000  0x00010000  *
# ...                          many lines here
0x13D75970000  0x00000200  +
0x13D75970200  0x00

Você identificou a linha antes do lixo binário para ser a última válida. Ele diz 0x2BA923A0000 0x00010000 * e é o número da linha 880829 no seu caso. Faz sentido porque as linhas depois do lixo têm posições mais baixas (primeiros números), elas parecem duplicar linhas anteriores.

eu fiz

<log3.txt head -n 880829 > log3new.txt

e execute ddrescue (com infile sendo o dispositivo de loop de um grande arquivo esparso, não importa, no entanto). Queixou-se da linha 583658.

Esta é a linha com sua vizinhança:

# ...
0x186C6940000  0x00000200  +
0x186C6940200 A9520200  0x0001FE00  *  # <- this line here
0x24AA9540000  0x00000200  +
# ...

Para corrigir isso, você deve cobrir todo o intervalo de 0x186C6940200 a 0x24AA9540000 , para que o arquivo de log seja contíguo. O comprimento é 0x24AA9540000 - 0x186C6940200 = 0xC3E2BFFE00 . Toda a linha 583658 deve ser:

0x186C6940200 0xC3E2BFFE00 ?

onde ? significa blocos não experimentados.

Eu fiz uma correção com

sed -i '583658s/.*/0x186C6940200 0xC3E2BFFE00 ?/' log3new.txt

O arquivo de log resultante é válido para ddrescue .

EDITAR

The problem I have though is that it's making DDrescue think that it's only recovered 2041GB while when the crash happened it was above 2800GB and as you can imagine these last 800GB took many weeks to be recovered.

Na verdade, não sabemos se são os mesmos 800 GB. Há uma ferramenta ddrescueview (com GUI, disponível como ddrescueview package no Ubuntu) que mostrará onde exatamente esses blocos não experimentados que introduzimos são. Observe que a posição atual é em outro lugar:

SoI'mwonderingiftheinfoafterthegarbagemighthavesomethingtodowithit?Anywaywecanincludeitinthelogfile?

Euisoleiessapartedo"after the garbage", as últimas 129289 linhas:

tail -n 129289 log3.txt > extra.txt

Este comando mostrará as linhas que estão em extra.txt , mas não em log3new.txt :

diff --suppress-common-lines extra.txt log3new.txt | grep -e '^<'

A saída é

< 0x13D75970200  0x00

Significa apenas a última linha (incompleta) depois que o lixo não está lá antes do lixo no original log3.txt . Desculpe, parece-me que log3new.txt já é o melhor que você pode obter.