Arquivos de salvamento do sistema de arquivos ext3 com erros físicos

Question

Eu tenho um disco de um laptop Linux com arquivos que o infeliz proprietário gostaria de ter de volta se possível (sem soluções de backup, por favor). Eu não tive nada a ver com isso antes. O disco é reconhecido pelo OS X e pelo Ubuntu 11.10:

root@ubuntu1110:~# fdisk -l /dev/sdc

Disk /dev/sdc: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x80d549b4

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1   *          63   953602334   476801136   83  Linux
/dev/sdc2       953602335   976768064    11582865    5  Extended
/dev/sdc5       953602398   976768064    11582833+  82  Linux swap / Solaris

Isso parece consistente com uma instalação de estoque de uma distribuição Linux com uma partição swap.

Infelizmente, algumas mensagens bastante desagradáveis aparecem no dmesg, depois que o Ubuntu diz que não pode montar a partição sdc1:

[  181.228092] sd 6:0:0:0: [sdc] 976773168 512-byte logical blocks: (500 GB/465 GiB)
[  181.232176] sd 6:0:0:0: [sdc] Write Protect is off
[  181.232181] sd 6:0:0:0: [sdc] Mode Sense: 21 00 00 00
[  181.236359] sd 6:0:0:0: [sdc] No Caching mode page present
[  181.236364] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[  181.246696] sd 6:0:0:0: [sdc] No Caching mode page present
[  181.246707] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[  182.835915]  sdc: sdc1 sdc2 < sdc5 >
[  182.854199] sd 6:0:0:0: [sdc] No Caching mode page present
[  182.854204] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[  182.854208] sd 6:0:0:0: [sdc] Attached SCSI disk
[  218.250174] sd 6:0:0:0: [sdc] Unhandled sense code
[  218.250179] sd 6:0:0:0: [sdc]  Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
[  218.250182] sd 6:0:0:0: [sdc]  Sense Key : Hardware Error [current] 
[  218.250187] Info fld=0x0
[  218.250188] sd 6:0:0:0: [sdc]  Add. Sense: No additional sense information
[  218.250193] sd 6:0:0:0: [sdc] CDB: Read(10): 28 00 00 00 01 08 00 00 08 00
[  218.250200] end_request: I/O error, dev sdc, sector 264
[  218.250206] Buffer I/O error on device sdc, logical block 33
[  255.398994] sd 6:0:0:0: [sdc] Unhandled sense code
[  255.399029] sd 6:0:0:0: [sdc]  Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
[  255.399032] sd 6:0:0:0: [sdc]  Sense Key : Hardware Error [current] 
[  255.399037] Info fld=0x0
[  255.399038] sd 6:0:0:0: [sdc]  Add. Sense: No additional sense information
[  255.399053] sd 6:0:0:0: [sdc] CDB: Read(10): 28 00 00 00 01 08 00 00 08 00
[  255.399061] end_request: I/O error, dev sdc, sector 264
[  255.399066] Buffer I/O error on device sdc, logical block 33
[  281.340599] sd 6:0:0:0: [sdc] Unhandled sense code
[  281.340609] sd 6:0:0:0: [sdc]  Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
[  281.340618] sd 6:0:0:0: [sdc]  Sense Key : Hardware Error [current] 
[  281.340653] Info fld=0x0
[  281.340655] sd 6:0:0:0: [sdc]  Add. Sense: No additional sense information
[  281.340659] sd 6:0:0:0: [sdc] CDB: Read(10): 28 00 00 00 00 67 00 00 08 00
[  281.340667] end_request: I/O error, dev sdc, sector 103
[  281.340739] EXT3-fs (sdc1): error: can't read group descriptor 4

Minha teoria atual é que o disco rígido ficou sem blocos sobressalentes, então agora um bloco ruim foi introduzido e está na área usada na montagem da partição. Isto é confirmado por dd:

root@ubuntu1110:~# dd if=/dev/sdc1 of=/dev/null bs=10240 conv=noerror
dd: reading '/dev/sdc1': Input/output error
2+0 records in
2+0 records out
20480 bytes (20 kB) copied, 44.7084 s, 0.5 kB/s
dd: reading '/dev/sdc1': Input/output error
9+1 records in
9+1 records out
96256 bytes (96 kB) copied, 162.933 s, 0.6 kB/s
dd: reading '/dev/sdc1': Input/output error
9+1 records in
9+1 records out
96256 bytes (96 kB) copied, 180.083 s, 0.5 kB/s

Bloqueios incorretos taxa de transmissão muito cedo e muito lenta, ainda mais tarde no processo (não mostrado)

Meu problema agora é como me aproximar daqui. Eu preciso de algo que possa ler de um sistema de arquivos ext2 / ext3 quebrado para que possamos copiar os arquivos que ainda estão no disco, e eu não fiz muita administração do sistema Linux nos últimos 15 anos, então não sei os termos corretos para pesquisar .

Eu provavelmente poderia copiar uma imagem de disco durante a noite, mas a informação "este bloco é ruim" é perdida.

Que tipo de programa seria útil nesta situação?

    

Answer 1

Primeira regra de recuperação de disco: Pare de usar o disco. Se houver problemas de hardware (como queda de cabeça), qualquer uso pode causar mais danos; se o sistema de arquivos estiver corrompido, qualquer mount ou fsck terá o potencial de torná-lo pior. (Mesmo no modo ro ! Observe que mount -t ext3 -o ro irá tentar reproduzir o diário e gravar no disco!)

Use dd_rescue ou ddrescue para copiar o máximo possível da imagem do disco para outro sistema, coloque o disco fora e faça cópias da imagem. Realize todas as tentativas de recuperação de uma das cópias.

Agora, dei algumas dicas para a recuperação de dados aqui . Resumindo,

• O layout da sua partição parece ainda válido. Se não fosse, você poderia usar TestDisk ou gpart para tentar recuperar a tabela de partições.
• e2fsck pode ser capaz de recarregar o sistema de arquivos em um estado montável. Colocará inodes pendentes em /lost+found e reportará erros.
• ext4magic tenta recuperar dados de metadados registrados no diário. Se os arquivos podem ser recuperados da revista, é uma questão de sorte e acaso, mas é possível que haja coisas lá.
• O The Sleuth Kit pode analisar e gerar a maioria das estruturas do sistema de arquivos. Se você sabe muito sobre o layout interno do sistema de arquivos e tem um editor hexadecimal à mão (para fazer coisas como "superbloco é corrupto e superbloco de backup está desatualizado, mas eu posso pegar dados suficientes para reconstruir eu mesmo"), IMO é a ferramenta mais útil para recuperar a maioria dos dados.
• O PhotoRec tentará encontrar sequências de bytes parecidas com arquivos. Está apenas adivinhando o início / fim do arquivo, não vai saber nada sobre a estrutura do sistema de arquivos, como diretórios e nomes de arquivos, e não encontrará arquivos fragmentados.

Answer 2

Assumindo que você passou por todos os prós e contras habituais dos serviços de recuperação de dados profissionais, você pesou o custo dos dados perdidos contra o risco de fazer isso sozinho ... o usuário decidiu que os dados não valem $ 000 mas vale a pena horas e horas do seu tempo ...

Veja o que eu faria.

• Tente fazer a imagem dd do dia para o dia e defina o disco de lado
• use o Testdisk no arquivo de imagem link

Se eu consegui 0.5kB / s consistentemente no dd, provavelmente não vale a pena tentar isso.

Você poderia executar o Testdisk no disco. pode funcionar. Se o custo / risco não determina outras opções, então ... é a sua chamada. Pode funcionar.

Em geral, seriamente, esses problemas são um campo minado político. O usuário tem vergonha de pedir a seus colegas de trabalho para reenviarem seus arquivos, ou eles não querem encarar o gerenciamento deles e admitir que eles não executaram backups regulares, e agora eles precisam gastar milhares em recuperação de dados. Eles estão esperando que talvez você possa consertar isso para eles e fazer com que todos os seus problemas desapareçam ... e se a unidade se autodestruir no processo. ELES VÃO JOGAR SOB A ÔNIBUS para salvar sua própria pele.