ext3 criptografado danificado; como proceder?

5

Minha partição home em uma instalação wheezy do Debian é um volume LVM criptografado. É ext3. Hoje cedo, eu tive uma mensagem estranha em uma janela de terminal sobre uma tentativa de gravar em um arquivo em minha árvore /home com falha devido a ter um sistema de arquivos somente leitura. Eu reiniciei e terminei com uma mensagem de erro dizendo /dev/sda1 is reported as clean. fsck.ext3 , que é executado automaticamente e relata que não existe tal dispositivo como /dev/mapper/sda1_crypt e relata o código de saída 8. Eu caí em um shell de manutenção e disse que havia uma tentativa de gravar um log para /var/log/fsck/checkfs .

Esse registro diz:

[Timestamp]

fsck from util-linux 2.20.1
/dev/mapper/sda1_crypt: Super blocks need_recovery flag is clear, but journal has data.
/dev/mapper/sda1_crypt: Run journal anyway

/dev/mapper/sda1_crypt: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY
     (i.e., without -a or -p options)
fsck died with exit status 4

eu corri

$ fsck -vnM /dev/mapper/sda1

Um monte de illegal block #nnnn (mmmmmmmmm) in inode ppppppp IGNORED mensagens passou, seguido por

too many blocks in Inode somenumberhere

Em seguida, execute passes adicionais para resolver os blocos reivindicados por mais de um inode

Em seguida, exibe a saída

Pass 1B: Rescanning for multiply claimed blocks

Depois de um tempo, recebi uma parede de

Illegal block number passed to ext2fs_test_block_bitmap somenumberhere for multiply claimed block map

Estes foram seguidos por 2 Multiplique os blocos reivindicados no nó I de outro número: [listas de números de 5 e 8 blocos]

Então eu tenho várias estrofes como

[ 3828.181915] ata1.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 3828.182462] ata1.01 BMDMA stat 0x64
[ 3828.183810] ata1.01 failed command: READ DMA EXT
[ 3828.185889] ata1.01 cmd 25/00:08:08:10:9c/00:00:29:00:00/f0 tag dma 4096 in
[ 3828.185891] res 51/40:00:09:10:9c/40:00:29:00:00/f0 Emask 0x9 (media error)
[ 3828.190071] ata1.01 status: { DRDY ERR }
[ 3828.192153] ata1.01 status: { UNC }

Estes foram seguidos por

[ 3830.509338] end_request: I/O error, deb SDA, sector 698093577
[ 3830.509841] Buffer I/O error on device dm-3, logical block 87261184
Error reading block 87261184 (Attempt to read block from filesystem resulted in short read) while reading I node and block bitmaps. Ignore error? no

fsck.ext3: Can't read an block bitmap while retrying to read bitmaps for /dev/mappersfa1_crypt

/dev/mapper/sda1_crypt: ******* WARNING: Filesystem still has errors *******

e2fsck: aborted

/dev/mapper/sda1_crypt: ******* WARNING: Filesystem still has errors *******

E o abortou com um aviso de que o sistema de arquivos ainda tinha erros.

Minhas perguntas são:

  1. Meus dados são torrados? (Minha rigorosa política de backup não foi rigorosamente seguida ultimamente; estou sendo punida pelo universo, tenho certeza.)

  2. O que posso / devo fazer agora?

  3. Já fiz a coisa errada?

  4. Alguém me segurará até que o tremor pare?

EDITAR

Eu também perguntei na minha lista de discussão local do LUG. O conselho que obtive foi tirar uma imagem da unidade com o ddrescue e executar o fsck em uma cópia dessa imagem. Isso parece sólido e improvável para piorar as coisas. Então, esse é o plano atual de ataque, aguardando sugestões melhores.

    
por vanden 11.05.2014 / 00:45

2 respostas

7

Parece que o próprio disco rígido está com problemas. ("short read", etc.) Em caso afirmativo, dmesg | tail provavelmente mostrará alguns erros de E / S.

Outra maneira de verificar isso é executar badblocks -n na partição do problema. Ou melhor, no disco inteiro. O que quer que você teste, precisa ser desmontado. Isso levará horas em um disco grande e moderno. Se houver alguma coisa na (s) partição (ões) que você não pode viver sem, copie-a para uma mídia removível ou um volume de rede primeiro.

A sugestão para espelhar o disco também é boa. É uma espécie de versão "lite" do badblocks -n check, porque forçando o disco a ler em todos os setores, ele pode fazer com que o disco realoque os blocos de problemas, como badblocks -n . badblocks -n é mais eficaz porque os setores duvidosos podem ser pouco legíveis e só podem ser mostrados no disco como ruins o suficiente para serem movidos ao tentar escrever para eles. Ainda assim, se o disco tiver vida suficiente para sobreviver a um resgate, o passe de leitura extra não será suficiente para finalizá-lo.

Não tenho muita esperança de que executar fsck na imagem do disco recupere tudo. Você quase certamente perderá setores nesse processo, o que significa que alguns arquivos ficarão ilegíveis ou corrompidos além do uso. Um JPEG decodificará parcialmente com dados corrompidos, por exemplo, mas um JPEG com a parte inferior cortada pode não ser útil para você.

Is my data toasted?

Possivelmente, possivelmente não. O badblocks -n pass às vezes pode corrigir o problema. Em caso afirmativo, você ainda precisa substituir o HDD, pois um disco só pode entrar em um estado tão ruim por estar quase morto para começar.

Did I do the wrong thing already?

Além de esquecer o significado da palavra "rigorosa", não. :)

    
por 11.05.2014 / 01:20
0

Espero que você tenha uma imagem de backup atual da qual restaurar.

Eu teria um backup limitado AGORA de qualquer coisa que você deseja preservar e, em seguida, verifique se o disco ainda é utilizável. Um truque que costumava usar era usar o dispositivo de partição RAW e inseri-lo em /dev/null…. Com uma opção apropriada, uma área que não pudesse ser lida seria identificada.

    
por 11.05.2014 / 02:12