Como posso recriar os volumes lógicos removidos do LVM?

Navegue suas respostas
2

Eu acidentalmente removi todos os meus volumes lógicos com lvremove . Após a reinicialização, os backups de lvm foram perdidos (live CD), então não posso usar vgcfgrestore . testdisk pode encontrar as partições por análise, então elas ainda estão lá. Existe uma maneira de restaurar os volumes lógicos? 

TestDisk 6.14, Data Recovery Utility, July 2013
Christophe GRENIER <[email protected]>
http://www.cgsecurity.org

Disk /dev/mapper/Manjaro - 999 GB / 931 GiB - 1952782336 sectors
     Partition               Start        End    Size in sectors
>  MS Data                   264190   82675709   82411520 [ManjaroRoot]
   MS Data                 61442046 1739163645 1677721600 [ManjaroHome]
 P MS Data               1762396158 1844807677   82411520 [ManjaroRoot]
 P Linux Swap            1936631800 1936631815         16

dmsetup ls 

Manjaro (254:0)

[root@manjaro ~]# dmsetup table Manjaro
0 1952782336 crypt aes-xts-plain 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0 8:4 4096

pvdisplay -v 

    Scanning for physical volume names
  --- Physical volume ---
  PV Name               /dev/mapper/Manjaro
  VG Name               ManjaroVG
  PV Size               931.16 GiB / not usable 3.00 MiB
  Allocatable           yes 
  PE Size               4.00 MiB
  Total PE              238376
  Free PE               238376
  Allocated PE          0
  PV UUID               3Vv8c2-O0fr-jOgd-QIBR-WBMY-RGBf-rujHnF

vgdisplay -v 

    Finding all volume groups
    Finding volume group "ManjaroVG"
  --- Volume group ---
  VG Name               ManjaroVG
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  16
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                0
  Open LV               0
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               931.16 GiB
  PE Size               4.00 MiB
  Total PE              238376
  Alloc PE / Size       0 / 0   
  Free  PE / Size       238376 / 931.16 GiB
  VG UUID               VWNJNN-iaBv-cLuu-1AAb-nS00-SogZ-z6qDU0

  --- Physical volumes ---
  PV Name               /dev/mapper/Manjaro     
  PV UUID               3Vv8c2-O0fr-jOgd-QIBR-WBMY-RGBf-rujHnF
  PV Status             allocatable
  Total PE / Free PE    238376 / 238376

lvdisplay -v 

    Finding all logical volumes

tentando criar LV 

[root@manjaro ~]# dmsetup create ManjaroRoot --table "264190 82411520 linear 8:4 4096"
device-mapper: reload ioctl on ManjaroRoot failed: Invalid argument
Command failed
[root@manjaro ~]# dmsetup create ManjaroRoot --table "264190 82411520 linear 8:4 4096" --readonly
device-mapper: reload ioctl on ManjaroRoot failed: Invalid argument
Command failed
[root@manjaro ~]# dmsetup create ManjaroRoot --table "264190 100 linear 8:4 4096" --readonly
device-mapper: reload ioctl on ManjaroRoot failed: Invalid argument
Command failed
[root@manjaro ~]# dmsetup create ManjaroRoot --table "0 100 linear 8:4 4096" --readonly
[root@manjaro ~]# lvscan 
[root@manjaro ~]# dumpe2fs -h /dev/mapper/ManjaroRoot 
dumpe2fs 1.42.9 (28-Dec-2013)
dumpe2fs: Bad magic number in super-block while trying to open /dev/mapper/ManjaroRoot
Couldn't find valid filesystem superblock.

Aproximando-se 

[root@manjaro ~]# dmsetup create ManjaroRoot --table "0 82411520 linear /dev/mapper/Manjaro 264190" --readonly
[root@manjaro ~]# dumpe2fs -h /dev/mapper/ManjaroRoot 
dumpe2fs 1.42.9 (28-Dec-2013)
Filesystem volume name:   ManjaroRoot
Last mounted on:          /
Filesystem UUID:          b5cbe2bf-54cf-46c3-96ed-047ad7e77bcf
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              2575440
Block count:              10301440
Reserved block count:     488035
Free blocks:              2771298
Free inodes:              2140018
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1021
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8176
Inode blocks per group:   511
Flex block group size:    16
Filesystem created:       Mon Nov 17 06:33:51 2014
Last mount time:          Wed Jan  7 15:40:24 2015
Last write time:          Wed Jan  7 15:40:24 2015
Mount count:              37
Maximum mount count:      -1
Last checked:             Mon Nov 17 06:33:51 2014
Check interval:           0 (<none>)
Lifetime writes:          62 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      bf1a643c-f34a-456d-bb88-4ea72a94239c
Journal backup:           inode blocks
dumpe2fs: A block group is missing an inode table while reading journal inode

montagem 

[root@manjaro ~]# mount "/dev/mapper/ManjaroHome" "/run/media/manjaro/ManjaroHome"
mount: /dev/mapper/ManjaroHome is write-protected, mounting read-only
mount: wrong fs type, bad option, bad superblock on /dev/mapper/ManjaroHome,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

… nada de novo no dmesg

Thunar tentou o seguinte - que também errou mas pelo menos existe algo no dmesg: 

[root@manjaro ~]# mount -t "ext4" -o "uhelper=udisks2,nodev,nosuid" "/dev/mapper/ManjaroHome" "/run/media/manjaro/ManjaroHome"
mount: /dev/mapper/ManjaroHome is write-protected, mounting read-only
mount: wrong fs type, bad option, bad superblock on /dev/mapper/ManjaroHome,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

dmesg 

[Wed Jan 21 06:10:04 2015] EXT4-fs (dm-2): VFS: Can't find ext4 filesystem
    
por Jan Tojnar 20.01.2015 / 02:43

1 resposta

3

Deve ser fácil restaurar os LVs se eles não estiverem fragmentados (no nível LVM) e se forem volumes simples (lineares); pode funcionar também com o provisionamento thin, mas não estou familiarizado com isso. Você só precisa criá-los na mesma ordem e com o mesmo tamanho de antes.

Não estou familiarizado com testdisk . Se lhe disser o tamanho dos volumes encontrados, você não precisará descobrir a si mesmo.

Isso ajuda a entender como o dmsetup funciona. Um exemplo do meu sistema: 

> dmsetup ls
[...]
linux2-test   (254:4)

> dmsetup table linux2-test
0 106496 linear 8:8 384

Os primeiros 384 setores contêm os metadados do LVM. Se esse volume foi excluído, testdisk deve mostrar um volume ext4 começando no setor 384. Em seguida, você pode configurar um dispositivo de mapeamento de dispositivo temporário: 

> dmsetup create restore-lv-1 --table "0 100 linear 8:8 384" --readonly

O número de setores (100 neste exemplo) não é conhecido primeiro, então você pode escolher praticamente qualquer valor, mas não deve exceder o tamanho do dispositivo de bloco subjacente. Você pode usar um valor pequeno como 100, pois você só precisa do superbloco. Então você lê o tamanho do sistema de arquivos do dispositivo temporário: 

> dumpe2fs -h /dev/mapper/restore-lv-1
dumpe2fs 1.41.14 (22-Dec-2010)
[...]
Block count:              53248
[...]
Block size:               1024
[...]

O tamanho do volume é 53248 * 1024 = 54525952, que é 106496 setores de 512 bytes. Se o sistema de arquivos cobriu todo o LV (o que geralmente é o caso), então este também é o tamanho do dispositivo. O deslocamento do próximo LV deve ser 106496 + 384 = 106880. Com esse deslocamento, você pode repetir esse processo.

Se você criar um novo LV, você deve verificar com dmsetup table se ele tem o offset e comprimento esperados.

    
por 20.01.2015 / 05:30

Tags

Extraindo valores de um arquivo digitado por várias chaves O que exatamente é a falta de transparência no systemd? [fechadas]