2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

OS移行時にLVM構成を復旧する (メタデータファイルなし)

Last updated at Posted at 2022-09-14

原因

OSの移行

サーバーの定期アップデートをしようと思い、yum updateをかけたところlibc.so.6が勝手にアップデートされて再起動後にカーネルパニックを起こして起動できなくなってしまった。

LiveUSBからリンク貼り直しetcを試したものの復旧できず、設定ファイル等をコピーしてそのままOS再インストールへ。

そういえば、LVM復旧用のメタデータバックアップしてなくね?

データを格納していたLVMデバイスをマウントしようとして気がついた。
REDHATのマニュアルには、

pvcreate --uuid physical-volume-uuid --restorefile /etc/lvm/archive/volume-group-name_backup-number.vg block-device

でLVM構成を復旧できるよ!とあったものの、肝心のレストア用のメタデータをバックアップしていなかった。

対処

色々調べていたらどうやら

1. LVMを構成する全ディスクを接続
2. pvscanでPVを認識
3. vgscanでVGを認識
4. vgchange -a y VG名 でVGをアクティベート

で復旧できるらしい。

やってみよう

# pvscan
  PV /dev/sda   VG data            lvm2 [931.51 GiB / 0    free]
  PV /dev/sdb   VG data            lvm2 [931.51 GiB / 0    free]
  PV /dev/sdd   VG data            lvm2 [<465.76 GiB / 0    free]
  PV /dev/sde   VG data            lvm2 [<465.76 GiB / 0    free]
  Total: 4 [<2.73 TiB] / in use: 4 [<2.73 TiB] / in no VG: 0 [0   ]

おや?

# vgscan
  Reading volume groups from cache.
  Found volume group "data" using metadata type lvm2

いけそうだ

# vgchange -a y data
  1 logical volume(s) in volume group "data" now active
# fdisk -l
~~~~
 Disk /dev/mapper/data-lv0: 3000.6 GB, 3000613470208 bytes, 5860573184 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O サイズ (最小 / 推奨): 4096 バイト / 4096 バイト
~~~~

正常にマウント出来た。
データもサルベージ出来た。

2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?