Shulou(Shulou.com)06/02 Report--

The case I share with you today is the information management platform of a provincial branch of Sinopec. Several VMware virtual machines-ESX SERVER share an IBM DS4100 storage, and there are about 40-50 virtual machines, which occupy 1.8TB space. Data is very important.

In normal work, the loss of the virtual disk is reported in vc. Ssh executes fdisk-l in ESX to check the disk and finds that storage has no partition table. After rebooting all devices, ESX SERVER cannot connect to the STORAGE where the DS4100 is located.

After carefully questioning the administrator at that time, they mentioned that an windows 2003 server had been connected to this storage network, but the details were unknown.

It is natural to think that the windows 2003 may have corrupted the entire vmfs volume due to its exclusive operation on storage.

According to the analysis of the whole storage, it is found that the partition table is clear 0, there is a 55aa valid end flag, and there is a hard disk ID flag. Simply looking from front to back, I found a NTFS volume, but it did not seem to write data into it, like a volume that had just been formatted. By analyzing the BITMAP of this NTFS volume, we found that the size was about 1.8T (all space), the front part occupied part of the space, the 3G around position occupied part of the space, and the 0.9T area occupied part of the space, but the total space was no more than 100m. Based on the analysis of the VMFS volume, it is found that there are two groups of VMFS partitions in the original 1.8TB disk, the second group is about the first group of extend, the first group is about 1.5T, the second group is about 300GB, because the NTFS partition does not write data to the second VMFS partition (the DBR backup of the last sector does not cover the useful data), so the focus is on the first VMFS partition. According to the analysis of the first group of VMFS, the header structure is lost, the first-level index and the second-level index exist, and the data area covered by NTFS happens to be the temporary memory mirror of a group of virtual machines.

Through the above analysis, we can recover the data.

Step 1: mirror backup the entire STORAGE.

Step 2: after analysis, connect two VMFS partitions and extract all VMDK and configuration files directly according to the organization of VMFS analysis.

Step 3: migrate back to ESX SERVER directly through nfs.

In addition: in this example, because the fault storage has been securely backed up, the first set of VMFS volume headers, index lists, partition tables and other information are directly rebuilt during the repair, which is directly attached to the ESX SERVER environment, which is the second solution.

After two days of efforts, the data has been successfully restored. I would like to thank the engineers for their efforts.

[other]

1. In this example, the problem is still caused by improper mutual exclusion in the optical fiber environment. In fact, the volume should be repartitioned on the WINDOWS system and formatted into NTFS, and then the partition is deleted. Because the mutex of ESX VMFS does not depend on hardware, it only depends on the driver layer of the operating system, so we must be careful when other servers connect to the storage network and try our best to consider the storage allocation permissions.

2. Because of the convenient centralized management of information, ESX data is often very important in real use. We must do a good backup and consider the convenience of migration in case of damage.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.