Shulou(Shulou.com)05/31 Report--

Today, I would like to talk to you about how the data of EMC Isilon is recovered, which may not be well understood by many people. In order to make you understand better, the editor has summarized the following contents for you. I hope you can get something from this article.

[fault description]

Due to hacking in a university, the important data of its "teaching system" has been deleted. It includes the MSSQL database in the "teaching system" and a large number of video teaching files of MP4, ASF and TS types. The overall storage architecture uses EMC high-end network NAS (Isilon S200), the number of nodes is 3, each node is equipped with 12 3T STAT hard drives, no SSD. All the data is divided into two parts, one is the vmware virtual machine (WEB server), which is shared to the ESX host through the NFS protocol, and the other is the video teaching file, which is shared to the virtual machine (WEB server) through the CIFS protocol. The hacker only deleted all the data shared by NFS (that is, all virtual machines), while the data shared by CIFS was not deleted.

[data backup]

Due to the consideration of data security and avoiding secondary damage to the data, all hard drives need to be fully backed up. However, because the number of disks is too large (12 disks per node and 36 disks per node), and the capacity of a single disk is too large (single disk 3TB, a total of 108TB), the backup cycle will be longer. The end customer decided to back up only the existing data in the storage, and the North Asia backup once, and the customer backup again to ensure the security of the existing data.

[data analysis]

After backing up all the data, shut down Isilon normally in the web management interface of Isilon. Then label all the hard drives on all nodes, remove them in turn and put them into the data recovery platform provided by North Asia, and begin to analyze the data in all the hard drives.

At this point, a brief introduction to the storage structure of Isilon, Isilon internal use of the distributed file system OneFS. In an Isilon storage cluster, each node is a single OneFS file system, so Isilon supports scale-out without affecting the data in use. When the storage cluster works, all nodes provide the same function, and there is no distinction between active and standby nodes. When users store files in the storage cluster, the OneFS layer will divide the files into 128K fragments and store them in different nodes, while in the node layer, 128K fragments will be divided into 8K fragments to different hard drives of the node. On the other hand, the Indoe information, directory items and data MAP of the user file are stored in all nodes, which ensures that users can access all the data no matter from which node. Isilon allows users to choose the appropriate storage redundancy mode during initialization, and different redundancy modes provide different levels of data security (the default 3 nodes are in Nation2V1 mode).

Since the customer data has been deleted, there is no need to think too much about the redundancy level of the storage. The key point is to analyze whether the file Indoe and data MAP have changed after the file is deleted. After communicating with the customer, the deleted virtual disk files are 64g or above, and there are no other types of large files in the storage. Write a program to scan the Indoe of all files, and scan out the Indoe that meets the size of 64G or more. After a careful analysis of the scanned Indoe, it is found that the location of the data MAP recorded in the Indoe, the content that the index points to is no longer normal data, and the Indoe on all nodes is the same. After a careful analysis of the Inode, it is found that the data MAP of a large file will have multiple layers (tree structure), and the unique ID of the file will be recorded in the data MAP, so you can try to find the lowest data MAP of the file. Traversing and tracking the data MAP at the bottom of the file with a sense of luck, I found that the data MAP at the lowest level was still there.

[data recovery analysis steps]

1. Write a program to extract the unique ID of the file from the Inode of the file, and then aggregate all the data MAP that conforms to the ID. And sort according to the VCN number in the data MAP, it is found that the first 17088 items of data in each file MAP does not exist, which means that the first 17088 items of data in each file is really impossible to recover (the mood falls into a trough).

2. After careful conversion, it is found that the missing data MAP item contains less than 1G of data in total, while the deleted files are all virtual machine vmdk files, which are all NTFS file systems, while the MFT of the NTFS file system is basically in the 3G location, that is, you only need to manually forge a MBR and DBR in the header of each vmdk file to explain the data in vmdk (I don't know what a coincidence! It's a coincidence! ). Hurry up to write code, explain the scanned data MAP, and export the data according to the order of VCN numbers, leaving it zero without MAP.

3, after continuous testing, the program is finally ready, first export a vmdk file to have a look. To my surprise, the exported vmdk file was smaller than it actually was, and the location of the MFT in the vmdk did not match my own description. Is it the procedure? Or is the data MAP itself corrupted? It is manually randomly verified that several MPA findings can point to the data area, and there is no problem with the way the program interprets MAP. Just when I was puzzled, it occurred to me that there could be no sparse files in such high-end storage as Isilon. Otherwise, how much space will be wasted! Immediately according to the data MAP verification, found that the file is indeed sparse.

4. Modify the code and re-export the previous vmdk. This time the vmdk size is in line with the actual size, and the location of the MFT is also in the corresponding location. Manually forge a MBR, partition table and DBR, and then use the file system interpretation tool developed by North Asia to successfully interpret its file system and export the database and video files in vmdk.

5. After verifying that there is no problem with the database and video files in this vmdk, export all the important vmdk files in batch, and then manually modify each vmdk file one by one.

After reading the above, do you have any further understanding of how the EMC Isilon data is recovered? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

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.