Recuperação via fsck

4

Recentemente, fui atingido pelos problemas da AWS na Irlanda, perdi um volume e preciso tentar uma recuperação.

Eu anexei o volume do problema para / dev / sdf -

Sou completamente novo nisso, não tenho certeza do que está acontecendo, mas isso não parece promissor > >

> sudo fsck /dev/sdf
fsck from util-linux-ng 2.17.2
e2fsck 1.41.12 (17-May-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/sdf

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 

Ao executar fdisk -l / dev / sdf ... eu recebo > >

sudo fdisk -l /dev/sdf

Disk /dev/sdf: 8589 MB, 8589934592 bytes
255 heads, 63 sectors/track, 1044 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/sdf doesn't contain a valid partition table

mais informações Após a execução:

> sudo mke2fs -n /dev/sdf 
Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632 

Alguém pode fornecer ajuda, não muita experiência com a execução do fsck.

Obrigado antecipadamente!

EDITAR > > Encontrou a resposta:

> sudo mount -t xfs -o /dev/sdf /mnt/test-ebs
XFS: Filesystem sdk has duplicate UUID - can't mount
> sudo mount -t xfs -o nouuid /dev/sdf /mnt/test-ebs
mount: Structure needs cleaning
> sudo xfs_repair -L /dev/sdf
..
.
connected inode 9625284, moving to lost+found
disconnected inode 9625285, moving to lost+found
disconnected inode 9625286, moving to lost+found
disconnected inode 9625287, moving to lost+found
disconnected inode 17957583, moving to lost+found
disconnected dir inode 17977810, moving to lost+found
disconnected dir inode 17977835, moving to lost+found
Phase 7 - verify and correct link counts...
resetting inode 368465 nlinks from 2 to 4
resetting inode 17977810 nlinks from 0 to 2
..

Em seguida, executei novamente o sudo mount -t xfs -o nouuid / dev / sdf / mnt / teste-ebs

Todos trabalhando agora!

Felicidades

    
por williamsowen 10.08.2011 / 12:34

1 resposta

2

Antes de executar o fsck, faça uma imagem do sistema de arquivos e depois trabalhe nele. Então, se algo der errado, você terá o original. Não trabalhe no próprio sistema de arquivos.

Além disso, é altamente improvável que sdf seja o sistema de arquivos, sdf seja a própria unidade e o sistema de arquivos esteja em alguma partição. Execute fdisk -l / dev / sdf para ver as partições, o try fsck em / dev / sda1, etc.

Para preparar uma imagem do dispositivo:

# dd if=/dev/sdfX of=sdfX.img

em que X é o número da partição, conforme listado em fdisk -l.

Em seguida, execute fsck na imagem: EDIT: (note que você não pode usar o fsck diretamente, em vez disso você precisa dizer ao fsck que tipo de sistema de arquivos é este)

# fsck.ext3 sdfX.img

Depois que o fsck consertar a partição, monte-a como:

# mount -o loop sdfX.img /mnt/somedir

De acordo com o seu comentário, o fdisk não lista nenhuma partição - isso pode significar que a tabela de partição também foi perdida.

Mais uma vez, faça uma imagem de todo o dispositivo:

# dd if=/dev/sdf of=sdf.img

Em seguida, tente usar testdisk na imagem para tentar recuperar a tabela de partições.

Outra opção seria usar photorec na imagem. É uma ferramenta muito legal, que é capaz de detectar e localizar arquivos, mesmo se o sistema de arquivos estiver danificado. Pode recuperar toneladas de formatos de arquivo. Pelo menos, você poderá retirar seus dados.

    
por 10.08.2011 / 14:44