Como estimar loops / tempo para a conclusão do GNU ddrescue (1.18.1) usando o status atual?

Antecedentes / Contexto:

Atualmente, estou executando o GNU ddrescue 1.18.1 para recuperar dados de um USB que sofreu uma desconexão de cabo enquanto eu escrevia uma imagem de disco virtual na partição disk2s1. Inicialmente, estou recuperando minha segunda partição (disk2s2) e observe que atingi a terceira fase (divisão). Estou colocando a imagem em um armazenamento em rede.

Questão:

Eu notei que essa fase faz um loop. Existe uma maneira de calcular o número de loops que provavelmente encontro, considerando minhas informações de status atuais (estou mostrando apenas dois erros)?

Estado:

Atualizar / Editar:

Por isso, ainda estou muito interessado em saber como estimar os loops / tempo para conclusão usando a ferramenta ddrescue. Pelos comentários, estou adicionando uma avaliação de um arquivo de log para minha partição disk2s1 como a que está sendo executada atualmente (o disk2s2 foi concluído após 14,5 horas, com uma interrupção de usuário por aproximadamente 6 horas).

Log de partição concluído

Para a partição que acabou de concluir, aqui está o resultado da inspeção do log.

Referência (notas do algoritmo ddrescue):

4 Algoritmo

O GNU ddrescue não é um derivado do dd, nem está relacionado ao dd de forma alguma, exceto pelo fato de que ambos podem ser usados ​​para copiar dados de um dispositivo para outro. A principal diferença é que o ddrescue usa um algoritmo sofisticado para copiar dados de unidades com falha, causando o menor dano possível possível.

O Ddrescue gerencia eficientemente o status do resgate em andamento e tenta resgatar as partes boas primeiro, agendando leituras em áreas ruins (ou lentas) para mais tarde. Isso maximiza a quantidade de dados que podem ser finalmente recuperados de uma unidade com falha.

O utilitário dd padrão pode ser usado para salvar dados de uma unidade com falha, mas ele lê os dados sequencialmente, o que pode desgastar a unidade sem resgatar nada se os erros estiverem no início da unidade.

Outros programas leem os dados sequencialmente, mas alternam para leituras pequenas quando encontram erros. Essa é uma péssima idéia, pois significa gastar mais tempo em áreas de erro, danificando a superfície, as cabeças e a mecânica do acionamento, em vez de sair delas o mais rápido possível. Esse comportamento reduz as chances de resgatar os bons dados restantes.

O algoritmo do ddrescue é o seguinte (o usuário pode interromper o processo a qualquer momento, mas esteja ciente de que uma unidade defeituosa pode bloquear o ddrescue por um longo tempo até que o kernel desista):

1) Leia opcionalmente um arquivo de log descrevendo o status de um resgate com várias partes ou interrompido anteriormente. Se nenhum arquivo de log for especificado ou estiver vazio ou não existir, marque todo o domínio de recuperação como não tentado.

2) (Primeira fase; Copiando) Leia as partes não tentadas do arquivo de entrada, marcando os blocos com falha como não aparados e pulando além deles. Pule também além das áreas lentas. As áreas ignoradas são tentadas posteriormente em duas passagens adicionais (antes do corte), revertendo a direção após cada passagem até que todo o domínio de recuperação seja tentado. O terceiro passe é um passe amplo, com o salto desativado. (O objetivo é delimitar erros grandes rapidamente, manter o arquivo de log pequeno e produzir bons pontos de partida para aparar). Somente áreas não experimentadas são lidas em grandes blocos. O corte, divisão e nova tentativa são feitos setor por setor. Cada setor é tentado no máximo duas vezes; o primeiro nesta etapa (geralmente como parte de uma leitura de bloco grande, mas às vezes como leitura de um único setor), o segundo em uma das etapas abaixo como leitura de um único setor.

3) (Segunda fase; Aparar) Leia adiante um setor de cada vez, a partir da borda principal do menor bloco não aparado, até encontrar um setor defeituoso. Em seguida, leia para trás um setor de cada vez, a partir da borda final do mesmo bloco, até que um setor defeituoso seja encontrado. Para cada bloco não aparado, marque os setores defeituosos encontrados como setor defeituoso e marque o restante desse bloco como não dividido, sem tentar lê-lo. Repita até que não haja mais blocos não aparados. (Grandes blocos não aparados são produzidos pela concatenação de blocos menores e, portanto, sua fração de bons dados nas bordas é menor).

4) (Terceira fase; Divisão) Leia adiante um setor por vez do centro do maior bloco não dividido, até que um setor defeituoso seja encontrado. Então, se o setor defeituoso encontrado não for o primeiro, tente retroceder um setor por vez no centro do mesmo bloco, até encontrar um setor defeituoso. Se o arquivo de log for maior que '--logfile-size', leia sequencialmente os maiores blocos não divididos até que o número de entradas no arquivo de log fique abaixo de '--logfile-size'. Repita até que todos os blocos não divididos restantes tenham menos de 7 setores. Em seguida, leia os blocos não divididos restantes sequencialmente.

5) (Quarta fase; nova tentativa) Opcionalmente, tente ler novamente os setores defeituosos até que o número especificado de passes de nova tentativa seja atingido. Todo setor defeituoso é tentado apenas uma vez em cada passo. O Ddrescue não pode saber se um setor defeituoso é irrecuperável ou se será eventualmente lido após algumas tentativas.

6) Escreva opcionalmente um arquivo de log para uso posterior.

O tamanho total do erro ('errsize') é a soma dos tamanhos de todos os blocos não aparados, não divididos e com setores defeituosos. Aumenta durante a fase de cópia e pode diminuir durante o corte, divisão e nova tentativa. Observe que, à medida que o ddrescue divide os blocos com falha, diminuindo-os, o tamanho total do erro pode diminuir enquanto o número de erros aumenta.

O arquivo de log é salvo periodicamente no disco, bem como quando o ddrescue termina ou é interrompido. Portanto, em caso de falha, você pode retomar o resgate com poucas cópias. O intervalo entre salvamentos varia de 30 segundos a 5 minutos, dependendo do tamanho do arquivo de log (arquivos de log maiores são salvos em intervalos mais longos).

Além disso, o mesmo arquivo de log pode ser usado para vários comandos que copiam diferentes áreas do arquivo de entrada e para várias tentativas de recuperação em diferentes subconjuntos. Veja este exemplo:

Salve a parte mais importante do disco primeiro. ddrescue -i0 -s50MiB / dev / arquivo de log de imagem hdc ddrescue -i0 -s1MiB -d -r3 / dev / arquivo de log de imagem hdc hdc

Em seguida, salve algumas áreas principais do disco. ddrescue -i30GiB -s10GiB / dev / arquivo de log de imagem hdc ddrescue -i230GiB -s5GiB / dev / arquivo de log de imagem hdc hdc

Agora salve o resto (não copia novamente o que já foi feito). ddrescue / dev / arquivo de log de hdimage hdc ddrescue -d -r3 / dev / arquivo de log de hdimage hdc

Embora a pergunta tenha sido feita há 10 meses, a resposta pode ser relevante porque o ciclo de recuperação ainda pode estar em execução, dependendo de alguns fatores! Sem trocadilhos.

A razão é que, a estimativa de tempo é quase impossível; no entanto, às vezes você pode ter uma idéia aproximada da seguinte forma. Uma das razões mais óbvias é que você não pode prever quanto tempo a unidade levará para ler um setor defeituoso e se você quiser que o ddrescue leia e tente novamente cada um deles, poderá demorar muito tempo. Por exemplo, no momento, estou executando uma recuperação em uma pequena unidade de 500 GB que já dura mais de duas semanas e possivelmente ainda tenho alguns dias. Mas a minha é uma situação mais complicada, porque a unidade é criptografada e, para ler qualquer coisa com êxito, certifique-se de obter todos os setores que possuem tabelas de partição, setores de inicialização e outras partes importantes do disco. Estou usando técnicas além do ddrescue para melhorar minhas chances de todos os setores defeituosos. IOW,

Por estimativa de "loops", se você quer dizer o número de tentativas, isso é algo que você determina pelos parâmetros que usa. Se você quer dizer "número total de passes", isso é facilmente determinado lendo sobre o algoritmo aqui .. > man ddrescue </ Algoritmo: Como o ddrescue recupera os dados

Vou falar especificamente com os números nas capturas de tela que você forneceu. Outras situações podem ter outros fatores que se aplicam, portanto, tome essas informações como uma orientação geral.

No exemplo que você forneceu, dê uma olhada na tela de status de execução do ddrescue. Nós obtemos a "estimativa" total do problema (domínio de resgate) por "tamanho do erro". Essa é a quantidade de dados que "ainda precisam ser lidos". Na amostra, é 345GB. A próxima linha abaixo à direita é "taxa média". Na amostra, é 583kb / s

Se a "taxa média" permanecer próxima de estável, isso significa que você tem mais 7 dias pela frente. 345 GB / (583 kb * 60 * 60 * 24) = 7,18 No entanto, o problema é que você não pode confiar nos 583kb / s. Na verdade, quanto mais você entra em recuperação, a unidade fica mais lenta, pois está lendo áreas cada vez mais difíceis e está fazendo mais tentativas. Portanto, o tempo para terminar aumenta exponencialmente. Tudo isso depende de quanto a unidade está danificada.

A amostra que você forneceu mostra que uma "leitura bem-sucedida" foi realizada há mais de 10 horas. Isso significa que ele não recebe nada da unidade por mais de 10 horas. Isso mostra que sua unidade pode ter 345 GB no valor (ou uma parte) de dados gravados. Esta é uma notícia muito ruim para você.

Por outro lado, minha segunda unidade de 500 GB, que havia começado a me dar erros "SMART", foi copiada de disco para disco (com arquivo de log em outra unidade) e toda a operação levou cerca de 8 a 9 horas. A última parte diminuiu a velocidade. Mas isso ainda é suportável. Enquanto a unidade muito ruim, como observado acima, já passou duas semanas trabalhando em 500 GB e ainda resta cerca de 4-5% a recuperar.

HTH e YMMV