salvando dados de uma unidade com falha

Question

Um HDD externo de 3½ "parece estar em perigo de falhar - está fazendo assinalar sons quando ocioso .

Adquiri uma unidade de substituição e quero saber qual é a melhor estratégia para obter os dados da unidade duvidosa com a melhor chance de salvar o máximo possível.

Existem alguns diretórios que são mais importantes que outros. No entanto, acredito que escolher e escolher diretórios reduz minhas chances de salvar a coisa toda. Eu também teria que montá-lo, despejar uma listagem de arquivos e, em seguida, desmontá-lo para poder efetivamente priorizar diretórios. Adicionando o fato de que é demorado fazer isso, estou me afastando dessa abordagem.

Eu considerei apenas usar dd , mas não sei como ele lida com erros de leitura ou outros problemas que podem impedir que apenas algumas partes dos dados sejam resgatadas ou que possam ser superadas com algumas tentativas, mas não tantos que colocam em risco que outras partes do disco não sejam salvas. Eu acho que seria ideal fazer um único passo para obter o máximo possível e depois voltar a tentar qualquer coisa que tenha sido perdida devido a erros.

É possível que copie mais lentamente? pausar cada x MB / GB - seria melhor do que apenas executar a operação com inclinação total, por exemplo, para evitar problemas de superaquecimento?

Para a multidão "where is your backup": essa é a minha unidade de backup, mas também contém alguns itens não críticos e volumosos, como música, que não são backups, ou seja, não são armazenados em backup.

A unidade não exibiu nenhum sinal claro de falha além deste som um tanto agourento. Eu tive que fsck alguns erros recentemente - inodes órfãos, contagens livres de blocos / inodes incorretos, diferenças de bitmap inode, zero dtime em inodes excluídos; cerca de 20 erros em todos.

O sistema de arquivos da partição é ext3.

    

Answer 1

Você pode usar ddrescue ou dd_rescue ou myrescue para clonar o disco com falha , sem abortar em qualquer setor ilegível. (O Myrescue é menos configurável, mas tem uma melhor estratégia padrão, pois tenta pular regiões ilegíveis.) Isso copiará tudo, incluindo o espaço em branco, e não permitirá que você defina prioridades. No entanto, essa abordagem de baixo nível tem uma vantagem sobre as ferramentas no nível do sistema de arquivos: se um diretório é ilegível, você ainda pode recuperar os arquivos que ele contém pesquisando a imagem bruta com ferramentas como foremost , magicrescue , photorec incluído testdisk , etc.

    

Answer 2

Não há como saber a melhor das suas opções sem saber exatamente o que está errado com a unidade. Se é uma falha mecânica, evitando aquecê-lo pode ajudar, mas se é devido a erros nos dados do servo, o calor não é susceptível de importar.

Eu começaria imediatamente a copiar os dados exclusivos para a nova unidade com rsync . rsync permite pausar, retomar e reiniciar conforme necessário até que todos os dados sejam removidos.

Em seguida, eu executaria uma limpeza de dados na unidade. Eu assumo do sistema de arquivos ext3 que você está executando o Linux, então tente isto:

# umount /dev/sdX
# badblocks -n /dev/sdX

(Desmontar a unidade primeiro é importante.)

Isso lerá todos os setores do disco e os gravará de volta sem alteração. Isso forçará o firmware da unidade a verificar todos os setores em busca de erros e a remapear os setores defeituosos que encontrar. Essa é a parte mais importante do que o caro programa SpinRite faz. Aumente para isso somente se badblocks falhar e você ainda não tiver obtido todos os dados exclusivos da unidade: o SpinRite tenta mais do que badblocks faz.

    

Answer 3

Se o disco estiver a ponto de morrer, primeiro certifique-se de fazer um clone tão bom quanto possível (veja a resposta de Gilles) e somente então avance para a unidade . Dessa forma, você sempre terá pelo menos alguns dados, caso algo dê errado (o que geralmente acontece com um hardware com falha).

Se você usa ddrescue (ou dd_rescue , não tenho certeza sobre os outros), sempre é possível fazer uma cópia dos dados parcialmente clonados e do arquivo de log associado e tentar melhorá-lo executando ddrescue novamente depois de fazer algo que deveria consertar a unidade. Ele tentará ler as partes ausentes, deixando as partes bem clonadas intocadas.