Existe alguma maneira de acelerar o ddrescue?

Question

Eu tive um HDD de drive de 500 GB aproximadamente cinco dias atrás. Eu usei ddrescue na partição importante há alguns dias e está em "Trimming failed blocks" há quase 2 dias.

Comando original:

ddrescue -n /dev/rdisk1s2 /Volumes/OSXBackup/rdisk1s2.img /Volumes/OSXBackup/rdisk1s2.log

Saída atual:

Initial status (read from logfile)
rescued:   248992 MB,  errsize:   1007 MB,  errors:   15867
Current status
rescued:   249021 MB,  errsize:    978 MB,  current rate:    17408 B/s
   ipos:    44405 MB,   errors:   15866,    average rate:     2784 B/s
   opos:    44405 MB,     time from last successful read:       0 s
Trimming failed blocks...

O comando original usou o parâmetro ddrescue -n e reiniciei o processo algumas vezes, conforme necessário (e ele pareceu continuar de onde parou a cada vez).

Existe alguma maneira de acelerar este processo?

Editar: Seis horas depois, este é o status atual:

rescued:   249079 MB,  errsize:    920 MB,  current rate:      409 B/s
   ipos:    39908 MB,   errors:   15851,    average rate:     2698 B/s
   opos:    39908 MB,     time from last successful read:       0 s
Trimming failed blocks...

Parece que, enquanto os "erros" estão diminuindo excrucianemente lentamente, o ipos / opos está fazendo uma contagem decrescente de dados para os quais tem que trabalhar, e parece estar trabalhando a uma taxa de 750MB / hora. Nesse ritmo, ele será concluído em aproximadamente 53 horas. Yikes

Editar # 2: Dois dias depois, ainda em execução. No entanto, há esperança. Ele moveu a parte "Trimming failed blocks" e passou para a próxima fase "Splitting failed blocks". Se alguma coisa, o que deve ser tirado de ver esta questão é que isso definitivamente leva muito tempo quando uma boa quantidade de dados / erros estão envolvidos. Minha única esperança é que eu possa recuperar com sucesso alguns dados importantes quando tudo estiver dito e feito.

rescued:   249311 MB,  errsize:    688 MB,  current rate:        0 B/s
ipos:    26727 MB,   errors:   15905,    average rate:     1331 B/s
opos:    26727 MB,     time from last successful read:      20 s
Splitting failed blocks...

    

Answer 1

Eu observei que usar a opção -n (no-split) junto com -r 1 (repetir uma vez) e definir -c (tamanho do cluster) como um valor menor pode ajudar.

Minha impressão é que a etapa de divisão é muito lenta, pois ddrescue divide e divide novamente as áreas danificadas. Isso leva muito tempo porque ddrescue tenta restaurar partes muito pequenas dos dados. Então, eu prefiro usar -n (no-split) junto com -c 64 , -c 32 , -c 16 , a.s.o.

Provavelmente, o -n (sem divisão) sempre deve ser usado para uma primeira passagem nas direções direta e inversa. Parece que quanto mais os dados foram divididos, mais lenta a clonagem, embora eu não tenha certeza disso. Assumo que quanto maiores as áreas não tratadas, melhor quando executar ddrescue novamente, porque setores mais contíguos serão clonados.

Como estou usando um arquivo de log, eu não hesito em cancelar o comando com Ctrl + C quando a velocidade de leitura de dados se torna duas baixa.

Eu também uso o modo -R (Reverse) e depois de um primeiro passo muitas vezes ele me dá velocidades mais altas de leitura para trás do que para frente.

Não está claro para mim como os setores já repetidos ( -r N ) são manipulados ao executar o comando ddrescue novamente, especialmente ao alternar comandos de clonagem de encaminhamento (padrão) e reverso ( -R ). Eu não tenho certeza se o número de vezes que eles foram tentados é armazenado no arquivo de log e provavelmente o trabalho é feito novamente inútil.

Provavelmente, o sinalizador -i (posição de entrada) pode ajudar a acelerar as coisas também.

    

Answer 2

Pode ser muito difícil ver o progresso de ddrescue , mas há outro comando incluído chamado ddrescuelog .

Um comando simples ddrescuelog -t YourLog.txt gerará essas informações interessantes:

current pos:     2016 GB,  current status: trimming
domain size:     3000 GB,  in    1 area(s)
rescued:     2998 GB,  in 12802 area(s)  ( 99.91%)
non-tried:         0 B,  in    0 area(s)  (  0%)

errsize:     2452 MB,  errors:   12801  (  0.08%)
non-trimmed:   178896 kB,  in 3395 area(s)  (  0.00%)
non-split:     2262 MB,  in 9803 area(s)  (  0.07%)
bad-sector:    10451 kB,  in 19613 area(s)  (  0.00%)

Você pode até usá-lo enquanto ddrescue estiver em execução ...

    

Answer 3

Se o seu objetivo é obter a maior parte dos dados intactos, você pode acelerar sua extração. Mas se você realmente quer resgatar o máximo de dados possível, então deixar o ddrecue mordiscar em cada um é o caminho a ser seguido.

    

Answer 4

Eu descobri que brincando com o parâmetro -K você pode acelerar as coisas. Pelo que eu vi se o ddrescue encontrar um erro ao executar com a opção -n, tente pular uma quantidade fixa de setores. Se ainda não consegue ler, salta o dobro do tamanho. Se você tem grandes áreas danificadas, você pode indicar um grande valor K (por exemplo, 100M) e assim o salto em um erro será maior na primeira vez e será mais fácil evitar áreas problemáticas rapidamente no primeiro tempo.

A propósito, existe uma maravilhosa aplicação gráfica para analisar o log.

link

    

Answer 5

Mais uma maneira de monitorar o progresso do ddrescue (no Linux, pelo menos) é através do uso de strace.

Primeiro, encontre o PID para o processo do ddrescue usando "ps aux | grep ddrescue"

root@mojo:~# ps aux | grep ddrescue
root     12083  0.2  0.0  15764  3248 pts/1    D+   17:15   0:04 ddrescue --direct -d -r0 /dev/sdb1 test.img test.logfile
root     12637  0.0  0.0  13588   940 pts/4    S+   17:46   0:00 grep --color=auto ddrescue

Em seguida, execute "strace" nesse processo. Você verá algo como:

root@mojo:~# strace -p 12083
Process 12083 attached - interrupt to quit
lseek(4, 1702220261888, SEEK_SET)       = 1702220261888
write(4, "01653733o7M652101653733o7M6521"..., 512) = 512
lseek(3, 1702220261376, SEEK_SET)       = 1702220261376
read(3, "01653733o7M652101653733o7M6521"..., 512) = 512
lseek(4, 1702220261376, SEEK_SET)       = 1702220261376
write(4, "01653733o7M652101653733o7M6521"..., 512) = 512
^C

... e assim por diante. A saída é rápida e feia, então eu canalizo através de "grep" para filtrar as coisas que me interessam:

root@mojo:/media/u02/salvage# nice strace -p 12083 2>&1|grep lseek
lseek(4, 1702212679168, SEEK_SET)       = 1702212679168
lseek(3, 1702212678656, SEEK_SET)       = 1702212678656
lseek(4, 1702212678656, SEEK_SET)       = 1702212678656
lseek(3, 1702212678144, SEEK_SET)       = 1702212678144
lseek(4, 1702212678144, SEEK_SET)       = 1702212678144
lseek(3, 1702212677632, SEEK_SET)       = 1702212677632
lseek(4, 1702212677632, SEEK_SET)       = 1702212677632
lseek(3, 1702212677120, SEEK_SET)       = 1702212677120
lseek(4, 1702212677120, SEEK_SET)       = 1702212677120
lseek(3, 1702212676608, SEEK_SET)       = 1702212676608
^C

Nesse exemplo, o "1702212676608" equivale a "a quantidade de dados que ainda precisa ser processada nesse disco de 2 TB que você está tentando salvar". (Sim. Ouch.) O ddrescue está lançando um número similar - ainda que "1720 GB" - em sua saída de tela.

strace oferece um fluxo de dados de granularidade MUITO mais alto para você examinar; é mais uma forma de avaliar a velocidade do ddrescue e estimar uma data de conclusão.

Rodá-lo constantemente é provavelmente um plano ruim, já que competiria com o ddrescue pelo tempo de CPU. Eu comecei a canalizá-lo para "cabeça" para que eu possa pegar os primeiros 10 valores:

root@mojo:~# strace -p 4073 2>&1 | grep lseek | head

Espero que isso ajude alguém.

    

Answer 6

Qual é o sistema de arquivos do disco rígido onde você salva a imagem de recuperação e o arquivo de log? Acabei de fazer a experiência que resgatar um disco rígido interno de 500Gb (conectado via SATA) em um laptop executando o Linux Mint a partir de um pendrive USB, salvando a imagem de recuperação e o arquivo de log em um disco rígido USB formatado exFat -2MB / seg), mas depois de cerca de 250 GB, estava apenas a rastrear a < 100KB / seg. Parecia ficar mais lento quanto maior o arquivo de imagem de resgate estava crescendo.

Em seguida, movi a imagem de resgate e o arquivo de log para outro local temporário, reformatei o disco rígido USB com o sistema de arquivos ext4 , movi os arquivos de volta e retomei o processo ddrescue - e agora ele é executado com 1 20MB / seg novamente (flutuando mas em média 7MB / seg)!

Parece que exFat não joga muito bem com arquivos muito grandes (várias centenas de gigabytes).

    

Answer 7

Para uma opção rápida e rápida de resgatar o disco, você pode usar um arquivo de script sh e executar o arquivo com "sh filename.sh". Ele contém esta linha mostrada, basta repetir "sudo ddrescue" e "sleep 3" mais algumas vezes, o sono é usado para fazer a unidade descansar por alguns segundos, pode ser bom por alguns motivos:

#! /bin/sh -e  
sudo ddrescue -d -r0 -e +0 -T 1s -n /dev/drivepartition file.img log.logfile 
sleep 3

O -r0 é sem respostas. O -e +0 é para sair em 1 erro. O -T 1s sai com 1 segundo de falha de leitura. Existem opções que podem ser usadas como -d para direct e -n para nenhum raspar que possa acelerar.

Você pode usar -R depois de terminar com a opção -A uma vez, que irá reverter e remover todos os erros e começar de novo para trás. Significa que vai ler erros de maneira diferente.