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

[FreeNAS Storage Summary]

First of all, we need to understand what is NAS storage?

NAS (Network Attached Storage) network attached storage, NAS mode is a comprehensive improvement of the previous inefficient DAS storage. It uses a file server which is independent of the server and developed separately for network data storage to connect the stored devices and form a network. In this way, the data storage is no longer attached to the server, but exists in the network as an independent network node and can be shared by all network users.

So what kind of storage mode is FreeNAS?

FreeNAS is a free NAS server that can turn an ordinary PC into a network storage server. The software is based on FreeBSD, Python, and supports CIFS (samba), FTP, NFS protocols, Software RAID and web interface setting tools.

Based on the understanding of the above stored information, today I will give you a brief introduction to the specific recovery model operation.

[fault background Overview]

A company uses iSCSI to achieve the function of FC SAN. Physical storage is built on a DELL server, using FreeNAS to do iSCSI, and then using two DELL servers to do ESXi5.0 virtualization system.

The FreeNAS layer is the UFS2 file system, and a sparse mode file is built for the whole storage and hung to the ESXi5.0 system. There are five virtual machines running in the ESXi system, of which three are the most important. A windows2003 system virtual machine is the company's local portal. The mixed architecture of ASP.net and PHP is used, and the database is SqlServer2005 and mysql 5.1. One is a FreeBSD system with Mysql database, which is used by many other virtual machines. One is a windows2003 server, which stores the newly developed program code of this company.

[fault Information Overview]

After a sudden power outage of storage, the ESXi system was not connected to storage, and the administrator found a problem with the UFS2 file system in FreeNAS, and then the administrator repaired the file system with fsck. At this time, the ESXi system can be connected to storage, but found that the ESXi system could not recognize the original data storage and VMFS file system. The administrator formatted the VMFS and found that it was empty.

[specific recovery plan operation]

Analyze faults and maximize the use of available information.

Application architecture level: FreeNAS (UFS2 file system-> a large sparse mode file)-> ESXi 5.0 (VMFS file system layer)-> virtual disk of a single virtual machine (windows-NTFS file system / FreeBSD-UFS2 file system).

The first step is to mirror the FreeNAS layer, and then analyze the entire storage to find a large file of more than 900 GB, file name: iscsidata. Through the binary structure of the UFS2 file system, locate the Inode data of the iscsidata file, and find that the file has been rebuilt, and the inode pointer points to a small amount of data.

If the FreeNAS layer cannot be solved, it will not be able to proceed to the next step of VMFS layer analysis.

Collect important structures of the UFS2 file system:

Block size: 16KB

Segment size: 2KB

Cylindrical group size: 188176 KB

UFS2 A data pointer occupies 8 bytes, and a block can store 2048 data pointers. Then a secondary pointer block can store: 2048204816KB = 64GB data. A third-level pointer block can store 64GB 128TB data. If you can find the third-level pointer block of the iscsidata file, you can solve the FreeNAS layer problem. But the iscsidata file has been rebuilt, the process and size are the same as the original, and it is estimated that some of the pointer blocks have been overwritten. The inode of the original iscsidata file and the inode of the newly created iscsidata file are in the same place, trying to search, and no other useful inode appears. You have to write a program on the spot to collect useful pointer blocks:

Because the iscsidata file uses sparse mode, the collection conditions can only be relaxed, collecting a large number of third-level pointer blocks and secondary pointer blocks. All the collected third-level pointer blocks are invalid, and there is no third-level pointer block used by iscsidata files, which is estimated to be newly overwritten when creating a new iscsidata file (the new iscsidata file has a VMFS formatting process after being mounted to ESXi5.0, while ESXi5.0 uses GPT partitions, and GPT partitions write redundant GPT headers and partition table information data at the end of the disk, which uses the third-level pointer blocks of iscsidata files).

Now we can only analyze the collected secondary pointer blocks, DUMP the pointing data with a large number of secondary pointer blocks, and then locate the secondary pointer from the data in the disk. In this way, we can get a lot of DUMP data.

Start analyzing the VMFS layer:

The VMFS has been reformatted and the pointer to the original UFS2 has been lost, so that the VMFS metafile is basically unavailable and has no important reference information. fortunately, the virtual machine does not have a snapshot and can still be restored. Through the file system structure of a single virtual machine layer (windows (NTFS) and FreeBSD (UFS2) systems), navigate up to the VMFS layer, navigate to a single 64GB file out of DUMP through the VMFS layer, and through multiple combinations, the virtual disks of the three important virtual machines have been restored. Upload the recovered web page data and database data to a newly built system, pull up the application, and the data is correct.

[recovery result]

After acceptance by the user, the data is the required information, and the acceptance is correct, so the data recovery work is completed.

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.