DD'ed an image to the wrong disk over ExFAT filesystem

[PacketFiend]

Hello, I'm hoping to get some technical guidance.

The other day I accidentally pointed DD (yeah, I know...) at an external 6TB storage array, with

Code: Select all

dd if=memtest86.img of=/dev/sdi conv=sync

It should have been /dev/sdj. Upon realizing the error, I aborted the overwrite. The memtest86.img image is approximatey 1GB in size, and I believe I stopped the process about halfway through, although I'm not certain. I believe it was a GPT partition scheme. The disk had a single 6TB partition, formatted as ExFAT. The drive itself was a mirrored RAID-1 array.

I've since removed both drives and am only operating on one of them, as I lack the storage capacity to create images of it. My plan is to copy back over from the hard drive I don't operate on to the one I do operate on if any of my attempts further damage the filesystem/partition scheme.

I'm wondering what my options are, and what the best way to go about recovering this would be. After an initial scan with TestDisk (so I'd have a log to post here, once I can post attachments) that didn't help, I'm running photorec to carve out anything it can find, and it's finding quite a bit, albeit with no filename or directory structure information

It's my understanding that there should be a backup copy of the partition scheme at the end of this 6TB disk, correct? Would it help at all to attempt to rebuild the damaged partition tables, and then try "undeleting" what I can find by some other means? I know ext filesystems store several backup copies of the superblock around the disk, but I'm not sure if ExFAT has anything like this, so I don't know how successful any attempts at using what's left of the filesystem will be.

The disk is about 55% full and I don't expect much fragmentation, in case that makes any difference.

Photorec got me out of a really tight spot, oh, about ten years ago, it was a lifesaver. With some luck and persistence, maybe I can recover most of what I just destroyed.

[PacketFiend]

Apologies, I forgot to attach the log - but I now realize I can't post attachments or edit the original post.

[recuperation]

Hello, I'm hoping to get some technical guidance.

The other day I accidentally pointed DD (yeah, I know...) at an external 6TB storage array, with

Code: Select all

dd if=memtest86.img of=/dev/sdi conv=sync

It should have been /dev/sdj. Upon realizing the error, I aborted the overwrite. The memtest86.img image is approximatey 1GB in size, and I believe I stopped the process about halfway through, although I'm not certain. I believe it was a GPT partition scheme. The disk had a single 6TB partition, formatted as ExFAT. The drive itself was a mirrored RAID-1 array.

I've since removed both drives and am only operating on one of them,

I hope you mean "recover" because "operating" means regular use including writing. The TestDisk home page
https://www.cgsecurity.org/
only specifies Linux raid configurations when dealing with RAID structures. You did not provide any additional information about your RAID.

as I lack the storage capacity to create images of it. My plan is to copy back over from the hard drive I don't operate on to the one I do operate on if any of my attempts further damage the filesystem/partition scheme.

I never recovered a RAID structure. I assume there will be a manufacturer-specific header on both of your disks which will serve to distinguish both disks and make sure that they belong together.

I'm wondering what my options are, and what the best way to go about recovering this would be. After an initial scan with TestDisk (so I'd have a log to post here, once I can post attachments) that didn't help,

Please post the log.

I'm running photorec to carve out anything it can find, and it's finding quite a bit, albeit with no filename or directory structure information

It's my understanding that there should be a backup copy of the partition scheme at the end of this 6TB disk, correct? Would it help at all to attempt to rebuild the damaged partition tables, and then try "undeleting" what I can find by some other means? I know ext filesystems store several backup copies of the superblock around the disk, but I'm not sure if ExFAT has anything like this, so I don't know how successful any attempts at using what's left of the filesystem will be.

"Other means" are most likely able to read out the backup GPT table (assuming GPT as partition table) as well.

The disk is about 55% full and I don't expect much fragmentation, in case that makes any difference.

The less the fragmentation the higher the recovery rate with carvers like Photorec will be.

[recuperation]

As for the options you were asking for:

As you failed with TestDisk, you might try out other (commercial) recovery software. If they fail, use PhotoRec.

[PacketFiend]

I hope you mean "recover" because "operating" means regular use including writing. The TestDisk home page https://www.cgsecurity.org/ only specifies Linux raid configurations when dealing with RAID structures. You did not provide any additional information about your RAID.

It's raid1, a simple mirrored array of two disks. When you pull them out of the array, they're identical, and can be attached and mounted as single disks if you want to. So I'm doing recovery attempts on drive A, and if any of those attempts hamper recoveries any further, I can image drive B back over to drive A and try again. For basic recovery purposes, it's not a RAID, really. The only reason I mentioned the raid is so it's communicated that although I can't create an image with ddrescue or similar, I am able to try destructive recovery operations and image from drive B, instead.

"Other means" are most likely able to read out the backup GPT table (assuming GPT as partition table) as well.

By "other means" I mean trying filesystem recovery if I can restore the partition table. With any luck there's at least bits and pieces of the MFT or whatever ExFAT calls it scattered around the disk. A bit of reading tells me that there might be a backup copy of the MFT but it would be directly after the first, at the beginning of the disk. What I don't know is whether or not Testdisk will be successful at all, on an ExFAT filesystem with a corrupted MFT.

I'm thinking Testdisk might have been unsuccessful becuase there is in fact a valid 1GB disk image at the beginning of the 6TB drive, so it stops looking when it sees that. I didn't yet do a deep search, but a quick search didn't find the original partition table. A deep search will be my next step. If that is unsuccessful, would perhaps overwriting the 1GB memtest image sitting at the beginning of the drive with random data or zeros help Testdisk find the backup GPT?

(testdisk.log attached)

[recuperation]

I hope you mean "recover" because "operating" means regular use including writing. The TestDisk home page https://www.cgsecurity.org/ only specifies Linux raid configurations when dealing with RAID structures. You did not provide any additional information about your RAID.

It's raid1, a simple mirrored array of two disks.

If that is the case meaning that your disks do not contain any additional RAID information recovery will be simplified.

When you pull them out of the array, they're identical, and can be attached and mounted as single disks if you want to. So I'm doing recovery attempts on drive A, and if any of those attempts hamper recoveries any further, I can image drive B back over to drive A and try again. For basic recovery purposes, it's not a RAID, really. The only reason I mentioned the raid is so it's communicated that although I can't create an image with ddrescue or similar, I am able to try destructive recovery operations and image from drive B, instead.

"Other means" are most likely able to read out the backup GPT table (assuming GPT as partition table) as well.

By "other means" I mean trying filesystem recovery if I can restore the partition table. With any luck there's at least bits and pieces of the MFT or whatever ExFAT calls it scattered around the disk. A bit of reading tells me that there might be a backup copy of the MFT but it would be directly after the first, at the beginning of the disk. What I don't know is whether or not Testdisk will be successful at all, on an ExFAT filesystem with a corrupted MFT.

MFT is a structure in NTFS and is not part of EXFAT. EXFAT ressembles the FAT type file systems. There is no backup of the MFT in NTFS. There is something called MFT mirror which only contains four entries of the MFT. But again this only applies to NTFS. There is no quick fix for any partly overwritten file system as crucial meta data is typically located at the beginning of the partition. The remains of your EXFAT file system may indeed contain scattered information but TestDisk does not provide this kind of analysis. Doing so would require individual program code for each type of file system. That is why I am always referring to using other (commercial) software if TestDisk does not succeed. If other software fails, PhotoRec will be the last line of defense.

I'm thinking Testdisk might have been unsuccessful becuase there is in fact a valid 1GB disk image at the beginning of the 6TB drive, so it stops looking when it sees that. I didn't yet do a deep search, but a quick search didn't find the original partition table. A deep search will be my next step. If that is unsuccessful, would perhaps overwriting the 1GB memtest image sitting at the beginning of the drive with random data or zeros help Testdisk find the backup GPT?

I don't know unfortunately but I doubt that. If you do that let the forum know!

(testdisk.log attached)

You should run the currently most recent TestDisk version 7.2 instead of the outdated version 7.1 which is four years old:
https://www.cgsecurity.org/wiki/TestDisk_Download

[PacketFiend]

Well after several attempts, I can't manage to rebuild the partition table. Testdisk found a few dozen "partitions" actually, because there's disk images on the failed HD. But alas, none of them were the one I was looking for. Zeroing out the beginning of the disk and hoping Testdisk would default to the backup GPT at the end didn't work either. It's possible that it was an Intel partition scheme, but after a few days of trying both, I don't think I'll recover much more this way.

Photorec did a good job though. I'm still going through everything it recovered, but between a year old backup and what Photorec was able to dig up, I'm in a much better spot than I thought I'd be.

Thanks again for writing and maintaining this software, this is the second time I've needed it

[recuperation]

Thank you for the feedback!