zoukankan      html  css  js  c++  java
  • 记录一次生产环境LVM中误操作删除VG卷组恢复过程

    场景描述: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),可想而知这次误操作给当时的我里留下了多大的阴影。
     我更多希望的是大家在工作中时刻牢记数据安全很重要,大脑不清醒状态下不要去动数据;更多的是希望大家不要搜到这边文章,因为一旦发生既是煎熬。
     感谢当时主管从公司第一时间赶过来帮我一起解决了问题,而没有责备我什么。
  • 相关阅读:
    达叔系列——神经网络编程基础
    win10安装pytorch——前面有坑,快跳进去鸭
    Python基础(六)——面向对象编程
    Python基础(五)——闭包与lambda的结合
    Python基础(四)——迭代器/对象,生成器
    Mysql优化(出自官方文档)
    Mysql优化(出自官方文档)
    Scala语言笔记
    Scala语言笔记
    Scala语言笔记
  • 原文地址:https://www.cnblogs.com/alisapine/p/15104734.html
Copyright © 2011-2022 走看看