Restaurando dados da partição ext4 corrompida sob o LVM - fsck ou repara os blocos defeituosos primeiro?

Question

Estou usando o Linux no meu notebook. Meu notebook recentemente caiu no chão e agora eu estou tentando salvar o máximo de dados do meu disco rígido danificado possível. Eu posso inicializar o notebook do live CD do Linux.

Longa história curta: uma partição ext4 não é montável, mas posso tentar repará-la por fsck.ext4. Eu também posso tentar primeiro tentar recuperar os blocos ruins no disco rígido (provavelmente por SpinRite). O que devo fazer primeiro?

Em detalhes completos:

Aqui está o meu caminho:

# fdisk -l

Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 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: 0x00000080

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1        3824    30716248+   7  HPFS/NTFS
/dev/sda2            3825       19449   125507812+  83  Linux
/dev/sda3           19450       19457       64260   83  Linux

Vamos esquecer / dev / sda1 partição NTFS, não tão importante. Terceira partição / dev / sda3 é apenas / boot, não é importante também. Segundo / dev / sda2 é o espaço físico para o LVM (veja abaixo).

O grupo lógico / dev / group1 / arch é criptografado pelo dm-crypt LUKS, não consigo abri-lo e os dados provavelmente estão perdidos. Grupos lógicos / dev / group1 / data e / dev / group1 / data2 são volumes ext4. Eu posso montar / dev / group1 / data2 ( montar -t ext4 -o ro, carregar / dev / group1 / data2 / mnt / data2 ) e dados de backup na unidade externa. Mas eu não consigo montar / dev / group1 / data:

# mount -t ext4 -o ro,noload /dev/group1/data /x/data
mount: wrong fs type, bad option, bad superblock on /dev/mapper/group1-data,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

fsck não funciona:

# fsck.ext4 -n /dev/group1/data
e2fsck 1.41.11 (14-Mar-2010)
fsck.ext4: Attempt to read block from filesystem resulted in short read while trying to open /dev/group1/data
Could this be a zero-length partition?

dumpe2fs também não encontra superblocos:

# dumpe2fs /dev/group1/data
dumpe2fs 1.41.11 (14-Mar-2010)
dumpe2fs: Attempt to read block from filesystem resulted in short read while trying to open /dev/group1/data
Couldn't find valid filesystem superblock.

A única coisa que posso fazer é tentar descobrir onde o superbloco geralmente está:

# mkfs.ext4 -n /dev/group1/data
mke2fs 1.41.11 (14-Mar-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
5242880 inodes, 20971520 blocks
1048576 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
640 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424, 20480000

... e inicie o fsck usando um desses superblocos:

# fsck.ext4 -n -b 229376 /dev/group1/data
e2fsck 1.41.11 (14-Mar-2010)
One or more block group descriptor checksums are invalid.  Fix? no

Group descriptor 0 checksum is invalid.  IGNORED.
Group descriptor 1 checksum is invalid.  IGNORED.
Group descriptor 2 checksum is invalid.  IGNORED.
Group descriptor 3 checksum is invalid.  IGNORED.
Group descriptor 4 checksum is invalid.  IGNORED.
Group descriptor 5 checksum is invalid.  IGNORED.
...
Group descriptor 637 checksum is invalid.  IGNORED.
Group descriptor 638 checksum is invalid.  IGNORED.
Group descriptor 639 checksum is invalid.  IGNORED.
/dev/group1/data contains a file system with errors, check forced.
Resize inode not valid.  Recreate? no

Pass 1: Checking inodes, blocks, and sizes
...here I pressed Ctrl-C...

Então - ele exibe muitos erros, mas parece que ele tentará reparar (se eu usar fsck.ext4 -y em vez de fsck.ext4 -n, é claro).

Outras opções - O meu frind possui o CD de inicialização do SpinRite 6, que é considerado um dos melhores programas para reparar blocos defeituosos.

Então, minha PERGUNTA é - devo

1. experimente primeiro o SpinRite para reparar blocos defeituosos e, em seguida, fsck.ext4 -y (ou, melhor ainda, copie partições cruas inteiras para um arquivo grande em disco rígido externo, faça cópia, monte a cópia como loopback e tente fckk.ext4 -y)
2. tente firt fsck.ext4 -y com esperança do que depois os dados serão legíveis, faça backup desses dados em um disco rígido externo (e, em seguida, experimente o SpinRite)?
3. ou fazer outra coisa?

Muito obrigado por qualquer dica.

Estrutura do LVM:

# pvdisplay 
  --- Physical volume ---
  PV Name               /dev/sda2
  VG Name               group1
  PV Size               119.69 GiB / not usable 2.22 MiB
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              30641
  Free PE               0
  Allocated PE          30641
  PV UUID               0k3Zl5-Q7BD-rb8J-9jTZ-2uii-GSGd-B339JB

# vgdisplay 
  --- Volume group ---
  VG Name               group1
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  10
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                4
  Open LV               1
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               119.69 GiB
  PE Size               4.00 MiB
  Total PE              30641
  Alloc PE / Size       30641 / 119.69 GiB
  Free  PE / Size       0 / 0   
  VG UUID               kKhvri-OVpL-uhCP-T4an-qXIJ-4XL0-kn9Ifi



# lvdisplay 
  --- Logical volume ---
  LV Name                /dev/group1/swap
  VG Name                group1
  LV UUID                wpDink-01q0-peLc-29at-5kgP-YO3a-8bNrb7
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                1.50 GiB
  Current LE             384
  Segments               1
  Allocation             contiguous
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:0

  --- Logical volume ---
  LV Name                /dev/group1/arch
  VG Name                group1
  LV UUID                S1TZkr-y62z-dOuc-D38G-nuCH-1ilc-y2jqMa
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                15.00 GiB
  Current LE             3840
  Segments               1
  Allocation             contiguous
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:1

  --- Logical volume ---
  LV Name                /dev/group1/data
  VG Name                group1
  LV UUID                2R4LNv-sHPh-E7ES-goIF-5nUz-tQyj-GOiwvC
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                80.00 GiB
  Current LE             20480
  Segments               1
  Allocation             contiguous
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:2

  --- Logical volume ---
  LV Name                /dev/group1/data2
  VG Name                group1
  LV UUID                4VqpZj-uOBi-OAIZ-1IXA-G6mj-Qgfb-c6RYqw
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                23.19 GiB
  Current LE             5937
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:3

    

Answer 1

A primeira coisa que eu faria é usar o ddrescue de um liveCD para criar uma imagem de backup da unidade. Se houver dano físico ao disco, há uma chance de haver um tempo finito até que ele falhe completamente. Em seguida, faça uma cópia dessa imagem para trabalhar.

De lá, não tenho sugestões que você não tenha tentado. Outros mais espertos do que eu terão que te ajudar lá.