Resolvendo problemas de Bad Superblocks em partições EXT4

Publicado por Matheus Fidelis em 06/11/2015

[ Hits: 31.276 ]

Blog: http://www.nanoshots.com.br/

 


Resolvendo problemas de Bad Superblocks em partições EXT4



É comum algumas vezes no boot do sistema alguns erros serem apresentados e na investigação você acabar se deparando com vários bad superblocks.
Neste artigo abordaremos um problema recorrente de perda de trilhas e problemas de superblock em HDs e partições EXT4 no Linux.
Este problema pode acarretar falhas na montagem das partições e dispositivos e dificultar o acesso aos dados das mesmas. Para recuperar essas falhas nos blocos e restaurar o acesso aos arquivos, devemos antes fazer alguns procedimentos.

Vamos listar todos os dispositivos montados em nosso sistema e identificar a partição corrompida que queremos acessar.

# fdisk -l

 Disk /dev/sda: 698,7 GiB, 750156374016 bytes, 1465149168 sectors
 Units: sectors of 1 * 512 = 512 bytes
 Sector size (logical/physical): 512 bytes / 4096 bytes
 I/O size (minimum/optimal): 4096 bytes / 4096 bytes
 Disklabel type: gpt
 Disk identifier: 97BFC9A6-9CD0-4EB8-9526-7B6EAA7B2E61

 Device     Start    End  Sectors  Size Type
 /dev/sda1    2048  1050623  1048576  512M EFI System
 /dev/sda2   1050624 1456998399 1455947776 694,3G Linux filesystem
 /dev/sda3 1456998400 1465147391  8148992  3,9G Linux swap

 Disk /dev/sdb: 7,5 GiB, 8054112256 bytes, 15730688 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

No caso, o teste será feito na partição única do meu pendrive, identificado pelo sistema como /dev/sdb/.

# umount /dev/sdb

Vamos realizar uma verificação de filesystem para tentar limpar os erros de superblocks e tentar acessar a partição:

# fsck.ext4 -v /dev/sdb

O fsck, dependendo do estado do seu disco, tentará recuperar os superblocks danificados, caso não consiga, vamos ter que optar pelos backups dos blocos e restaurá-los manualmente. Vamos verificar os backups dos blocos da nossa partição.

# mke2fs -n /dev/sdb

mke2fs 1.42.12 (29-Aug-2014)
/dev/sdb contains a ext4 file system
last mounted on /media/tarsila/b72ba6bf-6020-4a36-aba7-d89c6c4f51f2 on Mon Nov 2 12:11:43 2015
Proceed anyway? (y,n) y
Creating filesystem with 1966080 4k blocks and 492480 inodes
Filesystem UUID: d73dd08c-0f1b-41bf-bdb0-87b4a1a644e4
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

Os blocos destacados em negrito são os blocos backupeados da partição. Agora vamos tentar restaurá-los manualmente dentro das tabelas do filesystem.

Agora vamos tentar restaurá-los um a um:

# e2fsck -b <número do superblock> /dev/sdb

Vamos criar um ponto de montagem temporário para montarmos a partição corrompida e tentar acessar seus dados:

# mkdir /mnt/temp
# mount /dev/sdb /mnt/temp


Agora repita esse processo até que consiga restaurar os blocos um a um, testando todos os blocos de backup.

Para acompanhar o processo de montagem e erros, você pode visualizar os logs de hardware com o dmesg do sistema:

# dmesg

Previamente publicado em: http://www.nanoshots.com.br/2015/11/resolvendo-problemas-de-superblocks-e.html

Outras dicas deste autor

Configurando interface de rede em servidores Red Hat e CentOS 7

Brute Force em senhas de roteadores e painéis utilizando Python

Instalando agente do Zabbix em servidores Linux

Criptografando o diretório HOME de um usuário com eCryptFS

Leitura recomendada

Problemas na instalação do Mandriva a partir de um mirror local

Papéis de parede legais e "perdidos"

Extraindo arquivos zip com sem caracteres errados (mojibake)

[rsync] Sincronizando becapes e outros dados

Smbmount e smbfs no Fedora Core 5

  

Comentários
[1] Comentário enviado por annakamilla em 07/11/2015 - 14:59h


o meu note não deu certo encheu de setor defeituoso e o ubuntu nem incia mais. tive que levar para o técnico e talvez chegue neste final de semana para a reinstação do mesmo ou a instalação de um outro linux.



[2] Comentário enviado por albfneto em 07/11/2015 - 18:28h

Se você fizer fsck mesmo que no HDD, todo, tipo

# fsck /dev/sda

mas fizer de um Boot Live, e não do Boot normal, regular do HDD, o seu HDD estará todo desmontado, é mais seguro.
não costuma perder os dados.
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨
Albfneto,
Ribeirão Preto, S.P., Brasil.
Usuário Linux, Linux Counter: #479903.
Distros Favoritas: [i] Sabayon, Gentoo, OpenSUSE, Mageia e OpenMandriva[/i].

[3] Comentário enviado por Carlos_Cunha em 10/11/2015 - 23:50h

Dica Boa!!!!
Abraço

#-------------------------------------------------------------------------------------#

"Linux é algo que me fez ter Gosto pela Informática, se tornou um Vicio" - Carlos A. P. Cunha

[4] Comentário enviado por pedrotscom em 06/04/2018 - 00:57h

Boa postagem porém o meu tá doido. Após tentar restaurar o primeiro bloco que por conhecidência é o mesmo desta postagem (aliás todos que foram listadis tenho o mesmo problema, além de outros). O meu note não para de listaruma numeração, Obs, Kali Linux em dual boot com Windows 10.

[5] Comentário enviado por pedrotscom em 06/04/2018 - 01:00h

Essa dor de cabeça ocorreu após uma atualização do sistema, agora não consigo entrar no sistema nem a pau! E detalhe, não tenho arquivos importantes no kali.



Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts