Frightened for 36 hours, a production accident, dynamic disk deletion, volume partition loss, actual data recovery case

Recommended reading:

1. The source of the accident

On September 3, I performed a 50g disk expansion on the Alibaba Cloud server, and then performed an operation to expand the volume of the newly expanded 50G disk 2, and found that the E disk became 141G, which is not right. I want to expand the F disk. Then I did an operation that I regretted. I clicked the small square to delete the volume. The pop-up confirmation box instinctively clicked OK, and then it became as shown in the figure below. Disk E is gone! ! ! Disk E was originally the place framed by the frame shown in the figure below. It is a dynamic disk partition across disks. The partition table is lost. I thought this was just an ordinary accident. The data is still there when the partition table is lost. We can restore the data by restoring the partition table.

Then the facts gave us a resounding slap, let's talk about the difficulties first.

1. It is not possible to directly restore the partition table with DiskGen, because this is a dynamic disk. The data behind the 50G partition directly recovered by the tool is 0000000000, which means that the data is only half, especially our database files. The latter half are all 0000000

2. Disk 3 has been compressed and expanded several times, which caused the data recovery technician to directly ask whether your disk has been adjusted many times, and I can't restore it at all. It turns out that Disk 3 is 100G allocated to Disk F. Our operation and maintenance found that other disks are not enough. We compressed the volume on Disk F, and then allocated space to Disk D and Disk E 4 times through dynamic disks, and time It's been too long, he remembered that it was 25G for the E disk once, 1G for the E disk once, 10G for the D disk once, and 15G for the E disk once. And here he is pretty sure that I count the space of G at 1024 every time, and there will never be a decimal point. This wrong information caused us to be misled repeatedly after restoring information, including technicians who were also misled by this information and unable to restore the data. This is not shown.

Never write! ! ! ! Never write! ! ! ! Never write! ! ! !

Do not restore the partition table with confidence for dynamic disks! ! ! ! Do not restore the partition table with confidence for dynamic disks! ! ! ! Do not restore the partition table with confidence for dynamic disks! ! ! !

Two, repair ideas

Why did you mention the source of the accident, and it was said in such detail, in fact, to let the latecomer judge whether my accident is similar to my own accident and whether there is something to learn from, instead of looking for a long time and finding that it is not applicable at all Own problem.

The repair idea is actually mentioned in Reference 2. Recover according to the LDM database of the dynamic disk.

The LDM database can be viewed by using the tool winHex, but the winHex downloaded from the Internet generally does not have the LDM template. The source of this template is mentioned in Reference 1. Thank you very much to the author of Reference 1. The template is provided and the principle is also provided. .

Through the information given by the LDM database, we can know the composition of the E disk, and then use the r-studio tool to create a virtual disk for combination, and then restore a complete logical partition of the E disk, and then use this virtual disk Export the file to another disk.

Three, actual operation

3.1 Disk analysis

First use winHex to load the disk. If this is not possible, it is recommended to find a professional data repairer to operate it.

Go to the end of Disk2 and search for Hex with WinHex. The search content is actually the keyword of the LDM database, the hexadecimal code of TOCBLOCK, this can be done with the online string to hexadecimal tool.

I found it soon, indicating that there is an LDM database at the end of the disk. The disk here refers to a physical disk, not every partition. This TOC did not play a substantial role.

Next, go down a bit and you can see the data of VMDB, which didn't play a substantial role in my use.

Then go down a bit or search for 56424C4B to find this place.

I'm sorry here, I can't do the actual combat, because when the technician gave me the backup disk image, the 0000 part in the back was ignored, so I have no real data to demonstrate here. I can only use the similar pictures in the reference to explain

Note that 04 and 05 in my box are the serial number of VBLK. Starting from 4, every VBLK will have this serial number. I counted 17 disks at the time. Reference 1 explains clearly that the principle is to enable LDM Describe various situations like RAID0, RAID5, etc. See the references for details.

Then pay attention to the 34 and 35 in my box. What type of VBLK is talking about? The data in different types are also different. Then call different templates of winHex according to different types.

组件的VBLK:0x32
分区的VBLK:0x33
磁盘的VBLK:0x34
磁盘组的VBLK:0x35
卷的VBLK:0x51

For example, the VBLK whose serial number is 04 in the above figure is 34, so press ALT+F12 to open the template management, and select the 0x34 template inside.

PS: There is a small detail here. The cursor must be positioned on the first character of the first byte, which is above 5 of 56, otherwise the data of template analysis will be confused.

It looks like this

Then I used excel to record a total of 17 VBLK records, of which 3 of the disk types, as shown in the figure below, were all recorded from the template.

Then there is the volume record, which is the 51 template volume structure, which looks like this when opened with a template.

I recorded a total of 3 volumes, volume is very important, it is our drive letter E, I found him, his size is 91.0341.

For the above record, I would like to specifically say that the length is in hexadecimal. You can use a calculator, click to view, select the programmer type, then select the hexadecimal, paste it in, and then convert to decimal to get a 190912512 number, this It is the number of sectors, one sector is 512B, so for 190912512*512/1024/1024/1024, the size is 91.0341G, which is exactly the size of my previous E disk. So this method is interesting.

Next is 33 types of partition information, very important information, we use this information to partition

I found a total of 7 partition information. This number is actually in the LDM at the beginning. It just matches here. Let me talk about it. The starting position, 7C1, converted to decimal is 1985. However, based on the previous experience of looking at other disk repairs, I found The sector where 55AA is located is 2048, which is just 63 different between the two, so I tried both 1985 and 2048, and found that 2048 can actually be used to splice accurate data. The principle here is not very clear, it is the result obtained through experiment. At that time, I used the end of Partition No. 2 to go to the beginning of Partition No. 3, and found that as long as the starting position of Partition No. 3 adds 63 to their data, it can be continuous and regular. If you don't add it, it feels wrong.

With this information, plus all the information we have at the beginning, we can speculate. Our E disk should be

49.99G+24.41G+0.99G+15.62G=91.034G

And we can get the same order according to the volume offset. If you don't know the order, you can also get this conclusion according to the volume offset from small to large.

Let me add here. At the beginning, the operation and maintenance personnel stated that I was 25G+1G, which led us to mislead detours when we first tried, until I made this list, and then he found it from the Alibaba Cloud work order. A screenshot confirms this conclusion. This is the picture below. Snapped.

3.2 R-STUIDO restore data

Next, with the starting position and length of each partition, it is very simple to operate and configure R-studio.

Find Disk 2, select the creation area

Enter the starting position and size in turn, and then select the sector for the next type. The starting position is equal to the data we found in the LDM database +63. The experiment shows that the principle is not clear, and I have talked about it before.

Repeat the above steps, then click Disk 3, create regions respectively, and create all the 3 regions of 24G 1G 15G.

Then create a virtual volume set

Then add the area 0 and area 1 just added on the right side in order to ensure that the order is correct.

Then go back to the left, there should be a direct volume under virtual volume group 1, double-click it, and after a short load, you can see our directory

The catalog is out

Open a db to see

Pull to the last look, the data is there, everything is just like a dream. My data was recovered through my own ability.

After simply opening a txt file, it is found that the position of the line is not misaligned at all, indicating that the partition we spliced ​​is correct. Before this, we have tried r-studio many times. Every time we open this conf file, there are some log logs. The reason is that we were misled by the positive number of 25G. The file record on the disk says that this file is in The 15W position of the disk offset actually found the contents of a log file. As long as we can accurately restore the start and size of the partition, we can re-splice the data back. This is why you must never do a write operation, because the write operation will damage the data in the original location, resulting in slightly different data restored. Don't rebuild the partition table either, because the original LDM database may be rewritten, so we can't restore the sector location corresponding to each partition.

Four, thanks

Finally, I would like to thank my colleagues who have been with me in these two days. They worked overtime with me until 12 o'clock, analyzed possible causes with me, helped me find various articles, listened to me constantly asking various questions, and analyzed various principles with me. From the beginning, I looked at Reference 2 like a heavenly book, and now I am a master of winHex operation.

I also want to thank the technicians of DiskGen. I found him after reading the advertisement on the tool. From the beginning, he helped me restore the data. If it succeeded, I would give the money. Others would give me the money before working. After the first attempt failed, I kept looking for him again. Later, I paid a 1,000 deposit first, and he helped me out for another afternoon, but he didn’t succeed. He helped me out the next morning, although he still didn’t succeed. Shou Shou Cheng retired 700 to me. And I downloaded the mirror image of the disk and prepared for fragmentation analysis.

I would also like to thank Reference 1 and Reference 2, which helped me a lot. In particular, the VBLK template provided in Reference 1 is really not found on the entire network. It is also found on the forum. You can register for a fee before you can enter.

The main purpose of writing this article is to let everyone know that data recovery is no longer mysterious, and you can succeed on your own by carefully studying the principles. Then give some help to latecomers.

At the end of the day, don't ask me to recover the data, I am also in a panic.

Guess you like

Origin blog.csdn.net/weixin_45784983/article/details/108490375