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

[storage server introduction]

The failed server is stored in a common storage mode, the physical storage is a Dell server, and the virtualized system is esxi5.0. The upper layer uses iSCSI to realize the FCSAN function, and the upper layer iSCSI is built by FreeNAS.

The FreeNAS layer of the server uses the UFS2 file system, and there are three virtual machines in the virtualization system. The focus of this server data recovery is on these three virtual machines. One of the virtual machines uses the FreeBSD system to store database files, while the other two store website data and Windows2003 servers respectively, storing database data and working program code.

[storage server failure process]

The instability of the power supply system in the client computer room caused the server storage to shut down abnormally, and the ESXI system could not connect to the storage after reboot. The computer room administrator conducted troubleshooting on the server and found that the UFS2 file system of FreeNAS failed due to abnormal shutdown, so the file system was repaired by fsck and the ESXI system was connected to the server storage.

The administrator checked the upper file system and data, found that the file system and stored data on the original server could not be identified, formatted the vmfs and other operations, resulting in data loss.

[server stores data recovery process]

After receiving the client's server hard disk, the data recovery center first mirrors the FreeNAS layer, and then carries on the underlying data analysis. The server data recovery engineer found a large file named iscsidata in the storage with a capacity of about 900G. The server data recovery engineer continues to analyze the file system structure and navigate to the iNode data of this large file according to the storage structure of the UFS2 file system for further review.

Through inspection, it is found that the iscsidata file has been rebuilt before, and the amount of data pointed to by the iNode pointer is very small. In this case, if you want to enter the vmfs file system layer for data analysis and recovery, you must first analyze the necessary information and data at the FreeNAS level. The server data recovery engineer got the following information through analysis.

The block size of UFS2 file system is 16kb, the size of cylinder group is 2kb, the size of cylindrical group is 188176kb, the size of each data pointer is 8 bytes, and each block can hold 2048 data pointers.

From this information, it can be calculated that the amount of data that can be stored by a secondary pointer block = 2048204816KB=64GB. The amount of data that can be stored in the tertiary pointer block = 64GB*2048=128TB.

The server data recovery engineer plans to recover the data of the FreeNAS layer through the third-level pointer block of the iscsidata file, but because the file has been rebuilt, some of the pointers are overwritten by the reconstructed data, the iNode of the original file is exactly the same as the reconstructed file iNode, and there is no other data available for data recovery iNode data.

According to the actual data situation of the server, the server data recovery engineer wrote Mini Program to collect useful pointer blocks with broader conditions than in the past, and collected a large number of secondary pointer blocks and tertiary pointer blocks.

The server data recovery engineer first analyzed the third-level pointer blocks, but it is a pity that these pointer blocks are invalid after checking, so they are useless in this server data recovery (estimated to be overwritten during reconstruction. The new iscsidata file has a VMFS formatting process after being mounted to ESXi5.0, while ESXi5.0 uses GPT partitions. GPT partitions write redundant GPT headers and partition table information data at the end of the disk. This uses the third-level pointer block of the iscsidata file.

Continue to analyze the secondary pointer block, DUMP the pointing data with a large number of secondary pointer blocks, and then navigate from the data on disk to the secondary pointer. So we can get a lot of DUMP data.

Server data recovery engineers use the previous research of NTFS and UFS2 file system structure to locate to the vmfs layer, and then locate a single 64GB file out of DUMP for data combination.

After complex query and reorganization operations, the server data recovery engineer successfully recovered the three virtual machines and all the data in the virtual machines stored by the client server.

[verification of server data recovery results]

The server data recovery engineer uploads the recovered data to the newly built system for verification, and after verification by the customer administrator, all data recovery is successful, and the success rate of this data recovery is 100%.

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.