Há dois dias, comecei a recuperação de um disco rígido de 1 TB com defeito, que me foi entregue com a esperança de poder recuperar a maior parte dele por um preço barato.
No início ele se comportou de forma irregular, muitas vezes sendo desconectado repentinamente e fazendo barulhos assustadores, com uma velocidade de cópia variando entre alguns KB por segundo e cerca de 50 MB por segundo (era um dia quente, tentei evitar o superaquecimento com uma almofada de resfriamento de laptop embaixo e um bloco de resfriamento por cima, que eu trocava a cada hora ou mais). Depois, durante a primeira noite, tornou-se mais estável, mas a velocidade média de cópia caiu significativamente, para cerca de 3-4MB/s. Agora, tendo recuperado 250 GB, caí para cerca de 400 KB/s em média, o que é dolorosamente lento (pelo menos não parece diminuir ainda mais).
Então minhas perguntas são:
- Estou fazendo essa recuperação para uma partição NTFS, que, pelo que li bem tarde no processo (noeste guia francês), não é recomendado, pois pode retardar consideravelmente a recuperação. Isso (ainda) é verdade e, em caso afirmativo, por quê?
- Ou isso é coisa do passado, quando o driver NTFS para Linux não estava maduro o suficiente? (Estou usando o DVD ao vivo do Knoppix mais recente, copiado para um cartão de memória, pois ele não inicializava com êxito a partir de um DVD-RW.)
- Valeria a pena converter a partição para um formato nativo do Linux como Ext4 neste estágio? Quero dizer, isso melhoraria significativamente a velocidade de cópia?
- Ou é normal experimentar tal lentidão com uma unidade com falha, após a primeira passagem onde a maioria dos setores “saudáveis” já foram recuperados? (Os parâmetros SMART estão piorando, o “resultado geral do teste de autoavaliação de saúde” passou de “APROVADO” para “REPROVADO”, o número de setores realocados passou de 144 para 1360.)
- Há algo mais que eu possa fazer para melhorar a taxa de recuperação e/ou a velocidade de recuperação?
- Existem opções nas
ddrescuequais eu poderia tentar com algum benefício real?
Fiz as primeiras execuções com este comando:
ddrescue -n -N -a500000 -K1048576 -u /dev/sdc /media/sda1/Hitachi1TB /media/sda1/Hitachi1TB.log
(As opções -n& -Nsupostamente ignoram as fases de raspagem e corte - embora eu não tenha certeza em que ponto do processo essas ações são tentadas pelo programa e se isso é realmente útil para contorná-las. Então especifiquei uma velocidade mínima de cópia de 500.000 bytes por segundo, e um valor de 1MB para “tamanho inicial para pular em caso de erro de leitura”, tentando copiar o mais rápido possível as áreas que ainda estão íntegras ou de fácil acesso. O -ué para “unidirecional”: em uma recuperação anterior com. outro HDD, copiar no sentido inverso com o -Rswitch pareceu melhorar as coisas, mas com este parece causar estragos, e aparentemente é mais estável com esse switch.)
Agora, depois de completar uma passagem, removi a maioria desses parâmetros, mantendo apenas o -u. Tentei a -dopção em algum momento (“usar acesso direto ao disco”), mas nada foi copiado, o “tamanho do erro” cresceu muito rapidamente.
Responder1
Para completar meus comentários acima (desculpem os inconvenientes/inconsistências formais): eu diria que valeu a pena, embora não entenda bem o porquê. A segunda tentativa, recuperando para uma partição Ext4, teve uma taxa de cópia significativamente maior no início (cerca de 90 MB/s em média, enquanto eu só tive cerca de 50 MB/s na melhor das hipóteses para a primeira tentativa, recuperando para uma partição NTFS) , e sem erros ou mesmo lentidão. Mas então, depois de copiar cerca de 165 GB (mais cedo do que antes), ele ficou muito instável e desacelerou, fez barulhos de cliques e zumbidos novamente (foi um período muito quente que não ajudou - tentei esfriar para baixo o máximo possível, usando uma almofada de resfriamento de laptop abaixo e um pacote de congelamento por cima, trocado a cada hora ou mais); Tentei várias vezes (às vezes voltava a uma taxa de 120 MB/s por alguns segundos e depois voltava a 0), mas tive que abandoná-la depois de um tempo.
Aqui está um ddrescueviewmapa da primeira recuperação:
Há um padrão interessante, com faixas de dados facilmente recuperados alternando com dados muito lentos ou ilegíveis.[Pelo que sei, parece indicar que uma cabeça entrou em contato com um prato, danificando a superfície e liberando poeira magnética, que então se espalhou com a força centrífuga. E como a trilha do servo (que contém informações essenciais para o processo de inicialização) está localizada na borda externa do disco rígido (é um Hitachi 1 TB de 3,5"), parte dessa poeira pode ter chegado até ela, dificultando o acesso, o que poderia explicar os ruídos de clique frequentes na inicialização.](Corrija-me se estiver errado.) => [EDIT 20200501] Isso estava errado, na verdade, esse padrão normalmente indica que um cabeçote da unidade falhou completamente e não está mais lendo nada, os dados nos pratos ainda podem ser legíveis neste ponto, mas seria necessária a substituição do conjunto da pilha principal, que somente um laboratório especializado em recuperação de dados pode realizar com segurança.
Aqui está um ddrescueviewmapa da segunda recuperação:
Assim, o disco rígido tornou-se muito instável e a recuperação cada vez mais difícil após cerca de 165 GB, mas antes disso a taxa de cópia era consistentemente alta, sem áreas ignoradas. Mais tarde, usei o ddru_ntfsbitmapmétodo, nas últimas tentativas, de modo que o espaço não alocado foi praticamente ignorado.
Aqui está um ddrescueviewmapa do arquivo de log criado com ddru_ntfsbitmap, mostrando as áreas do disco rígido que contêm dados reais em verde e o espaço livre em cinza:
Felizmente, a maioria dos dados reais foi localizada no primeiro trimestre e recuperada com sucesso. Agora ainda preciso combinar as partes boas dessas duas imagens e extrair os arquivos reais, provavelmente com o R-Studio (o melhor software de recuperação de dados que experimentei).
Mais tarde descobri uma coisa interessante e peculiar em relação à minha pergunta inicial (acho que deveria ter colocado isso como um comentário, de acordo com as regras formais, mas teria demorado muito e não poderia ter fornecido capturas de tela) .
Tentei copiar as áreas resgatadas da imagem 2, na partição Ext4, que estavam faltando na imagem 1, para essa imagem 1, na partição NTFS {1} , o que deveria ter sido feito em uma taxa muito alta (entrada e saída estando em um HDD saudável de 2 TB), ainda assim obtive uma velocidade média de apenas 660 KB/s, muito próxima da velocidade da recuperação inicial em um estágio posterior, quando fiquei preocupado o suficiente para fazer essa pergunta em primeiro lugar. ..
Comando usado (arquivo de log para imagem 2 usado como arquivo de log de domínio):
ddrescue -m [image2.log] [image2] [image1] [image1.log]
Captura de tela:
Então parei e fiz o contrário: copiei as áreas resgatadas da imagem 1 (NTFS) que faltavam na imagem 2 (Ext4), para aquela imagem 2 — e agora a taxa de cópia era de cerca de 43.000 KB/s ou 43 MB/s em média (talvez um pouco mais lento do que o esperado para uma cópia no mesmo HDD, para um Seagate 2 TB que tem uma velocidade máxima de gravação próxima de 200 MB/s, portanto deve ser capaz de atingir cerca de 100 MB/s para um copiar de uma partição para outra, mas ainda quase 100× melhor que a primeira tentativa). Qual seria a explicação para tamanha discrepância?
Comando usado (arquivo de log para imagem 1 usado como arquivo de log de domínio):
ddrescue -m [image1.log] [image1] [image2] [image2.log]
Captura de tela:
Percebi que os arquivos de imagem em ambas as partições tinham um “tamanho em disco” {2} correspondente à quantidade de dados que foram realmente gravados, muito distante do tamanho total (1 TB ou 931,5 GB), embora eu não tivesse Use a -Sopção (“usar gravações esparsas para arquivos de saída”). A imagem 2 (após ser completada com áreas extras resgatadas da imagem 1) tem um “tamanho em disco” de 308,5 GB, enquanto a imagem 1 tem um “tamanho em disco” de 259,8 GB. Poderia estar relacionado com a taxa de cópia lenta, se o driver Linux NTFS de alguma forma tiver problemas para lidar com escritas esparsas? E como é que todo o tamanho não foi alocado assim que os setores no final foram escritos, considerando que eu não usei essa -Sopção?
Tentei usar o -pswitch (“preallocate”) logo no início do processo, pensando que seria “mais limpo”, mais direto, mais fácil de lidar caso algo desse errado (se a recuperação precisasse ser recuperada). ..), mas tive que parar porque era muito longo e queria começar o mais rápido possível (aparentemente ele grava dados vazios em vez de simplesmente alocar os setores necessários). Então imaginei que, usando a -Ropção (“reverso”) temporariamente, ele gravaria os últimos setores no arquivo de saída, alocando assim o tamanho total como eu pretendia; de fato, resultou no aumento do tamanho do arquivo de saída para 931,5 GB, mas o “tamanho no disco” era na verdade bem menor (percebi isso mais tarde, ao acessar o HDD usado para aquela recuperação no Windows e ver a quantidade anormalmente alta de espaço livre). espaço).
________________
{1} Ainda não entendo como a segunda tentativa de recuperação poderia produzir um resultado muito melhor para os primeiros 100 GB ou mais, apesar do fato de que o status de integridade do disco rígido havia diminuído nesse meio tempo. [EDIT 20200501] => Possivelmente é por causa do a500000parâmetro utilizado inicialmente, que pulou áreas para as quais a velocidade de leitura estava abaixo do limite de 500KB/s. Sem essa opção, na segunda vez, ele leu imediatamente as áreas mais lentas. Na verdade, essas áreas mais lentas estavam associadas a uma cabeça fraca, por isso ainda é intrigante que esta cabeça com defeito tenha conseguido obter tantos dados na segunda vez, embora já tivesse mostrado sinais de mau funcionamento. Eu ainda estou aprendendo...
{2} A propósito, a palavra “disco” deve ser substituída, tanto em sistemas Windows quanto em Linux, pois existem unidades de armazenamento de dados que não são “discos”...
Responder2
Você pode querer copiar a imagem do disco primeiro comddcomando
sudo dd bs=[tamanho_do_bloco] contagem=[NofBlocks] if=[arquivo_de_entrada] de=[arquivo_de_saída]
onde
[in_file] - pode ser o disco quebrado, digamos /dev/sdd2
[out_file] – localização do arquivo de imagem de saída.
- Monte a imagem e tente recuperá-la.