Os problemas que você está tendo soam muito mais extensos do que o esperado de uma simples perda de energia (mesmo durante uma atividade de gravação bastante pesada) em um dispositivo. Eu tenho que me perguntar se você está realmente tendo mais problemas no nível de interface / driver, ou uma tabela de partição corrompida ou algo desse tipo.
A partir dos sons das coisas, você pode ter exacerbado ainda mais o problema com toda a agitação que você fez ao tentar resolver o problema.
Não sei se podemos ajudar neste caso, mas não desistimos ainda.
Para o futuro, sugiro que você aprenda a seguinte técnica:
Quando você tiver problemas com uma unidade no Linux ou UNIX, normalmente você pode usar dd para fazer uma cópia de imagem de bit de todo o dispositivo para algum outro local. Encontre uma unidade que seja pelo menos tão grande quanto aquela em questão e tente um comando como: dd if=$PROBLEMATIC of=$TARGET bs=4M ... seja muito cuidadoso com as diretivas if (arquivo de entrada) e de (arquivo de saída). Deixe essa corrida. É uma boa idéia executar tail -f /var/log/messages & (ou possível variante, conforme apropriado para o seu /etc/syslog.conf) ... faça isso em segundo plano ou em outra janela. Existem versões aprimoradas de dd , que podem manipular novas tentativas e continuar com os blocos ruins de forma mais robusta ( sdd é um nome que vem à mente). Mas tente usar o comando stock GNU dd no começo.
Você pode fazer tal cópia de todo o dispositivo (/ dev / sdd, por exemplo) ou apenas a partição (/ dev / sdd1). Se você obtiver "erros de leitura ou erros semelhantes, sugere que o dispositivo possui erros físicos que impedem leituras anteriores a determinados cilindros ou, no caso de uma partição, que a tabela de partição está mutilada de alguma forma. Você pode fazer duas% diferentesdd images ... um de cada.
Aqui está o truque: faça todas as suas tentativas de fsck e mount e use suas várias outras ferramentas de recuperação, como o TCT (The Coroner's Toolkit) na imagem copiada!
Isso minimiza o tempo gasto na execução da unidade (que pode estar degradando no nível do hardware à medida que você a opera) e minimiza o impacto de tentativas de recuperação mal-sucedidas e possivelmente equivocadas. (Em algumas situações você faz uma imagem, depois outra baseada nisso e sempre opera na imagem terciária ... depende de quanto os dados valem).
Eu pessoalmente sugiro que você execute algo como hexdump ou strings para ler a imagem ... apenas deixe ela passar por um longo tempo e procure por texto simples que pareça ser um fragmento de seus dados . Eu usei grep para recuperar dados úteis (textuais) de sistemas de arquivos completamente desconfigurados. No caso eu não estou sugerindo isso como heroísmo de recuperação de dados ... mas como uma verificação de sanidade. Se você percorrer 10s de megabytes ou alguns gigabytes de dados e não vir nenhum texto reconhecível ... então você provavelmente tem um caso perdido ou fez algo muito errado (você estava realmente cuidado sobre aqueles se = e de = opções?).
Não sei se isso ajudará você com o esforço atual. Mas aprender esses truques agora e eles definitivamente vão fazer sua próxima incursão na recuperação de dados muito menos assustador. (Sim, pratique em um sistema saudável uma ou duas vezes - use um editor hexadecimal e tente adicionar sua própria corrupção criativa aqui e ali - à CÓPIA, é claro! Então tente consertá-lo).
Ah, e este é realmente um bom momento para revisar seus planos e procedimentos de backup e recuperação de dados (ou fornecer um aconselhamento melhor para seu cliente / colega / cliente / amigo / o que for).