Virtual machine virtual disk recovery case tutorial

This small series shares the memory after a sudden power failure ,ESXi The system is not connected to storage , stay FreeNAS Found in UFS2 There is a problem with the file system , Then use fsck Fixed the file system . here ESXi The system can be connected to storage , But found ESXi The system fails to recognize the original data storage and VMFS file system , format VMFS There was nothing in it , In this case, how can we save the data to the greatest extent ？

Preliminary inspection of equipment

After preliminary inspection by the engineer , The physical storage architecture is in one DELL Server , Use FreeNAS To do it iSCSI, Then use two DELL The server does ESXi5.0 The virtualization system of .

FreeNAS Layer for UFS2 file system , Build a sparse file for the entire storage , Hang to ESXi5.0 System .ESXi There are... In the system 5 Virtual machines , Three of them are the most important . a windows2003 The system virtual machine is the local portal of the company . Use ASP.net and PHP Hybrid framework , Use database for SqlServer2005 and mysql 5.1 . One for FreeBSD System , Ran you Mysql database , For other virtual machines . One for windows2003 The server , Store the newly developed program code of the company .

Analyze faults , How to use available information

Analyze faults , Maximize the use of available information . Begin to peel the cocoon , Application architecture hierarchy ：FreeNAS(UFS2 file system –> A large sparse pattern file ) –> ESXi 5.0(VMFS File system layer ) -> Virtual disk of a single virtual machine (windows-NTFS file system /FreeBSD-UFS2 file system ).

How does data recovery work ？

The first step is mirroring FreeNAS layer , Then analyze the entire storage , Just one 900 many GB The large files , file name ： iscsidata. adopt UFS2 Binary structure of the file system , Locate the iscsidata Of documents Inode data , It is found that this file has been rebuilt ,inode The amount of data pointed to by the pointer is very small .FreeNAS Layer cannot solve , You can't go to the next step VMFS Layer analysis .

collect UFS2 Important structure of file system ：

Block size ：16KB

Segment size ：2KB

Cylinder group size ：188176 KB

UFS2 A data pointer accounts for 8 byte , A block can store 2048 A data pointer . Then a secondary pointer block can store ：2048*2048*16KB= 64GB data . A three-level pointer block can store 64GB*2048= 128TB data . If you can find iscsidata The three-level pointer block of the file can solve FreeNAS Layer problem . but iscsidata The file was rebuilt , The process and size are the same as the original , It is estimated that some pointer blocks have been overwritten . original iscsidata Of documents inode And the new iscsidata Of documents inode In one place , Try searching , No other useful inode appear . I have to write a program on site to collect useful pointer blocks , because iscsidata The file is in sparse mode , Collection conditions can only be relaxed , A large number of three-level pointer blocks and two-level pointer blocks are collected . Analyze all three-level pointer blocks collected , It's all invalid , nothing iscsidata The three-level pointer block used by the file , Estimated to be newly built iscsidata The file is overwritten by a new （ new iscsidata The document is being attached to ESXi5.0 There's a VMFS Formatting process , and ESXi5.0 Use GPT Partition ,GPT The partition will write redundancy at the end of the disk GPT Header and partition table information data , This will use iscsidata Third level pointer block of file ）.

At present, only the collected secondary pointer blocks can be analyzed , For the pointing data with a large number of secondary pointer blocks DUMP, And then from the data in the disk to the secondary pointer . That's a lot of DUMP The data of .

To analyze VMFS layer ：

Reformatted VMFS, And primitive UFS2 The pointer to has been lost , cause VMFS Metafile is basically unavailable , No important reference information , Fortunately, none of the virtual machines have snapshots , Can still recover .

Through a single virtual machine layer (windows(NTFS) and FreeBSD(UFS2) File system structure of the system ), Position up to VMFS layer , Through VMFS Layer positioning to DUMP Out of a single 64GB file , Through multiple combinations , Finally, the virtual disks of these three important virtual machines have been completely restored . Upload the recovered web page data and database data to a newly built system , Pull up application , The data is completely free of problems , This data recovery is successful .