Data recovery scenarios for Xen Server repository (SR) corruption

"Common failures"

One, SR unrecognized, all virtual disk (VDI) lost

Virtual Disk (VDI) Access times in the SR error

Third, virtual disk (VDI) deletion or loss

Iv. snapshots (snapshot) deleted or missing

V. SR initialization

Vi. the LVM structure of the SR is corrupted

The PV partition Table of the SR belongs to the damaged

Viii. Other Failures

"Fault Analysis"

The common fault is the user interface layer performance, to explore its solution in fact same, only need to understand the structure of the Xen server SR layer, the fault can have a clear solution to the idea.

The structure of the Xen Server SR repository consists of most of the Linux LVM,SR per VDI equivalent to one LV in LVM, while the build LVM can be managed based on a traditional MBR partition table or GPT partition table. For instance, if you have a 1TB single hard drive, suppose to be/dev/sdb, you want to initialize to SR, usually 1T PV first partition (MBR or GPT, of course, can also not be divided), after dividing the area, then/DEV/SDB1 (assuming to process the first partition) create an LVM volume, Which creates LV again, these LV is VDI.

Xen server also backs up these LVM information, stored under/ETC/LVM, name-like VG_XENSTORAGE-151BEFD1-2224-5E06-914E-F15243F649D7_00103.VG, and content is standard LVM XML Information Format description.

These are almost all of the structural information in the SR repository, all of which are based on incomplete information about the above.

The different damage combinations of the above information derive different solutions.

"Solution"

First, when the PV partition table is damaged (suitable for 1, 7 of common faults):

The PV partition table corruption does not matter with the SR, but directly affects the access to the SR, and the repair process is the same as normal partitioned table fixes, modifying the MBR partition table or GPT partition table.

Second, when the LVM structure is damaged (applicable to 1, 6 of common failures):

Most of the LVM fabric corruption is corrupted by the LVM XML information area, and can be considered for recovery through the Xen server's LVM information backup. Of course, it is possible that this backup information has also been corrupted.

Third, when the LVM structure is corrupted, the backup information is also damaged (for 1, 6 of common failures):

This is the real technical problem, when the LVM structure and its backup information is corrupted, all the LV Fragment index information is all lost, the work to do is to retrieve the LV extents information for each VDI.

Xen VDI is based on the VHD format developed jointly by Connectix and Microsoft, typically with a streamlined growth model (as in the Esx vmdk), which means that VDI grows with the growth of usage, not how much is allocated. The advantage of this is that space can be saved, but the disadvantage is that the distribution is not too continuous, there will always be several VDI interactive application space. To recover these fragments (fragmentation information), information that can be referenced from the upper level is very limited, and in most cases, the extent fragment structure can be continuously corrected by the offset of the LV PE from the head of VDI through the correlation within the VHD format. This process is usually very laborious manual operation, for this reason, the North Asian Data Recovery Center is also deliberately developed to the VHD format for the previous backward offset check program to match, the detailed algorithm is not publicly available, but can refer to this article and I write <storage Layout series of VHD structure of the detailed > The algorithm is designed and developed.

After obtaining fragmentation information for each VDI, the LVM information can be modified or exported directly to the VHD file through fragmentation information.