VMware将已有做了LVM的磁盘挂载到其他系统的操作
以下是一个VMWARE 虚拟机Linux系统磁盘故障恢复的经验分享。
发生时间:2018年7月16日
因为VMWare虚拟机Linux服务器系统(A)故障,无法开机,将故障的虚拟机的磁盘挂载到其他Linux服务器(B)(VMware后台添加已有磁盘),这个磁盘在发生故障前做了LVM,登录服务器(B)进行vg导入操作。
查看pv,主要关注/dev/sdc2,因为这个是故障服务器(A)挂载过来的虚拟磁盘。
1 2 3 4 5 6 | [root@oem12c ~]# pvs PV VG Fmt Attr PSize PFree /dev/sda2 vg_oem12c lvm2 a--u 199.51g 0 /dev/sda3 vg_oem12c lvm2 a--u 99.99g 0 /dev/sdb vg_oem12c lvm2 a--u 100.00g 1012.00m /dev/sdc2 vg_jiuyuan lvm2 a--u 119.51g 0 |
查看/dev/sdc 磁盘及分区信息
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | [root@oem12c ~]# fdisk -l /dev/sdc
Disk /dev/sdc: 128.8 GB, 128849018880 bytes 255 heads, 63 sectors/track, 15665 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: 0x000633b7
Device Boot Start End Blocks Id System /dev/sdc1 * 1 64 512000 83 Linux Partition 1 does not end on cylinder boundary. /dev/sdc2 64 15666 125316096 8e Linux LVM |
查看系统已有的VG信息,其中vg_jiuyuan是故障服务器(A)的VG(卷组)
1 2 3 4 | [root@oem12c ~]# vgs VG #PV #LV #SN Attr VSize VFree vg_jiuyuan 1 4 0 wz--n- 119.51g 0 vg_oem12c 3 3 0 wz--n- 399.50g 1012.00m |
查看LV信息,前4个LV信息都是故障服务器(A)磁盘创建的。
1 2 3 4 5 6 7 8 9 | [root@oem12c ~]# lvs LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert Lv_var vg_jiuyuan -wi------- 67.75g lv_home vg_jiuyuan -wi------- 17.58g lv_root vg_jiuyuan -wi------- 14.65g lv_swap vg_jiuyuan -wi------- 19.53g lv_home vg_oem12c -wi-ao---- 290.65g lv_root vg_oem12c -wi-ao---- 100.00g lv_swap vg_oem12c -wi-ao---- 7.86g |
创建临时挂载目录
1 | [root@oem12c ~]# mkdir /psswxtmp |
注意,因为故障服务器(A)没有执行过vgexport 的导出操作,所以这里不能直接vgimport。如下所示,会报错。
1 2 | [root@oem12c dev]# vgimport vg_jiuyuan Volume group "vg_jiuyuan" is not exported |
利用pvscan扫描pv设备信息,没有发现报错。
1 2 3 4 5 6 | [root@oem12c dev]# pvscan PV /dev/sdc2 VG vg_jiuyuan lvm2 [119.51 GiB / 0 free] PV /dev/sda2 VG vg_oem12c lvm2 [199.51 GiB / 0 free] PV /dev/sda3 VG vg_oem12c lvm2 [99.99 GiB / 0 free] PV /dev/sdb VG vg_oem12c lvm2 [100.00 GiB / 1012.00 MiB free] Total: 4 [519.00 GiB] / in use: 4 [519.00 GiB] / in no VG: 0 [0 ] |
利用vgscan扫描vg信息,发现也没有报错。
1 2 3 4 | [root@oem12c dev]# vgscan Reading all physical volumes. This may take a while... Found volume group "vg_jiuyuan" using metadata type lvm2 Found volume group "vg_oem12c" using metadata type lvm2 |
但是在执行lvscan时,发现vg_jiuyuan卷组对应的4个lv的状态全部是inactive。
1 2 3 4 5 6 7 8 | [root@oem12c dev]# lvscan inactive '/dev/vg_jiuyuan/lv_root' [14.65 GiB] inherit inactive '/dev/vg_jiuyuan/lv_swap' [19.53 GiB] inherit inactive '/dev/vg_jiuyuan/Lv_var' [67.75 GiB] inherit inactive '/dev/vg_jiuyuan/lv_home' [17.58 GiB] inherit ACTIVE '/dev/vg_oem12c/lv_root' [100.00 GiB] inherit ACTIVE '/dev/vg_oem12c/lv_home' [290.65 GiB] inherit ACTIVE '/dev/vg_oem12c/lv_swap' [7.86 GiB] inherit |
利用vgchange激活vg,从而使lv的状态全部变为ACTIVE
1 2 3 4 5 6 7 8 9 10 | [root@oem12c dev]# vgchange -a y vg_jiuyuan 4 logical volume(s) in volume group "vg_jiuyuan" now active [root@oem12c dev]# lvscan ACTIVE '/dev/vg_jiuyuan/lv_root' [14.65 GiB] inherit ACTIVE '/dev/vg_jiuyuan/lv_swap' [19.53 GiB] inherit ACTIVE '/dev/vg_jiuyuan/Lv_var' [67.75 GiB] inherit ACTIVE '/dev/vg_jiuyuan/lv_home' [17.58 GiB] inherit ACTIVE '/dev/vg_oem12c/lv_root' [100.00 GiB] inherit ACTIVE '/dev/vg_oem12c/lv_home' [290.65 GiB] inherit ACTIVE '/dev/vg_oem12c/lv_swap' [7.86 GiB] inherit |
尝试挂载lv_root分区,因为这个分区存放着主要的数据。挂载目录是前面创建的/psswxtmp。
1 | [root@oem12c dev]# mount /dev/vg_jiuyuan/lv_root /psswxtmp/ |
查看挂载结果,发现已经可以正常mount,并且最好将程序复制出来,恢复到生产环境中,让应用重新启动。
1 2 3 4 5 6 7 8 9 10 | [root@oem12c dev]# df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_oem12c-lv_root 99G 23G 72G 24% / tmpfs 7.8G 148K 7.8G 1% /dev/shm /dev/sda1 485M 42M 418M 10% /boot /dev/mapper/vg_oem12c-lv_home 287G 151G 122G 56% /monapp /dev/mapper/vg_jiuyuan-lv_root 15G 11G 3.3G 77% /psswxtmp |
总结
其实,利用上面这种方法恢复程序文件,是非常无奈的。最理想的方法还是要定期备份应用程序文件,这样才是最可靠、最安全的故障恢复。
本文来自希曼博客-www.ximan.tech,作者:希曼博客,转载请注明原文链接:https://www.cnblogs.com/lihuaichen/p/15186435.html