Damaged xen server repository (sr) Data Recovery Solution

Common Faults]

1. sr cannot be identified. All Virtual Disks (vdi) are lost. 2. errors are reported when the Virtual Disks (vdi) in the sr are accessed. 3. Virtual Disks (vdi) are deleted or lost. 4. snapshots are taken) delete or lose 5. sr initialization 6. The LVM structure where the sr is located is damaged 7. The PV partition table to which the sr belongs is damaged 8. Other Fault Analysis] The above common faults are the performance of the user interface layer, to explore the solution, you only need to understand the structure of the xen server sr layer. The above faults can have a clear solution. The structure of the xen server sr repository is mostly based on linux lvm. Each vdi in the sr is equivalent to a lv in lvm, while the lvm can be constructed based on the partition table of traditional MBR or the Partition Table of GPT. For example, if there is a 1 TB single hard disk, assuming it is/dev/sdb, and you want to initialize it as SR, it is usually a 1 tb pv first partitioning (MBR or GPT, of course, it can also be divided), after the partition, and then create/dev/sdb1 (assuming you want to process the first partition) into an LVM volume, and then create a LV, these LV is VDI. The xen server also backs up the LVM information, which is stored under/etc/lvm and named like a VG_XenStorage-151befd1-2224-5e06-914e-f15243f649d7_00103.vg in the standard lvm xml format description. The above is almost all the structure information of the SR repository, and almost all the damages are caused by the incompleteness of the above information. Different damage combinations of the above information generate different solutions. Solution: 1. When the PV Partition Table is damaged (applicable to common faults 1 and 7): The PV Partition Table damage is not related to SR, but directly affects SR access, the repair process is the same as that for common partition tables. The MBR or GPT partition tables are modified. Ii. When the LVM structure is damaged (applicable to common faults 1 and 6): the LVM structure is damaged mostly in the lvm xml Information area, you can use the LVM information backup of the xen server to restore the data. Of course, this backup information may be damaged. Iii. When the LVM structure is damaged and the backup information is damaged (applicable to common faults 1 and 6): this is a real technical problem. When the LVM structure and backup information are damaged, the index information of all LV fragments is lost. The task is to retrieve the lv extents information of each VDI. Xen vdi is based on the VHD format jointly developed by Connectix and Microsoft. It usually adopts a simplified growth mode (like the esx vmdk), that is, vdi increases with the growth of usage, it is not how much space is allocated. The advantage is that it can save space, but the disadvantage is that the allocation cannot be too continuous and there will always be several vdi interaction application spaces at the same time. To restore these fragments (fragment information), the information that can be referenced from the upper layer is very limited. In most cases, only the correlation within the VHD format can be used, starting from the VDI header, the extent fragment structure is continuously corrected by the lv pe offset based on some information that can be matched before and after. This process is usually difficult to perform manually. Therefore, the data recovery center in North Asia has specially developed a program to verify the forward and backward offsets of the vhd format for matching. The detailed algorithms are not publicly available for the moment, however, you can refer to this article and my own <storage layout series VHD structure details> for algorithm design and development. After obtaining the fragment information of each VDI, you can use the fragment information to correct the LVM information or directly export it to a VHD file. Iv. vdi internal structure damage (applicable to all possible faults): Damage to the internal structure of vdi is equivalent to repair of disks in vhd format. For a vhd virtual disk, each converted physical block consists of an index table and block content. If the information of both parts can be found, the block at this position can be repaired. A vhd composed of all repaired blocks and unrecoverable blocks is like processing a bad track disk. It depends on the structure destruction of the internal file system. The next step is, you can refer to other solutions to remove the xen server sr layer and vdi vhd layer. Summary: The different combinations of the above four solutions are the solutions for all xen server sr faults. For example, to delete a vdi instance, you must first check whether LVM Backup exists. If yes, you can recover it by backup. If not, perform a complex combination based on the internal structure of the vdi instance. Data Migration solution: recovery in most cases refers to the recovery of vdi (vhd. In this way, there are several migration solutions after data recovery: 1. Data Processing after LVM information is corrected: After LVM information is corrected, if the xen server configuration information still exists, after re-obtaining the sr, all data can be completely restored. If the xen server is damaged or reinstalled, the sr must be activated as follows (the information on the Internet is modified but has been verified ): 1, list all volumes: Command: pvscan, obtain pv uuid as the output is PV/dev/sda3 VG VG_XenStorage-9ae1044f-d335-8143-d630-a6f546e57db7 lvm2 [66.52G/56.52 GB free]

Record uuid "region" 2 and create the UUID storage command: xe sr-introduce uuid = 9ae1044f-d335-8143-d630-a6f546e57db7 type = lvm name-label = "Local storage" content-type = user3, find the scsi id of the SR data storage device or partition

Command: ls-l/dev/disk/by-id/

Total 0

Lrwxrwxrwx 1 root 9 Aug 18 scsi-SATA_ST380811AS_9PS04Q4A-<.../sda

Lrwxrwxrwx 1 root 10 Aug 18 scsi-SATA_ST380811AS_9PS04Q4A-part1-<.../sda1

Lrwxrwxrwx 1 root 10 Aug 18 scsi-SATA_ST380811AS_9PS04Q4A-part2-<.../sda2

Lrwxrwxrwx 1 root 10 Aug 18 scsi-SATA_ST380811AS_9PS04Q4A-part3-<.../sda3

4. Run xe host-list 5 to list the server UUID. Run the following command to check the pdb uuid: xe pbd-create sr-uuid = your device-config: device =/dev/disk/by-id/scsi-SATA_ST380811AS_9PS04Q4A-part3 host-uuid = 4ca6582a-364b-4da2-a206-618438ae4dee get pbd uuid: ipv6, run the storage restoration command xe pbd-plug uuid = 0d65a15e-75a0-dc81-8bb5-79df3e6d96db 7. Create vps, Mount All retrieved vdi files, and export the data to vhd. If you export the recovered vdi to the vhd format, you can perform vhd mounting on windows 7 and windows server 2008, however, this solution is not suitable for VHD with snapshots. 2. Create nfs, import vhd for sr restoration, and perform operations directly on the xen server. 3. directly use winhex for vhd data interpretation, read the data, but this solution is not suitable for VHD with snapshots. 4. Refer to <vhd to img source code> written by myself (Zhang Yu, North Asia data recovery center) to convert VHD or snapshot, for data interpretation. 5. Use virtual machines such as VPC and VBOX to directly Mount Virtual Disks in vhd format and interpret data.

This article is from the "Zhang Yu (data recovery)" blog, please be sure to keep this source http://zhangyu.blog.51cto.com/197148/1184910