☰

dmsetup ls

tag-icon • tag-icon lvm
dmsetup ls

誤ってすべての論理ボリュームを削除しましたlvremove。再起動後にlvmバックアップが失われ（ライブCD）、使用できなくなりますvgcfgrestore。testdiskパーティションは分析によって見つけることができるので、まだ残っています。論理ボリュームを復元する方法はありますか？

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

PVショー-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

vg ショー -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

LVディスプレイ-v

    Finding all logical volumes

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.

近づく

[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

インストールする

[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.

... dmesgに新しいものはありません

Thunarは次のことを試しました。エラーも発生しましたが、少なくとも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.

情報

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

答え1

LVが断片化されていない（LVMレベルで）単純（線形）ボリュームの場合、LVを復元するのは簡単です。シンプロビジョニングでも機能できますが、私はそれに慣れていません。前と同じ順序と同じサイズで作成できます。

私は慣れていませんtestdisk。見つかったボリュームのサイズを教えてくれるので、自分で見つける必要はありません。

dmsetup仕組みを理解するのに役立ちます。私のシステムの例：

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

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

最初の384セクタにはLVMメタデータが含まれています。ボリュームが削除された場合は、セクタ384で始まるボリュームをtestdisk表示する必要があります。ext4その後、一時デバイスマッパーデバイスを設定できます。

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

セクタの数（この例では100）は最初は不明であるため、ほぼすべての値を選択できますが、基本ブロックデバイスのサイズを超えてはいけません。スーパーブロックのみが必要なため、100などの小さな値を使用できます。次に、一時デバイスからファイルシステムサイズを読み込みます。

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

ボリュームのサイズは 53248*1024=54525952、つまり 106496 512 バイトのセクターです。ファイルシステムがLV全体をカバーする場合（通常の場合）、これはデバイスサイズでもあります。次のLVのオフセットは106496 + 384 = 106880でなければなりません。このオフセットを使用すると、プロセスを繰り返すことができます。

新しいLVを作成する場合は、dmsetup table予想されるオフセットと長さがあることを確認する必要があります。

関連情報