Case:
After a sudden power outage, the ESXi system could not be stored. The administrator found that there was a problem with the UFS2 file system in the freeNAS. Then the administrator used FSCK to repair the file system. At this timeIt was found that the ESXi system failed to recognize the original data storage and VMFS file system. After the administrator formatted VMFS, it was found that the data inside was empty.
Solution:
The mirror engineer FreeNAS layer analyzes the entire storage, and found that there is a large file of more than 900 GB, the file name: ISCSIDATA. Through the binary structure of the UFS2 file system, the ISCSIDATA file’s INODE data is located, and this file has been rebuilt. The amount of data pointed by the INode pointer is very small. Further analyze the FreeNAS layer and collect the important structure of the UFS2 file system: block size: 16KB, segment size: 2KB, column surface size: 188176 kb. UFS2’s data pointer accounts for 8 bytes, and one piece can store 2048 data pointers. Then a second -level pointer block can be stored: 2048*2048*16KB u003d 64GB data. A three -level pointer block can store 64GB*2048 u003d 128TB data. In order to find the third -level pointer block of the ISCSIDATA file, the use of useful pointer blocks on the spot: Since the ISCSIDATA file uses a sparse mode, the collection conditions can only be relaxed. Analysis of all three -level pointer blocks collected is invalid. Three -level pointer blocks used by ISCSIDATA files are estimated to be newly covered when new iSCSIDATA files are newly covered (the new iSCSIDATA file is mounted to ESXI5.0 There is a VMFS formatting process, and ESXi5.0 uses GPT partitions. The GPT partition will be written into the redundant GPT header and partition table information data at the end of the disk, which will use the third -level pointer block of the iSCSIData file). At present, you can only analyze the second -level pointer blocks collected, DUMP with a large number of two -level pointer blocks, and then locate the data from the disk to the secondary pointer. Get a lot of DUMP data in this way. Analysis of the VMFS layer: re -formatted VMFS, and the pointer of the original UFS2 has been lost, resulting in the VMFS meta files that are basically unavailable. There is no important reference information. Fortunately, the virtual machine has no snapshots and can still be recovered. Through a single virtual machine layer (Windows (NTFS) and FREEBSD (UFS2) system structure structure), position it up to the VMFS layer, and locate a single 64GB file from DUMP through the VMFS layer. The virtual disk of important virtual machines of Taiwan has completely recovered. The customer uploaded the restored web page data and database data to a newly built system, and the application was pulled up. The data was completely fine.