Tive uma falha no disco rígido de 500 GB há cerca de 5 dias. Usei ddrescuea partição importante há alguns dias e ela está em "Cortar blocos com falha" 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 usava o ddrescue -nparâmetro e eu reiniciei o processo algumas vezes conforme necessário (e ele parecia continuar exatamente de onde parou a cada vez).
Existe alguma maneira de acelerar esse 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 a contagem de “erros” é dolorosamente lenta, o ipos/opos está contando a quantidade de dados que precisa processar e parece estar funcionando a uma taxa de 750 MB/hora. Nesse ritmo, ele será concluído em aproximadamente 53 horas. Caramba.
Edição nº 2:Dois dias depois, ainda em execução. No entanto, há esperança. Ele passou da parte "Recortando blocos com falha" e passou para a próxima fase "Dividindo blocos com falha". Na verdade, o que deve ser tirado da visualização desta questão é que isso definitivamente leva muito tempo quando uma boa quantidade de dados/erros está envolvida. Minha única esperança é poder 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...
Responder1
Observei que usar a -nopção (no-split) junto com -r 1(tentar novamente uma vez) e definir -c(tamanho do cluster) para um valor menor pode ajudar.
Minha impressão é que a etapa de divisão é muito lenta, pois ddrescuedivide e divide novamente as áreas danificadas. Isso leva muito tempo porque ddrescuetenta restaurar porções muito pequenas de dados. Então, eu prefiro usar -n(no-split) junto com -c 64, -c 32, -c 16, aso
Provavelmente o -n(no-split) deve sempre ser usado para uma primeira passagem nas direções para frente e para trás. Parece que quanto mais os dados foram divididos, mais lenta foi a clonagem, embora eu não tenha certeza disso. Presumo que quanto maiores as áreas não tratadas, melhor será a execução ddrescuenovamente, porque mais setores contíguos serão clonados.
Como estou usando um arquivo de log, não hesito em cancelar o comando com Ctrl+ Cquando a velocidade de leitura dos dados ficar baixa.
Eu também uso o -Rmodo (Reverso) e, após uma primeira passagem, muitas vezes me proporciona 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 tratados ao executar o ddrescuecomando novamente, especialmente ao alternar -Rcomandos de clonagem direta (padrão) e reversa ( ). Não tenho certeza se o número de vezes que eles foram tentados está armazenado no arquivo de log e provavelmente o trabalho foi feito novamente, inútil.
Provavelmente o -isinalizador (posição de entrada) também pode ajudar a acelerar as coisas.
Responder2
Pode ser muito difícil ver o progresso do ddrescue, mas há outro comando incluído chamado ddrescuelog.
Um comando simples ddrescuelog -t YourLog.txtproduzirá estas 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 ddrescueestá em execução...
Responder3
Descobri que brincar com o parâmetro -K pode acelerar as coisas. Pelo que vi se o ddrescue encontra um erro ao executar com a opção -n tenta pular uma quantidade fixa de setores. Se ainda não conseguir ler, ele aumenta o dobro do tamanho. Se você tiver 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 na primeira vez.
A propósito, existe um aplicativo gráfico maravilhoso para analisar o log.
Responder4
Mais uma maneira de monitorar o progresso do ddrescue (pelo menos no Linux) é através do uso do strace.
Primeiro, encontre o PID para o processo 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, "\3101\316\335\213\217\323\343o\317\22M\346\325\322\331\3101\316\335\213\217\323\343o\317\22M\346\325\322\331"..., 512) = 512
lseek(3, 1702220261376, SEEK_SET) = 1702220261376
read(3, "\3101\316\335\213\217\323\343o\317\22M\346\325\322\331\3101\316\335\213\217\323\343o\317\22M\346\325\322\331"..., 512) = 512
lseek(4, 1702220261376, SEEK_SET) = 1702220261376
write(4, "\3101\316\335\213\217\323\343o\317\22M\346\325\322\331\3101\316\335\213\217\323\343o\317\22M\346\325\322\331"..., 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, “1702212676608” equivale à “quantidade de dados que ainda precisa ser processada naquele disco de 2 TB que você está tentando recuperar”. (Sim. Ai.) ddrescue está exibindo um número semelhante - embora como "1720 GB" - em sua saída de tela.
strace oferece um fluxo de dados de granularidade MUITO maior para você examinar; é mais uma maneira de avaliar a velocidade do ddrescue e estimar uma data de conclusão.
Executá-lo constantemente é provavelmente um plano ruim, pois competiria com o ddrescue pelo tempo de CPU. Comecei a canalizá-lo para "head" para poder pegar os primeiros 10 valores:
root@mojo:~# strace -p 4073 2>&1 | grep lseek | head
Espero que isso ajude alguém.