场景描述：ORacle服务器中的数据盘容量已满，需要将其数据目录迁移到1.8T的SATA盘中，当时午睡醒来有些迷糊，误将oracle数据目录卸载并将其所在的磁盘删除VG卷组以及格式化磁盘；
将oracle数据目录迁移到新做好文件系统的盘中，发现数据空空，数据丢失；当时在这之前这台机器中并未对oracle数据库进行数据备份；在解决数据恢复问题之后，将误操作和数据恢复过程重新演绎并展现如下以供学习参考：
误操作过程：
[root@test01 ~]# umount /data01/ [root@test01 ~]# lvremove /dev/vgsata_01_J/lv_01 Do you really want to remove active logical volume vgsata_01_J/lv_01? [y/n]: y Logical volume "lv_01" successfully removed [root@test01 ~]# vgremove /dev/vgsata_01_J Volume group "vgsata_01_J" successfully removed [root@test01 ~]# pvremove /dev/sdb Labels on physical volume "/dev/sdb" successfully wiped. [root@test01 ~]# mkfs.xfs /dev/sdb meta-data=/dev/sdb isize=512 agcount=4, agsize=655360 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=0, sparse=0 data = bsize=4096 blocks=2621440, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=1 log =internal log bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 [root@test01 ~]# mount /dev/vgsata_02_J/lv_01 /data02/ [root@test01 ~]# ls （此处发现目录为空，这时已经意识到问题的严重性） 在/etc/lvm/存放着LVM的配置、归档、备份等信息，当我们在操作vgcreate、vgreduce、vgremove、lvcreate、lvreduce、lvremove等命令时均会生成新的归档信息；因此在/etc/lvm/archive/中发现曾经丢失的vg卷组。
数据恢复过程：
[root@test01 /etc/lvm/archive]# vgcfgrestore -f /etc/lvm/archive/vgsata_01_J_00000-1917780534.vg vgsata_01_J Couldn‘t find device with uuid zSvIeb-Hpsb-U0Fy-XGjS-Od3N-BQ19-dUkM3n. Cannot restore Volume Group vgsata_01_J with 1 PVs marked as missing. Restore failed. 这里发现无法找到uuid为“uuid zSvIeb-Hpsb-U0Fy-XGjS-Od3N-BQ19-dUkM3n” 的pv卷组。 [root@test01 /etc/lvm/archive]# vim /etc/lvm/archive/vgsata_01_J_00000-1917780534.vg vgsata_01_J 这里通过查看卷组文件验证了缺少pv卷组。 这时直接强制创建pv，看看能不能成功，看接下来的一步 [root@test01 ~]# pvcreate /dev/sdb --uuid zSvIeb-Hpsb-U0Fy-XGjS-Od3N-BQ19-dUkM3n --restorefile /etc/lvm/archive/vgsata_01_J_00000-1917780534.vg Couldn‘t find device with uuid zSvIeb-Hpsb-U0Fy-XGjS-Od3N-BQ19-dUkM3n. Physical volume "/dev/sdb" successfully created. 此处已经创建成功 再次尝试之前的恢复操作 [root@test01 /etc/lvm/archive]# vgcfgrestore -f /etc/lvm/archive/vgsata_01_J_00000-1917780534.vg vgsata_01_J Restored volume group vgsata_01_J 此时发现vgsata_01_J卷组已经找回 [root@test01 /etc/lvm/archive]# pvdisplay --- Physical volume --- PV Name /dev/sdc VG Name vgsata_02_J PV Size 10.00 GiB / not usable 4.00 MiB Allocatable yes (but full) PE Size 4.00 MiB Total PE 2559 Free PE 0 Allocated PE 2559 PV UUID 5WjGm3-d9fM-O7Bv-kp0z-vM8Q-ds2w-aUwEke --- Physical volume --- PV Name /dev/sdb VG Name vgsata_01_J PV Size 10.00 GiB / not usable 4.00 MiB Allocatable yes PE Size 4.00 MiB Total PE 2559 Free PE 2559 Allocated PE 0 PV UUID zSvIeb-Hpsb-U0Fy-XGjS-Od3N-BQ19-dUkM3n 然而并未出现 vgsata_01_J [root@test01 /etc/lvm/archive]# ls /dev/vg vga_arbiter vgsata_02_J/ [root@test01 /etc/lvm/archive]# vgscan Reading volume groups from cache. Found volume group "vgsata_02_J" using metadata type lvm2 Found volume group "vgsata_01_J" using metadata type lvm2 尽管卷组已经恢复，但是需要将卷组激活才可以使用；以下是卷组激活过程中的尝试： [root@test1 /etc/lvm/archive]# vgchange -ay vgsata_01_J 0 logical volume(s) in volume group "vgsata_01_J" now active [root@test1 /etc/lvm/archive]# vgcfgrestore -f /etc/lvm/archive/vgsata_01_J_00000-1398704631.vg vgsata_01_J Restored volume group vgsata_01_J [root@test01 /etc/lvm/archive]# vgchange -ay vgsata_01_J 0 logical volume(s) in volume group "vgsata_01_J" now active [root@test01 /etc/lvm/archive]# vgcfgrestore -f /etc/lvm/archive/vgsata_01_J_00001-82901740.vg vgsata_01_J Restored volume group vgsata_01_J [root@test01 /etc/lvm/archive]# vgchange -ay vgsata_01_J 0 logical volume(s) in volume group "vgsata_01_J" now active 当操作完vgsata_01_J_00002-1786117572.vg时，发现卷组已经被激活了。 [root@test01 /etc/lvm/archive]# vgcfgrestore -f /etc/lvm/archive/vgsata_01_J_00002-1786117572.vg vgsata_01_J Restored volume group vgsata_01_J [root@test01 /etc/lvm/archive]# vgchange -ay vgsata_01_J 1 logical volume(s) in volume group "vgsata_01_J" now active [root@test01 /etc/lvm/archive]# ls /dev/vg vga_arbiter vgsata_01_J/ vgsata_02_J/ 挂载 # mount /dev/vgsata_01_J/lv_01 /data01/ mount: wrong fs type, bad option, bad superblock on /dev/vgsata_01_J/lv_01, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so. 挂载失败，应该是文件系统有故障，所以修复一下 修复之前先备份元数据 xfs_metadump -f /dev/vgsata_01_J/lv_01 /dev/vgsata_03_J 修复操作： xfs_repair /dev/vgsata_01_J/lv_01 如果上条语句修复不成功，执行下一条 xfs_repair -L /dev/vgsata_01_J/lv_01(清空日志，会丢失文件) 说明：-L是修复xfs文件系统的最后手段，慎重选择，它会清空日志，会丢失用户数据和文件。 重新检查文件系统 xfs_repair /dev/vgsata_01_J/lv_01 挂载 mount /dev/vgsata_01_J/lv_01 /data01/ 恢复服务，检查数据健全。
总结：
总结： 在对VG做变更时，切记先用vgcfgbackup备份好VG的信息，避免意外。 [root@test01 ~]# vgcfgbackup -f /etc/lvm/backup/ vgsata_01_J 怎么说呢，这篇文章是在这次误操作事故发生后近一年才写出来的，当时的Oracle里存的数据是很极其重要（GAJD），可想而知这次误操作给当时的我里留下了多大的阴影。 我更多希望的是大家在工作中时刻牢记数据安全很重要，大脑不清醒状态下不要去动数据；更多的是希望大家不要搜到这边文章，因为一旦发生既是煎熬。 感谢当时主管从公司第一时间赶过来帮我一起解决了问题，而没有责备我什么。