Easy to handle VMware virtual machine data Recovery _vmware

This article is a case of data recovery for VMware virtual machines, although the entire VMware virtual machine data recovery process takes only three steps, but the problem analysis and experience summary are worth your reference.

A summary of the data recovery case for a VMware ESX server that took over a few days ago

[Data recovery failure description]

Sinopec Branch of a province, information management platform, several VMware virtual machine--esx server share an IBM DS4100 storage, about 40~50 group of virtual machines, occupy 1.8TB space, data is important.

Normal work, VC reported virtual disk lost, SSH to ESX in the implementation of Fdisk-l view disk, found that storage has no partition table. After rebooting all the devices, the ESX server cannot connect to the storage where DS4100 resides.

Ask the administrators at the time, and they mention a bit that they once had a Windows 2003 server connected to the storage network.

[Data Recovery analysis]

It was natural to think that the Windows 2003 could have caused the entire VMFS volume to become corrupted because of the exclusive operation of storage.

Analyze the entire storage to find:

1, the partition table clear 0, has the 55AA valid end sign, has the hard disk ID mark.

2, simple front and back view, found an NTFS volume, but did not appear to write data, like a newly formatted volume, the NTFS volume of the bitmap do analysis, learned that the size of about 1.8T (all space), the front occupies part of the space, 3G occupy part of the space around, 0.9T occupy part of the space, but the total occupancy space does not exceed 100M.

3, for the VMFS volume analysis, found in the original 1.8TB disk has 2 sets of VMFS partitions, the 2nd group is the first group of extend, the first group of about 1.5T, the second group of about 300GB, because the NTFS partition does not write data to the second VMFS partition ( The DBR backup of the last sector does not overwrite the useful data), so the focus is on the first VMFS partition.

4, the analysis of the first group of VMFS, the loss of the volume head structure, primary index, two-level index exists, NTFS-covered data area is just a group of virtual machine Temporary memory mirror, damage is no harm.

[Data recovery process is only three steps]

1, the entire storage for a mirrored backup.

2. After analysis, connect two VMFS partitions and extract all VMDK and configuration files directly according to the VMFS analysis organization.

3. Migrate directly back to ESX SERVER via NFS.

Another: In this case, because the fault storage has done a secure backup, the repair in the same time directly rebuild the first set of VMFS volume Head, index list, partition table and other information, directly attached to the ESX server environment, is the second scenario.

[Data Recovery Results]

Takes 2 days (excluding migration time), all data is restored successfully

Other

1, in this case is still due to the problem of incompatible fiber environment, in fact, it should be the volume in the Windows system has been repartition, and formatted as NTFS, and then the partition did delete operations. Because the mutual exclusion of ESX VMFS is not dependent on hardware and relies only on the operating system driver layer, it is important to be careful when other servers are connected to the storage network and to consider storage allocation permissions as much as possible.

2, ESX because of convenient information centralized management, the real use of data is particularly important, we must do a good job of backup, and consider the ease of migration when the damage.

The above is the entire content of this article, I hope to help you learn, but also hope that we support the cloud habitat community.