Accidentally remove the VMware virtual machine vmdk File Recovery process _ Recover data

Dell R710 Series servers (for VMware virtual hosts), Dell MD 3200 Series storage (for storing virtual machine files), VMware ESXi version 5.5, causing a virtual machine not to start properly due to accidental power outages, When you view the configuration file for a virtual machine, you find that the configuration file for this virtual machine is missing all but the disk files. The XXX-FLAT.VMDK disk files and xxx-000001-delta.vmdk snapshot files also exist. After looking for a VMware engineer to troubleshoot, try creating a new virtual machine to troubleshoot, but found ESXi storage space is low. As a result, the XXX-FLAT.VMDK disk files under the failed virtual machine are deleted, then the ESXi storage has more than 200 g of space left, then VMware engineers rebuild a 40G virtual machine, and assign a fixed size virtual disk, Windows Server 2008 (Virtual machine operating system), database application environment SQL Server 2008 database server (Managing macro bridge and Sophie two application databases), virtual machine disk capacity 200G data Disk (compact mode) + 160G snapshot data disk.

Fault analysis

1, Backup data

The VMFS volumes in the rd220i storage that are mounted on the VMware vsphere client are unloaded in a normal manner. The VMFS volumes on the rd220i storage are then connected to the backup server by means of a network cable. The entire VMFS volume is then mirrored to the prepared backup space using a professional tool to ensure that the customer's data is secure, and subsequent analysis and recovery operations are performed on the backed-up data.

2, analyze the cause of failure

Careful analysis of the underlying data on the VMFS volume found that the sudden power outage of the ESXi host damaged the directory entries in the directory of the failed virtual machine, but the damage did not affect the virtual machine's important data, but only the directory entries of the file, which could be solved by manual repair. When a file is deleted, the index of the data area corresponding to the catalog entry is cleared, and the actual data for the deleted file is not affected. This situation can be matched and merged in the free space of the VMFS volume by deleting the file system in the virtual disk file and the type of file on the virtual disk, and eventually restoring the deleted virtual Disk file. However, in both cases, a new virtual machine was created and a virtual disk was assigned. After careful analysis found that the assigned 40G virtual disk has been completely cleared (when creating a virtual disk will choose the type of disk creation), but also the new virtual machine occupied by all the disk space cleared. If the new virtual disk occupies the space freed by the removal of the virtual machine disk, then this part of the space will not be recoverable.

The following figure: (Is the directory entry area of the failed virtual machine)

Implementation direction

1. Implementation direction One: Restore deleted vmdk files

Based on the deletion of the file system in the virtual disk file and the type of file on the virtual disk for fragmentation matching and merging in the free space of the VMFS volume, the deleted virtual disk files are eventually restored, and the snapshot files and recovered virtual disk files are merged into a full virtual disk file by using the snapshots Merge program. Then use the Professional File system interpretation tool to interpret all the files in the virtual disk file.

2. Implementation direction Two: Restore MSSQL database files

If the direction-one implementation is less than ideal, the next step is to count, analyze, and aggregate the data regions in the VMFS volume free space that conform to the SQL Server page structure based on the structure of the SQL Server database file, resulting in a normal use. MDF-formatted file.

3, Implementation Direction Three: Restore MSSQL database backup files

Since the database is being backed up daily, it is backed up 15 days at a time, even if it is incremental every day. However, if there are some databases that cannot be recovered after the two schemes have been implemented, the database can only be recovered using the recovery backup files. Based on the structure of the backup file. bak, statistics, analysis, and aggregation of data regions that match the structure of the SQL Server backup file in the VMFS volume free space, resulting in a file that is normally imported into the SQL Server database. bak format.

Recovery process

1, direction one implementation process

Follow the direction of one of the basic analysis, according to the structure of the VMFS volume and delete the virtual disk file system information, in the underlying free space to scan for the deletion of virtual machine disk area, and statistics its number and size of the deleted virtual disk size. The scanned fragments are then grouped according to the information in the file system on the virtual disk, and there are a lot of missing pieces in the middle, and the missing fragments are carefully scanned again to find that the fragments are not actually found. The scanned fragments are then reorganized into the original sequence of the virtual disks, leaving blank for the fragments that are not found. Next, the virtual disk snapshot program is used to merge the restructured parent disk and the snapshot disk to generate a new virtual disk. Then use professional tools to explain the virtual disk file system, due to the lack of a lot of data, file system interpretation process reported a lot of errors, prompting some file damage.

The explained file system is shown below:

After parsing the file system, we found that the original database file was not found, while the directory structure of both the macro bridge backup and the Sophie Backup is normal. However, when you try to import a backup into the database, the database importer prompts an error.

The partial directory structure of the macro bridge backup and the Sophie Backup is shown below:

Import. BAK file error information is as follows:

2, direction two implementation process

The original database file was not recovered in direction one, and many of the backup files were not working properly. Therefore, a second set of scenarios is required to recover the database files that have not been recovered. According to the structure of the SQL Server database, go to the free space to find the starting position of the database. In the structure of the database, page 9th of the database records the database name of the database. So according to this feature you can check if the header page of this database is looking. and the database page number and file number are recorded on each page of the database, so you write the database scanner based on these features, and then use the program to scan the bottom of all data fragments that match the database pages. The scanned fragments are then sequentially formed into a full MDF file, and the MDF verifier is used to detect the integrity of the entire MDF file. During the entire validation process, only cl_system3.dbf and erp42_jck.dbf were found to be successful because of the partial fragmentation of the database. The MDF file that is finished is as follows:

CL_SYSTEM3.DBF and ERP42_JCK.DBF are not able to find a lot of debris at the bottom (initial suspicion may be covered), so the checksum does not pass. The following is a missing area of a fragment in the cl_system3.dbf file:

3, direction three implementation process

Since the above two directions have been implemented, all of the database files have not been recovered, and cl_system3.dbf and erp42_jck.dbf files are not used properly due to missing part of the page. As a result, backups are required to restore the two database files, but after checking the backup of the two files, CL_SYSTEM3.DBF's March 30 full backup was not backed up because of a backup mechanism failure, and erp42_ JCK.DBF March Backup all not, only April full incremental backup, the following figure:

Because only a small number of pages are missing from the erp42_jck.dbf file, you can find it in an incremental backup based on the missing page number, and then patch the found page into the erp42_jck.dbf file, which restores some of the missing database pages. After the final completion or missing part of the page, can not be used normally. However, you can successfully export the dozens of tables that are important to users in the erp42_jck.dbf file through the self-developed database resolver, and successfully import them into the newly created database.

Validating data

Build a database environment (SQL Server 2008) that is the same as the original environment on the local server, where the client connects to the authentication server through the TeamViewer Remote tool and installs the upper-layer macro-bridge application. Then the client arranges the project to verify the integrity of the database, after careful verification, the database recovery is basically no problem. The upper application can run normally, the data record is basically not missing, the data recovers successfully.

The database was successfully mounted, as shown in the following figure:

Recovery summary

Because of the knowledge of the underlying structure of the SQL Server database and experience with similar types of failures. So the whole recovery process was relatively smooth. The database is properly restored and the validation is not a problem and the entire data is restored successfully.