☰

ext3 criptografado danificado; como proceder?

tag-icon • tag-icon encryption data-recovery fsck
ext3 criptografado danificado; como proceder?

Minha partição inicial em uma instalação wheezy do Debian é um volume LVM criptografado. É ext3. Hoje cedo, recebi uma mensagem estranha em uma janela do terminal sobre uma tentativa de gravação em um arquivo em minha /homeárvore que falhou devido a um sistema de arquivos somente leitura. Reinicializei e acabei com uma mensagem de erro dizendo /dev/sda1 is reported as clean. fsck.ext3, que é executada automaticamente e informa que não existe um dispositivo como esse /dev/mapper/sda1_crypte informa o código de saída 8. Fui levado para um shell de manutenção e informado de que houve uma tentativa de gravar um log no /var/log/fsck/checkfs.

Esse log 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 IGNOREDmensagens passaram, seguidas por

too many blocks in Inode somenumberhere

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

Em seguida, produz

Pass 1B: Rescanning for multiply claimed blocks

Depois de um tempo, consegui uma parede de

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

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

Então eu tenho uma série de 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 foi interrompido com um aviso de que o sistema de arquivos ainda apresentava erros.

Minhas perguntas são:

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

  2. O que posso/devo fazer agora?

  3. Eu já fiz a coisa errada?

  4. Alguém vai me abraçar até que o tremor pare?

EDITAR

Também perguntei na minha lista de discussão local do LUG. O conselho que recebi foi tirar uma imagem da unidade com o ddrescue e executar o fsck em uma cópia dessa imagem. Isso parece sensato e improvável que piore as coisas. Então, esse é o atual plano de ataque, enquanto se aguarda sugestões melhores.

Responder1

Parece que o próprio disco rígido está com problemas. ("leitura curta", etc.) Nesse caso, dmesg | tailprovavelmente mostrará alguns erros de E/S.

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

A sugestão de espelhar o disco também é boa. É uma versão "leve" da badblocks -nverificação, porque, ao forçar o disco a ler todos os setores, pode fazer com que o disco realoque blocos problemáticos, como badblocks -nfará. badblocks -né mais eficaz porque setores duvidosos podem ser pouco legíveis e apenas serem mostrados no disco como ruins o suficiente para serem movidos ao tentar gravar neles. Ainda assim, se o disco tiver vida suficiente para sobreviver a um resgate, a passagem de leitura extra não será suficiente para finalizá-lo.

Não tenho muita esperança de que a execução fsckna imagem do disco recupere tudo. É quase certo que você perderá setores nesse processo, o que significa que alguns arquivos ficarão ilegíveis ou corrompidos além do uso. Um JPEG será parcialmente decodificado com dados corrompidos, por exemplo, mas um JPEG com ⅔ inferior cortado pode não ser útil para você.

Meus dados estão torrados?

Possivelmente, possivelmente não. Às vezes, o badblocks -npasse pode resolver o problema. Se isso acontecer, você ainda precisará substituir o HDD, já que um disco só pode ficar em um estado tão ruim se estiver quase morto para começar.

Eu já fiz a coisa errada?

Além de esquecer o significado da palavra “rigoroso”, não. :)

Responder2

Esperamos que você tenha uma imagem de backup atual para restaurar.

Eu faria um backup limitado AGORA de tudo que você deseja preservar e depois verificaria se o disco ainda pode ser usado. Um truque que eu costumava usar era usar o dispositivo de partição RAW e dd-lo para /dev/null.....com uma opção apropriada, uma área que não pudesse ser lida seria identificada.

informação relacionada