DDRescue levando meses mas sem erros?

Question

Estou com dificuldades para encontrar outras pessoas com o mesmo erro e estou tentando descobrir o melhor caminho a seguir.

Eu tenho um disco rígido que estava inutilmente lento e parei de inicializar. O clone clonezilla falhou, e eu iniciei um ddrescue, usando a ferramenta de resgate do gnu incluída em um live cd do clonezilla. Ele está indo incrivelmente lento com uma média de cerca de 400 kBps para uma unidade de 2 TB, então estou estimando quase 4 meses! neste ponto. Meu último backup foi triste há cerca de 2 anos, e há muitas fotos que eu gostaria de tirar dele. A parte surpreendente é que ele resgatou cerca de 50 GB, sem erros até o momento, apesar de ter levado 3 dias. Tenho algumas perguntas sobre o melhor caminho a seguir e por que isso levaria tanto tempo, mas também não teria erros.

A unidade leva apenas uma eternidade para ser lida com sucesso, mas nunca falha, diminuindo o tempo de cópia? O disco rígido está bom, mas algo como o painel de controle do problema?

Estou muito preocupado com o provável destino do arquivo de log. Eu não posso depender do meu computador ficar estável, e o comando não está errado por quatro meses. Se eu estou falando sobre mantê-lo funcionando por semanas, eu gostaria de colocar esse arquivo de log em um pen drive. Eu originalmente pensei que estava indo para o novo disco rígido maior, mas agora eu percebo o seu provável na unidade de RAM clonezilla_live está utilizando. É seguro inserir uma unidade USB formatada, montá-la e copiar o arquivo de log e, em seguida, reiniciar o ddrescue? Será que a clonezilla reconhece que eu inseri o pendrive que não estava lá na inicialização, então posso montá-lo?

Estou assumindo que eu tentei sudo fdisk -l listar os discos e criar um diretório? sudo mkdir /logfile/usb , em seguida, montá-lo? sudo mount /dev/sdb1 /media/usb e copie?

QUALQUER feedback seria apreciado. Eu transformei um pouco no shell Unix, configurei um z-pool raid, mas sempre quando eu sabia exatamente o que estava fazendo, e não no Linux, muito menos uma versão básica.

    

Answer 1

Se alguém estiver interessado ou se deparar com uma versão arquivada disso em alguns anos. Eu esperei os dois meses, estabelecendo um arquivo de log para retomar a cópia. Por duas vezes, começou a ficar com erros de leitura (até o computador ser reiniciado) e assim que perdi a energia. Depois de meses de cópia, eu liguei o backup através de um adaptador USB para outro laptop, eu provavelmente tinha 7,5 mb de ~ 2 tb que não foi copiado (ainda tinha erros após -r3 (3 tentativas)). Foi ilegível, mas reconstruí a tabela de partições de acordo com estas instruções: link  - Eu tive que mudar o tamanho do bloco já que esta unidade é muito maior do que as unidades antigas.

Em seguida, ele trabalhou perto da perfeição. Eu fiz um disco de verificação e reparo, e reparo de permissões no utilitário de disco, e ele arrancou bem.

Real lição aprendida? Estou usando o backblaze para os arquivos realmente importantes (fotos e documentos) e um backup inicializável espelhado no local.

    

Answer 2

O ddrescue marca os setores defeituosos até a segunda fase: link

(Second phase; Trimming) Trimming is done in one pass. For each non-trimmed block, read forwards one sector at a time from the leading edge of the block until a bad sector is found. Then read backwards one sector at a time from the trailing edge of the block until a bad sector is found. Then mark the bad sectors found (if any) as bad-sector, and mark the rest of the block as non-scraped without trying to read it.

E o problema é: pode demorar muito tempo até que esta fase comece. Sua dividido em três passagens:

1. copie para a frente e marque os blocos como rescued , non-trimmed e non-tried dependendo dos tempos limite, etc.
2. copie para trás e leia todos os non-tried blocks
3. copiar para frente sem pular para preparar erros grandes para aparar

Infelizmente, ninguém pode prever quanto tempo essa fase levará, pois depende da quantidade de erros (horas, dias, semanas ou até mesmo meses, como no seu caso).

Observação: o sinalizador --retry-passes=n ( r ) é importante apenas para a quarta fase:

(Fourth phase; Retrying) Optionally try to read again the bad sectors until the specified number of retry passes is reached.

Por isso, não acelera a primeira fase com seus passes, reduzindo os retrys.

Mas você pode ver no arquivo de log ddrescue se ele marcou alguns blocos como "resgatados", então você pode esperar que ele resgate alguns ou todos os dados da unidade. Aqui está um exemplo:

#      pos        size  status
0x00000000  0x00117000  +
0x00117000  0x00000200  -
0x00117200  0x00001000  /
0x00118200  0x00007E00  *
0x00120000  0x00048000  ?

Se o arquivo de log contiver linhas com + -status, haverá esperança. Isso significa "resgatado". Mas se contiver apenas ? (não tentada) e * (não aparada), acho que você pode desistir. É claro que pode haver uma chance de o disco estar com defeito no começo, mas acho que isso é apenas uma pequena chance. Mas se você pode se dar ao luxo de rodar o ddrescue através de um segundo pc, você deve testá-lo dependendo da importância dos dados. A esperança final poderia ser substituir a cabeça / eletrônica, mas isso poderia ser caro.

Uma alternativa para analisar os logs é usar o visualizador de logs do ddrescue: link

Eu uso Parted Magic , pois ele contém a GUI do ddrescue e o visualizador de log do ddrescue.

Aqui você pode ver uma captura de tela do visualizador no meio da fase 1, passo 2 (copiar para trás):

Asetamostraaposiçãoatual.Comovocêpodever,estaunidadetemmuitospossíveissetoresdefeituosos(nestafasemarcadoscomo"não aparados") no meio.

Adicionaremos capturas de tela adicionais depois que ele atingir outras fases.

    

Answer 3

Certifique-se de que os dados ainda estão sendo copiados - verifique os arquivos de saída e certifique-se de que o tamanho deles continue aumentando. A falha dos discos rígidos tende a congelar quando você tenta copiar muitos dados deles de uma só vez.

Se parecer que não está fazendo nada, provavelmente é melhor parar a operação, depois voltar e copiar um diretório de cada vez, para que, se isso acontecer novamente, você tenha pelo menos um diretório completo. Se estiver funcionando, você pode deixá-lo por mais um ou dois dias. As estimativas de tempo são muitas vezes terrivelmente incorretas, mas definitivamente não deve demorar um mês!

Não estou familiarizado com o ddrescue, mas costumo usar o Data Rescue no trabalho, e nunca vi uma imagem completa do disco rígido concluída se não o fizer em um dia. Dito isto, é melhor copiar apenas os diretórios que você precisa (provavelmente / home), já que os aplicativos podem ser reinstalados e as configurações reconfiguradas, mas documentos e imagens não podem ser substituídos.

No que diz respeito aos arquivos de log, eu não os tocaria enquanto um utilitário de recuperação de dados estivesse em execução.