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

Today, I would like to introduce a successful case of Linux server data recovery. the payment for this server data recovery physical server is as follows: the customer failure server is an X3850 server, which is a RAID5 composed of 4 146g SAS hard drives as storage medium, and the file systems are all reiserfs. We first analyzed and found that the previous hard disk data organization structure was composed of a less than 100m boot partition, followed by a 271g LVM volume, followed by a 2G swap partition. A reiserfs file system is directly divided into the LVM volume as the root partition.

During the normal use of the server, the system is paralyzed due to unknown reasons, so there is an urgent need for server data recovery. After the reinstallation of the system, it is found that the whole RAID logical volume has become the boot and swap partition of the previous 2G, followed by the 271g LVM volume, and there is an empty reiserfs super block in the file system location of the LVM volume.

The data we want to recover this time is all the user data in the original 271g file system, which includes the database, website programs and web pages, and all the office documents in the unit OA system.

The server data recovery engineer first determined the original reiserfs partition location through the association between the whole reiserfs tree nodes, and found that the first 2G data of the file system where the original data was stored had been overwritten, and the user should have initialized the partition structure wrongly when installing the system, so the installed system could not import the LVM volume and tried to repair it with reiserfsck.

Because the reiserfs file system linearizes all the files (including directories) in the file system, and then generates a B + tree with file key, the increasing number of nodes in the tree will cause the structure of the tree to stretch and migrate smoothly to the data area of the whole disk. As a result, the top-level node is not usually placed at the front of the file system.

Because the file KEY number of the root directory is usually the smallest, so, from a spatial point of view, the most stored in the first 2G should be the key node closest to the root start path, so that the possibility of the existence of the node is very high because of the deep level of the directory. The data covered by the first 2G can no longer be recovered, so we can only hope that the user data will not be overwritten exactly. Because the index of the whole tree in front of the file system is lost, and the tree concept of reiserfs is very abstract, it will be difficult to rebuild the tree.

The data recovery engineer scans key nodes throughout the original file system area and exports all nodes through an autonomous program. Then all the leaf nodes are reordered and filtered by the autonomous program (get rid of the nodes that were previously deleted), and the secondary, tertiary and fourth-level leaf nodes are regenerated. Select the 2G space in front of the partition as the structural area of the new tree (anyway, this part of the data is useless, the reloading system is full), and generate the corresponding address information.

To deal with the directory naming problem, if you encounter the loss of a node in the original tree path, name it with a custom key node number, and if you cannot determine its parent directory, temporarily add it to / otherfiles. According to the above face, spanning tree index information is written to a specific location, and then according to this information, super blocks are generated and the clear flag is set. Under the suse virtual machine, create a snapshot, mount the repaired volume, and you can already see the file. (note: virtual machines and snapshots can be traced back for the purpose of operation, and because metadata such as bitmap does not affect the data, no correction has been made, so you cannot do reiserfsck before mounting).

Under the suse virtual machine for repair, mount the target hard disk for copy data, and then cp all the data to the target disk after mkfs. The user collates the required data through the find command and modifies the location and name of some directory files. Part of the missing loose files, according to the size and file header flag to find, find and move and rename.

The non-intuitive nature of the tree and the debugging of the program make the whole recovery work extremely complicated. Fortunately, 100% of all the important data has been found by us.

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.