数据恢复技术与LVM数据恢复方法

1       摘要 随着计算机网络应用的发展，数据存储的安全性变的越来越重要。在常见的基于RAID和LVM的环境下面，当出现硬盘故障或者错误操作导致数据丢失的情况下，采用适当的数据恢复策略可以在很大程度上提供数据恢复的成功概率。本文研究了几种情况下的数据恢复技术和方法，为数据恢复和数据安全的预防提供了指导。   2       数据恢复需求 2.1    Linux IO存储栈   图（1）Linux IO 存储栈   Linux 的存储相关的栈包括如图1所示，最下方为各种硬件存储器，例如SATA，SAS，SSD等硬盘和磁带库等。 2.2    存储故障 2.2.1   介质故障 磁盘消失，例如由于线缆或者网络问题造成的磁盘丢失或者ISCSI磁盘链接失败 磁盘坏道 偶发的硬件错误 2.2.2   错误操作 包括误删除，格式化，重新分区等操作。 2.2.3   RAID故障 服务器上的硬盘比较多的应用了RAID(冗余磁盘阵列)来实现数据保护。以多块硬盘环境下常使用的RAID 5为例，当损坏一块硬盘时数据不会受到影响，而这种情况下如果第二块硬盘再损坏(或者更换硬盘时拔错)就会丢失数据。此时要注意硬盘掉线的先后顺序，如果将2块硬盘同时上线则会导致部分数据访问出错，正确的方法是先上线最后出问题的硬盘，看数据是不是我们想要的，再尝试之前掉线的硬盘进行比较。 有些RAID卡在插入掉线的硬盘时会自动尝试Rebuild(重建)，这样就会损坏我们需要的数据，因此企业级数据恢复最好还是找专业的公司/人士来进行。有的RAID卡还会出现硬盘完好，而RAID信息丢失的问题。如果用户在运输服务器/磁盘阵列时，将硬盘拆出来单独运输，没有记录安装的顺序，也可能会导致数据无法访问。 2.2.4   文件或者文件系统故障 这部分属于高端的数据恢复技术，比如ext2、ext3、reiserfs、XFS…文件系统。Linux/Unix的数据恢复难度较大一方面是由于这些文件系统结构复杂，另一方面则是有些厂商的相关资料不公开，比如IBM的AIX系统。这样我们只能通过不断的摸索，积累经验来“破解”它们的结构，最终能够恢复上面的数据，或者提取出修改文件(属性)的访问记录等。   2.3    存储部署对数据丢失的考虑 通常需要引入冗余（REDUNDANT）和备份（BAKUP）两种机制。 RAID和MIRROR和最常见的存储冗余的实现方式，可以容忍介质故障等问题。 备份测试可以在错误操作或者文件系统故障时，很容易的恢复数据。 3       数据恢复策略 3.1    数据恢复基本步骤 由于存储故障是无法完全避免的，在出现故障的时候，需要考虑如下的几个基本策略和步骤： 分析故障，通过分析用户手册，分析系统LOG，检查系统状态等方式定位和分析问题 在问题没有定位之前，不可以对存储系统作更改操作 在分析问题之后，必须通过模拟系统测试恢复策略的可行性和风险 寻求专业帮助，通过mail list，BBS，付费支持等方式获取专业的指导 3.2    数据恢复方法 3.2.1   硬件故障处理 检查硬盘，数据线，连接部位，电源等问题 检查Fimware版本，分析对应的Changelog 磁盘坏扇区，使用二进制的操作执行备份，例如dd命令 3.2.2   磁盘分区故障  检查驱动和内核版本 通过fdisk ,diskpart, partprobe,gpart等工具分析分区信息 检查磁盘和分区大小，blockdev,fdisk,sysfs等工具 3.2.3   RAID故障 分析RAID中device,raidset和volume的信息 查看RAID的配置文件的信息 尽可能的分析RAID的元数据信息 3.2.4   元数据 元数据是指数据的组织结构。通常，有两种方式存储： （1）在磁盘上，通常在硬盘的最前面或者最后面预留扇区用于存储元数据 （2）在配置文件中保存必要的信息 在执行数据恢复的时候，通常需要先修复元数据再修复数据。   4       LVM数据恢复 4.1    LVM基础 4.1.1   LVM的架构   图（2）LVM基础架构   如果所示为Linux Volume Management系统的基础架构，由PV，VG和LV组成。   4.1.2   LVM的on-disk PV结构 PV的基本结构如下： （1）标签，占用一个sector,包括签名，UUID，元数据的位置指针 （2）元数据：占用多个sector a)  真正元数据的指针 b) 循环缓存，文本格式 c) 原子更新操作 d) 序列号 e) 校验码，冗余信息，自动修复信息等     图（3）LVM的PV结构   4.1.3   LVM的文本元数据配置 如下为一个/etc/lvm/backup/pool的配置实例： # Generated by LVM2 version 2.02.42 (2008-10-26): Sat Sep 25 17:36:30 2010   contents = "Text Format Volume Group" version = 1   description = "Created *after* executing 'lvcreate --name block --size 300G pool'"   creation_host = "zhuweiR30"     # Linux zhuweiR30 2.6.28-storix #1 SMP Thu Dec 24 17:25:02 CST 2009 i686 creation_time = 1285407390      # Sat Sep 25 17:36:30 2010   pool {         id = "0Lm9dz-sIeu-t2Ho-qIBR-lD2P-dcbK-K1U4zW"         seqno = 2         status = ["RESIZEABLE", "READ", "WRITE"]         flags = []         extent_size = 8192              # 4 Megabytes         max_lv = 0         max_pv = 0           physical_volumes {                   pv0 {                         id = "rewaTQ-vKaK-PzWs-H14L-a2Qz-hV62-CcIHqT"                         device = "/dev/sdb"     # Hint only                           status = ["ALLOCATABLE"]                         flags = []                         dev_size = 21484367872 # 10.0044 Terabytes                         pe_start = 384                         pe_count = 2622603      # 10.0044 Terabytes                 }         }           logical_volumes {                   block {                         id = "ryg1Or-e1C3-ooKV-0XMM-jKSN-g0EM-dXky7G"                         status = ["READ", "WRITE", "VISIBLE"]                         flags = []                         segment_count = 1                           segment1 {                                 start_extent = 0                                 extent_count = 76800    # 300 Gigabytes                                   type = "striped"                                 stripe_count = 1        # linear                                   stripes = [                                         "pv0", 0                                 ]                         }                 }         } }                                   4.1.4   LVM元数据备份 LVM元数据通过默认备份在/etc/lvm目录下，可以通过工具vgcfgbackup和vgcfgrestore命令备份和恢复元数据。 4.2    LVM PV故障的修复实例 4.2.1   部分修复 检查系统的所有的LVM的VG信息 # vgscan  Reading all physical volumes. This may take a while...  Couldn't find device with uuid 'DHmMDP-bqQy-TalG-2GLa-sh6o-fyVW-3XQ3gp'.  Found volume group "vg_test" using metadata type lvm2 检查丢失的设备上的信息 #pvs -o +uuid  Couldn't find device with uuid 'DhmMDP-bqQy-TalG-2GLa-sh6o-fyVW-3XQ3gp'.  PV             VG      Fmt Attr PSize   PFree PV UUID  /dev/sdb       vg_test lvm2 a-   200.00m    0 5KjGmZ-vhc6-u62q-YcSZ-aKX0-bCYP-EXtbzd  unknown device vg_test lvm2 a-   200.00m    0 DHmMDP-bqQy-TalG-2GLa-sh6o-fyVW-3XQ3gp # lvs -o +devices  Couldn't find device with uuid 'DHmMDP-bqQy-TalG-2GLa-sh6o-fyVW-3XQ3gp'.  LV   VG      Attr   LSize   Devices  lv1 vg_test -wi--- 100.00m /dev/sdb(0)  lv2 vg_test -wi--- 100.00m unknown device(0)  lv3 vg_test -wi--- 200.00m /dev/sdb(25)  lv3 vg_test -wi--- 200.00m unknown device(25) 在这种情况下，lv1正常，lv2丢失,lv3部分丢失 激活 # vgchange -a y vg_test  Couldn't find device with uuid 'DHmMDP-bqQy-TalG-2GLa-sh6o-fyVW-3XQ3gp'.  Refusing activation of partial LV lv2. Use --partial to override.  Refusing activation of partial LV lv3. Use --partial to override.  1 logical volume(s) in volume group "vg_test" now active 对应—partial 参数，丢失的部分使用配置/etc/lvm.conf中的Missing_stripe_filler=”error” 指定的设备来补充  尝试部分修复 准备zero设备 # dmsetup create zero_missing --table "0 10000000 zero" 修复配置文件 missing_stripe_filler = "/dev/mapper/zero_missing" # vgchange -a y vg_test --partial  ...  3 logical volume(s) in volume group "vg_test" now active 移除丢失硬盘上的所有的LV # vgreduce --removemissing vg_test  Couldn't find device with uuid 'DHmMDP-bqQy-TalG-2GLa-sh6o-fyVW-3XQ3gp'.  WARNING: Partial LV lv2 needs to be repaired or removed.  WARNING: Partial LV lv3 needs to be repaired or removed.  WARNING: There are still partial LVs in VG vg_test.  To remove them unconditionally use: vgreduce --removemissing --force.  Proceeding to remove empty missing PVs. # vgreduce --removemissing vg_test --force  Couldn't find device with uuid 'DhmMDP-bqQy-TalG-2GLa-sh6o-fyVW-3XQ3gp'.  ...  Wrote out consistent volume group vg_test  完成数据修复 # pvs  PV         VG      Fmt Attr PSize   PFree  /dev/sdb   vg_test lvm2 a-   200.00m 100.00m # lvs -o +devices  LV   VG      Attr   LSize   Devices  lv1 vg_test -wi--- 100.00m /dev/sdb(0) 4.2.2   通过备份恢复 如果在某些情况下， 提示“操作错误”的情况 # vgscan  Reading all physical volumes. This may take a while...  WARNING: Inconsistent metadata found for VG vg_test - updating to use version 18  Removing PV /dev/sdc (DHmMDP-bqQy-TalG-2GLa-sh6o-fyVW-3XQ3gp) that no longer belongs   to VG vg_test  Found volume group "vg_test" using metadata type lvm2 # pvs  PV         VG      Fmt Attr PSize   PFree  /dev/sdb   vg_test lvm2 a-   200.00m 100.00m  /dev/sdc           lvm2 --   204.00m 204.00m 通过恢复配置还原 # vgcfgrestore -f /etc/lvm/archive/vg_test_01564.vg vg_test  Cannot restore Volume Group vg_test with 1 PVs marked as missing.  Restore failed.   手工修改配置 ...                pv1 {                         id = "DHmMDP-bqQy-TalG-2GLa-sh6o-fyVW-3XQ3gp"                         device = "unknown device"                         flags = ["MISSING"] ... 再次恢复 # vgcfgrestore -f vg_test_edited.vg vg_test  Restored volume group vg_test 5       小结 本文分析了存储故障参数的原因，提出了数据恢复的测试和实施步骤，并且针对常见的LVM的故障，分析了LVM的架构和元数据的组织结构，最后给出了LVM故障的常见修复方法和实例分析。 但是，数据恢复本身只是在出现存储故障之后的修补措施，修复成功的可能性也不是100%。因此，在部署存储系统的时候，考虑冗余和备份是提高数据安全性的更好的版本。

LVM 移機備忘

其實工廠主機又變快了.....好像常常看到我再給他加速.....以前一直傳聞說一台爛爛的linux主機跑個apache都可以很順暢，前幾天換了主機才知道這傳聞根本.....，主機的效能明顯還是受到CPU和硬碟讀取速度的影響。感覺前一句好像廢話一樣，但是我是在舊主機一直調整下，相信傳聞是真實的狀態下一直調，還是調不出一個好結果，常常被裕藍的老闆吐槽網站那麼慢.....
其實移機基本不難，檔案形式的複製一下就好，我比較擔心的是三顆硬碟組成的LVM，因為沒有其他空間把160G的檔案移出了，只好硬著頭皮嘗試直接把三顆硬碟直接移到另一台主機，依靠著一個小小的config檔，沒有過的經驗的確令人緊張，深怕轉移失敗資料都消失哩。
產生LVM的conf檔其實很簡單
# vgcfgbackup
  Volume group "homeVG" successfully backed up.
設定檔會產生出來在/etc/lvm/backup/homeVG，就依靠著個檔案定生死哩，來還原囉!!
# vgcfgrestore -f /etc/lvm/backup/homeVG -n homeVG homeVG
結果當然是成功~有哩經驗之後，以後就會大膽的作哩!!

 

 

备份  每次修改lvm会自动在/etc/lvm/backup下备份lvm的元数据信息 某个pv损坏： pvcreate --restorefile /etc/lvm/backup/test --uuid 2QI12V-AhFi-hd0r-Nn2e-LCrm-b3Of-leI0Nv /dev/hda6 vgcfgrestore --file /etc/lvm/backup/test test   分区表备份： sfdisk -d /dev/sdd > sdd-table                ===> 导出正常的分区表 sfdisk /dev/sdb < sdb-table                       ===> 恢复丢失的分区表

 

 

 

 

 

系统情况：Red Hat Enterprise Linux Server release 6.0，lvm2，ext4

原来有一个lvm分区/dev/data/ftproot挂载到/work目录下的。 周一的时候由于调休，不知道那个BT直接关机造成data_ftproot的lvm丢失

 

下是记录下的处理过程：

 

1. [root@localhost lvm]# vgcfgrestore -f /etc/lvm/backup/data -t /dev/sda3
2.   Test mode: Metadata will NOT be updated.
3.   Couldn't find device with uuid h6t9V2-Oi08-F5kw-U2G5-vRDW-1WdJ-1awgnU.
4.   '/etc/lvm/backup/data' does not contain volume group 'sda3'.
5.   Restore failed.
6.  
7. [root@localhost lvm]# pvcreate -u h6t9V2-Oi08-F5kw-U2G5-vRDW-1WdJ-1awgnU --restorefile /etc/lvm/archive/data_00002.vg /dev/sda3
8.   Couldn't find device with uuid h6t9V2-Oi08-F5kw-U2G5-vRDW-1WdJ-1awgnU.
9.   Physical volume "/dev/sda3" successfully created
10.  
11. [root@localhost lvm]# vgcfgrestore data
12.   Restored volume group data
13. [root@localhost lvm]# vgscan && vgscan && lvscan
14.   Reading all physical volumes. This may take a while...
15.   Found volume group "data" using metadata type lvm2
16.   Found volume group "vg_localhost" using metadata type lvm2
17.   Reading all physical volumes. This may take a while...
18.   Found volume group "data" using metadata type lvm2
19.   Found volume group "vg_localhost" using metadata type lvm2
20.   inactive '/dev/data/ftproot' [70.00 GiB] inherit
21.   ACTIVE '/dev/vg_localhost/lv_root' [21.55 GiB] inherit
22.   ACTIVE '/dev/vg_localhost/lv_swap' [1.97 GiB] inherit
23.  
24.  
25. You can now display the logical volumes. 
26.  
27. [root@localhost ~]# lvs -a -o +devices
28.   LV VG Attr LSize Origin Snap% Move Log Copy% Convert Devices
29.   ftproot data -wi--- 70.00g /dev/sda3(0)
30.   lv_root vg_localhost -wi-ao 21.55g /dev/sda2(0)
31.   lv_swap vg_localhost -wi-ao 1.97g /dev/sda2(5518)
32.  
33.  
34. [root@link-07 backup]# lvchange -ay /dev/VG/stripe
35. [root@localhost ~]# lvchange -ay /dev/data/ftproot
36. [root@localhost ~]# lvs -a -o +devices
37.   LV VG Attr LSize Origin Snap% Move Log Copy% Convert Devices
38.   ftproot data -wi-a- 70.00g /dev/sda3(0)
39.   lv_root vg_localhost -wi-ao 21.55g /dev/sda2(0)
40.   lv_swap vg_localhost -wi-ao 1.97g /dev/sda2(5518)
41.  
42.  
43. [root@localhost ~]# mount -t ext4 /dev/data/ftproot /work/
44. mount: wrong fs type, bad option, bad superblock on /dev/mapper/data-ftproot,
45.        missing codepage or helper program, or other error
46.        In some cases useful info is found in syslog - try
47.        dmesg | tail or so
48.  
49. [root@localhost ~]# dmesg | tail -10
50. RPC: Registered tcp transport module.
51. RPC: Registered tcp NFSv4.1 backchannel transport module.
52. SELinux: initialized (dev rpc_pipefs, type rpc_pipefs), uses genfs_contexts
53. SELinux: initialized (dev autofs, type autofs), uses genfs_contexts
54. SELinux: initialized (dev autofs, type autofs), uses genfs_contexts
55. SELinux: initialized (dev autofs, type autofs), uses genfs_contexts
56. eth3: no IPv6 routers present
57. eth1: no IPv6 routers present
58. EXT4-fs (dm-2): VFS: Can't find ext4 filesystem

 

至此，lvm是恢复了，但文件系统看样子是没有办法恢复了。参考“ext3 文件系统超级块损坏的修复”对ext4不起作用，我觉得对ext3/ext2估计都差不多。

 

 

 

事打电话询问LVM故障的处理办法，其实我对LVM也是一知半解，只是恰好在用户现场解决过几次有关LVM的故障。
这次故障的发生是因为不小心，把grub的信息写入到了阵列设备上，而阵列设备是用来做LVM的，导致的结果是pvscan可以得到pv信息，lvscan也能得到lv信息，但是 vgscan却不能。 使用vgcfgrestore命令恢复后，正常了。为了重现用户的现象，我做了另外一个实验，不是vg信息找不到，而是找不到对应 uuid号的设备，过程如下： 

创建pv，vg，lv

 [root@lancy ~]# pvcreate /dev/mdp0   Physical volume "/dev/mdp0" successfully created   [root@lancy ~]# vgcreate vg01 /dev/mdp0   Volume group "vg01" successfully created   [root@lancy ~]# lvcreate  -n lv01 -L+200M vg01   Logical volume "lv01" created   [root@lancy ~]# mkfs.ext3 /dev/mapper/vg01-lv01  -m 0   [root@lancy ~]# mount /dev/mapper/vg01-lv01 /misc   [root@lancy ~]# cp mdadm-2.5.2-1.i386.rpm /misc/   [root@lancy ~]# umount /misc  

 

2）做一个破坏者

    [root@lancy ~]# dd if=/dev/zero of=/dev/mdp0 bs=512 count=3      3+0 records in      3+0 records out      1536 bytes (1.5 kB) copied，7.6469e-05 秒，20.1 MB/秒      [root@lancy ~]# pvscan      No matching physical volumes found      [root@lancy ~]# vgscan      Reading all physical volumes.  This may take a while...      No volume groups found      pv，vg，lv都找不到了，但是vg01-lv01这个设备还是存在的，而且也能mount。不过估计重启后就找不到了。于是恢复。  

 

尝试老办法

 [root@lancy ~]# vgcfgrestore -f /etc/lvm/backup/vg01 -n vg01 -t /dev/mdp0   Test mode: Metadata will NOT be updated.   Couldn't find device with uuid 'fPsp4D-aaxu-YMGZ-gqGn-sbUq-fZE0-YnCbwz'.   Couldn't find all physical volumes for volume group vg01.   Restore failed.  

看来vgcfgrestore不是万能的，怎么办？

 

重写uuid

[root@lancy bin]# pvcreate –uuid fPsp4D-aaxu-YMGZ-gqGn-sbUq-fZE0-YnCbwz –restorefile /etc/lvm/archive/vg01_00001.vg /dev/mdp0 Couldn’t find device with uuid ‘fPsp4D-aaxu-YMGZ-gqGn-sbUq-fZE0-YnCbwz’. Physical volume “/dev/mdp1” successfully created [root@lancy bin]# vgcfgrestore vg01 Restored volume group vg01 [root@lancy bin]# lvs LV VG Attr LSize Origin Snap% Move Log Copy% lv01 vg01 -wi— 100.00M [root@lancy bin]# vgscan Reading all physical volumes. This may take a while… Found volume group “vg01” using metadata type lvm2

 

哈哈，到此搞定！

 

Linux逻辑卷的管理
 

Linux逻辑卷的管理
(1)Linux系统初始化LVM
vgscan
(2)创建物理卷
pvcreate /dev/sda1—————物理磁盘分区路径
(2)创建卷组
vgcreata vg0 /dev/sda1
                    |        ｜________________物理磁盘分区路径
                    |_____________________逻辑卷组名称
(3)创建逻辑卷
lvcreate -n backup1 -L 500G vg0
                         |                     ｜     |_______逻辑卷组
                         |                       |__________逻辑卷大小
                         |___________________逻辑卷名
(4)格式化逻辑卷
mkfs.ext3 /dev/vg0/backup1
(5)迁移逻辑卷vg信息
1.       在主机A上   
vgcfgbackup vg0
此命令将vg0的信息备份下来，产生一个/etc/lvm/backup/vg0文件，将此文件传到主机B上，注意此文件的权限，它默认是300，属主和属组都是root，如果你不是root用户，需要改变此文件的权限才能下载。
 2.导入vg信息
mkdir /etc/lvm/backup      在/etc/lvm下创建目录backup
      将主机A上的vg0              文件传到/etc/lvm/backup目录下
      vgcfgrestore vg0             在主机B上将vg0导入
      vgchange –ay             激活卷组

转载至