How to Rebuild Partition Table?

  • Thread starter Thread starter layoric
  • Start date Start date
Status
Not open for further replies.
L

layoric

Guest
I'm having issues with a data recovery job. I was able to image the drive, which doesn't have any mechanical issues, but does have the partition table missing. Ran the image through a rstudio, but it finds no directories, and all filenames are corrupted with incorrect file sizes as well. This is an external WD 1TB drive, removed from enclosure for direct access. The drive was connected to a Windows 8 computer, most likely just a single partition backup drive.
Testdisk finds no partitions. Chkdsk found no issues with the drive itself (no drive letter, used direct volume access to run). The drive was tipped when running which resulted in these issues. There's about 250 GB of data on there that customer would like recovered. Data recovery pgm only found a few jpg's, but there should be thousands. ddrescue only had about 5mb in error size for the image.

Is there a way to rebuild the partition table to bring back all file names if testdisk cannot find anything?
 
How was the drive partitioned originally? Also some usb2sata bridges do things like encryption and compression. In rstudio did you look at the recovery by file type. The names will be bad the the files themselves might be good.
 
The drive came ready to go. Yes, recovery by filetype has corrupt/incorrect information and filesizes. Nothing is viewable. No encryption/compression with this unit occurred.
 
Also just ran data lifeguard tool and the quick test reports to drive as passing/good, which reiterates my statement that there are no mechanical issues with the drive.
 
I think Mark is onto something here. Most recent WD external drives come with hardware encryption out of the box.
To confirm, check out the model at WD and try a different drive in the enclosure to see if it works.
 
If it's a MyBook or MyPassport other than an Elements model, it will be encrypted. The drive needs to be checked for head/media/firmware damage, and have that/those problems repaired, then cloned to a drive compatible with the USB PCB. The clone then needs to have the USB PCB mounted in order to access the data--or the clone can be decrypted on a PC3000. If the data has any value, it's time to ship it off to a DR firm.

Edit: Oops! Luke snuck in there while I was typing!
 
I wasn't aware of the encryption by default, just assumed it wasn't since customer wouldn't have known to do it expressly. I'm testing it with that board now, and will report back. Thanks for the heads up on this!
 
Connected drive back to mybook board. Attempted testdisk, and it DID find a partition, wow, neat - OK... Next rebooted, still in linux, tried to mount/view files directly - got message stating should run fdisk /f in Windows... One step forward, 2 steps back I guess.
Attempted to run command, was only able to run via direct access command prompt, specifying device directly (no disk letter yet). Couldn't lock it, so said would do it on reboot, just like OS drive messages. So.... rebooted, was taking forever due to drive problems with Windows still stupidly trying to read it. Left and came back, Windows was booted again. Don't know if it ever did anything, but now there's a drive letter, that does take some time to come up. Nothing listed on drive, format messages, etc. Ignored all that, tried to run fdisk again on drive letter directly but it wouldn't take, just froze the command line even bringing up elevated command prompt. Attempted windows repair disk boot, with option to load drivers for WD device, windows never found device after driver load.

For now, went back to ddrescue and making another image on to another ext. usb disk, so now imaging wd via it's usb board to another usb drive. Getting much slower throughput for this connection than with drive connected directly to sata, but apparantly, the image was hosed anyway due to encryption from the board. I'm just going to let this run for now, it'll be done in a few days :(

Wish I could just completely repair the tables as this is going to take some time -
 
You should not have done any of that stuff with fdisk. Once back on the usb2sata bridge you should have immediately imaged it then work off the image. On the first image you mentioned above, was that done when the drive was on the bridge or using the native sata?
 
I'm going to attempt to say this with some tact, so please consider that when I say: OMG what are you doing!?
Your really putting a huge amount of unneeded stress on that failed drive as well as probably causing irreversible changes by using chkdsk.

You say you used fdisk? On what version of Windows, XP or Vista? Because W7 doesn't even come with fdisk... as it only works with FAT/FAT32 filesystems.

You say that the drive is physically OK, yet, it's going to take days to transfer 1TB? Something doesn't seem right here.

The first thing I would have done is pulled the drive from the controller and ddrescue cloned to a server/computer.. then pop the physical clone back on the USB controller and see if it picks it up, as has been suggested a few times. You have some solid feedback here from the others that would, if possible, be your best and only bet with the limited equipment you have.

It is very possible the drive was recoverable but I fear that you will not be able to realize that now due to the operations you have performed already. A nail in the coffin, as they say. My 2 cents.
 
but apparantly, the image was hosed anyway due to encryption from the board. I'm just going to let this run for now, it'll be done in a few days
Keep the original ddrescue image. Restoring it to a drive compatible with the USB board may let you get your decrypted data back. Frankly, if the data has any value, I'd suggest providing the original drive plus the image/cone to a DR specialist for them to do the recovery. There is no way for you to transfer the clone's adaptives to the USB ROM without special equipment.
 
Thanks to this thread I have learnt a fair bit. 1. Use ddrescue for imaging bad drives. 2. Buy R-Studio, learn how to use it and use it to recover data after creating an image.
Am I missing anything else?
 
I'm going to attempt to say this with some tact, so please consider that when I say: OMG what are you doing!?
Your really putting a huge amount of unneeded stress on that failed drive as well as probably causing irreversible changes by using chkdsk.

You say you used fdisk? On what version of Windows, XP or Vista? Because W7 doesn't even come with fdisk... as it only works with FAT/FAT32 filesystems.

You say that the drive is physically OK, yet, it's going to take days to transfer 1TB? Something doesn't seem right here.

The first thing I would have done is pulled the drive from the controller and ddrescue cloned to a server/computer.. then pop the physical clone back on the USB controller and see if it picks it up, as has been suggested a few times. You have some solid feedback here from the others that would, if possible, be your best and only bet with the limited equipment you have.

It is very possible the drive was recoverable but I fear that you will not be able to realize that now due to the operations you have performed already. A nail in the coffin, as they say. My 2 cents.
Actually chdsk, not fdisk, android auto correct... should have been apparent with the/f switch.
limited equipment I have? Really? How do you know what I have? I don't ever post everything I've done, this is only one other route I've taken on this project, so try not to assume such things.
As ddrescue doesn't display time left, I can only use a formula for figuring it out manually. This is common knowledge with ddrescue.

I'm not going to answer to the other points you made as they are accusatory and I have no desire to go any further down that route, and frankly I'm getting annoyed. . .

So thanks to everyone else for the info on the encryption as that was the main issue, for which I was unaware. WD ext drives are on my list of do not buy recommendations.
 
WD ext drives are on my list of do not buy recommendations.
Seagates are worse. I recommend WD portable drives that are not encrypted, i.e., the Elements model. If you restore your ddrescue image to a new drive of the same model and capacity, I think it will yield your unencrypted data. Haven't tried it myself, but I think it should work, so long as the two drives use the same encryption chip and have identical capacities. Someone is sure to correct me if I'm wrong. :)
 
Actually chdsk, not fdisk, android auto correct... should have been apparent with the/f switch.
limited equipment I have? Really? How do you know what I have? I don't ever post everything I've done, this is only one other route I've taken on this project, so try not to assume such things.
As ddrescue doesn't display time left, I can only use a formula for figuring it out manually. This is common knowledge with ddrescue.
There is no reason to be so defensive. OK, so you know what your doing.. great! Have at it buddy!
Of course, you should almost never use chkdsk /f for data recovery because it is sure to change the File Allocation Table which is exactly what you don't want to do. Also, sorry about the fdisk mistake on your part... of course there is an fdisk function in Linux and on older versions of Windows, so I just wanted to clarify what tool you actually used, sorry for the inquiry.

So what professional data recovery equipment have you tried on this drive? It would help us point you in the correct direction if we knew what you have tried already. ACE PC-3000, DeepSpar, Dolphin DFL-DDP? I am interested in what tool you have found to be the most successful, that's all.
 
Seagates are worse. I recommend WD portable drives that are not encrypted, i.e., the Elements model. If you restore your ddrescue image to a new drive of the same model and capacity, I think it will yield your unencrypted data. Haven't tried it myself, but I think it should work, so long as the two drives use the same encryption chip and have identical capacities. Someone is sure to correct me if I'm wrong. :)
Thanks, that would be an interesting option, but I don't have the same model as a spare right now. If I can find it for reasonable cost I'll give it a go though. Even if the results are satisfactory without it, I may just try it out afterwards, as it was much faster imaging w/o using the existing wd board.
 
Status
Not open for further replies.
Back
Top