Recovering external drive

dbickin · 2017-10-16 15:08:17

Okay, made a STUPID mistake! I didn't double check the the correct sdX letter when writing an iso file to a pen drive. So instead of writing to the pen drive, it overwrote the beginning of my 500GB external drive. (The pen drive would usually be /dev/sdf, but if the external drive is turned on, it takes /dev/sdf. I forgot that the external drive was on....)

So, obviously the first 4GB of the drive is overwritten, but what is the likelihood that I can recover any of the remaining 486GB of data?

The drive had one partition, which I believe was formatted with ext3. The drive was mostly full of media files: avi/mp3/mp4/mkv.

From a similar blunder a decade earlier, with the front of the drive gone, what I had been able to "recover" so so corrupted, it wasn't worth the effort.

But I understand recovery software has gotten better.

Does anyone have any real world experience recovery? What software did you use?
Was it "worth the effort?"

Thanks for any help you can give.

David

nobody · 2017-10-16 16:01:47

Step 0) If you can afford it, clone the full corrupted disk using dd or ddrescue to a single file on another file system. testdisk manipulates on disk data/may be destructive. This will always allow you to consult a professional data recovery company if the data is valuable enough, using the backup.

Step 1) testdisk. It'll scan the hard disk and attempt to restore deleted partitions. Most major Linux file system copy their superblock several times, reasonably spaced across the file system, and testdisk will try to find superblocks and restore partition as well as file system boundaries. The actual files in the overwritten parts of the file system may still be lost, but chances are good that all untouched data can be recovered, esp. in a 500G file system where some superblock copies are located far from the beginning.

Step 2) photorec. If (1) didn't work, use photorec. This is more of an gamble. It'll scan the data on disk and use file magic numbers and patterns for recovering single files. File names will be lost, and this makes sense only when there are not too many larger files. File integrity may be lost if the tool can't determine the file boundary reliably. Works best for common data and container formats.

--

Personally, I had very good experience with (1) and used (2) only for fun/experimentation.

martix · 2017-10-16 20:51:15

Same thing happened to me, got everything back but that was an ntfs drive. I'd mention three Windows tools: DMDE, Active file recovery and Getdataback. I cannot tell though which one works best with ext3 (if any). As nobody mentioned, clone the disk first.

Bearded_Blunder · 2017-10-16 21:25:14

Testdisk and Photorec are my go-to solutions even in Windows, if there's any way you can (even if you have to purchase another disk) then cloning the damaged disk is always step 1, if you have enough space or the disk damage was physical (not the case here, but speaking in general) , work on a copy of the clone, this case you damage the clone, you can clone again. For a drive making funny noises, power it off and think about lab recovery as step one, only attempt DIY if risking making things worse or unrecoverable is acceptable versus the cost.

Depending on the value of the data Seagate do a fixed price deal for lab recovery which is expensive but not outrageous, looked into it recently for a physically damaged drive. My sister decided her not-backed-up pet pictures weren't worth that much.

I've sometimes thought about renaming the dd binary to data-destroyer as a little reminder the way I've been known to rename FDISK way back on MS-DOS machines, replacing it with a little script reminding me to be careful (and what I renamed it to).

hhh · 2017-10-16 21:33:33

On a personal note, I and many others of us here have made this mistake. Use it as a lesson that you should double-check and then check again before running that command, as well as everything else you do with root privileges.

dbickin · 2017-10-16 22:21:19

nobody wrote:

Step 0) If you can afford it, clone the full corrupted disk using dd or ddrescue to a single file on another file system. testdisk manipulates on disk data/may be destructive. This will always allow you to consult a professional data recovery company if the data is valuable enough, using the backup.
Step 1) testdisk. It'll scan the hard disk and attempt to restore deleted partitions. Most major Linux file system copy their superblock several times, reasonably spaced across the file system, and testdisk will try to find superblocks and restore partition as well as file system boundaries. The actual files in the overwritten parts of the file system may still be lost, but chances are good that all untouched data can be recovered, esp. in a 500G file system where some superblock copies are located far from the beginning.
Step 2) photorec. If (1) didn't work, use photorec. This is more of an gamble. It'll scan the data on disk and use file magic numbers and patterns for recovering single files. File names will be lost, and this makes sense only when there are not too many larger files. File integrity may be lost if the tool can't determine the file boundary reliably. Works best for common data and container formats.
--
Personally, I had very good experience with (1) and used (2) only for fun/experimentation.

Thanks. Last time I had used an ancient version of photorec and it didn't do much at all. I understood it got better. I'm glad to read I may not have lost everything.

Now, next question!

I need to buy another drive to hold a copy of the damaged disk. Looking at what is out there, I see most are USB 3.0, with Seagate saying they are USB 3.0/USB 2.0.

I'm pretty sure I have USB 2.0 ports.

Using lspci, I see references to USB and USB2, the latter I am thinking is USB 2.0.

Is that correct? And does it matter? Will a USB 3.0 drive work on USB 2.0, only perhaps slower?

David

Bearded_Blunder · 2017-10-16 22:38:45

A USB 3 drive will just act like a USB 2 drive in a USB 2 port, it'll happily *work* in a USB 1.1 port, just painfully slow.. as learned plugging one in my old Pentium 2 box.

If you're using a real PC (tower) rather than a laptop, I'd recommend connecting internally via SATA if possible even temporarily, moving that much data across a USB2 bus is slow. If that's an option, look into buying your drive and enclosure separately to assemble later. Warranty on bare drives is often longer than on external ones marketed as such, even though they have the same model actual HDD inside.

Last edited by Bearded_Blunder (2017-10-16 22:47:35)

martix · 2017-10-31 23:14:33

dbickin wrote:

Thanks. Last time I had used an ancient version of photorec and it didn't do much at all. I understood it got better. I'm glad to read I may not have lost everything.

Did it help in the end?

With a feedback such threads are more useful.

dbickin · 2017-11-01 03:46:04

Haven't taken the time to buy a drive to hold a backup image, so no progress on a solution yet.

Will report back if I am successful in the end.

David

martix · 2018-03-10 23:12:09

Still working on it?

Eon · 2018-04-22 06:45:41

I once did this mistake myself, wrongly formatted my 1TB external HDD, but I had a Windows system working on my other laptop, so I used Recuva software to recover most of my lost files/documents/medias real quick. Not sure if Recuva can read ext3/ext4 though.

Kino · 2018-04-24 10:40:59

I'm not sure if this will help in the future but I came across this some time ago:

Before you can fully understand how to restore the MBR, you should have a good idea of what it actually is. The MBR comprises the first 512 bytes of a hard drive. Now that's bytes, not megabytes or even kilobytes. In our terabyte age, it's hard to appreciate how very small that is, but to give you an idea, at this point in the column, I've already written about three MBRs worth of text.
This 512-byte space then is split up into two smaller sections. The first 446 bytes of the MBR contain the boot code—code like the first stage of GRUB that allows you to load an operating system. The final 66 bytes contain a 64-byte partition table and a 2-byte signature at the very end. That partition table is full of information about the primary and extended partitions on a disk, such as at which cylinder they start, at which cylinder they end, what type of partition they are and other useful data you typically don't think much about after a disk is set up—at least, until it's gone.
The following command backs up the MBR on the /dev/sda disk to a file named mbr_backup:

$ sudo dd if=/dev/sda of=mbr_backup bs=512 count=1

Basically, this tells dd to read from /dev/sda 512 bytes at a time and output the result into mbr_backup, but to do only one 512-byte read. Now you can copy mbr_backup to another system or restore it to the original one.
Simply swap the input and output sources:

$ sudo dd if=mbr_backup of=/dev/sda bs=512 count=1

Last edited by Kino (2018-04-24 10:42:12)

Head_on_a_Stick · 2018-04-24 18:03:03

Kino wrote:

$ sudo dd if=mbr_backup of=/dev/sda bs=512 count=1

Save yourself some typing:

sudo dd if=mbr_backup of=/dev/sda

^ Note though that method will *not* work if the disk has a GUID partition table (as has been the case for all new machines for many years).

#1 2017-10-16 15:08:17

Recovering external drive

#2 2017-10-16 16:01:47

Re: Recovering external drive

#3 2017-10-16 20:51:15

Re: Recovering external drive

#4 2017-10-16 21:25:14

Re: Recovering external drive

#5 2017-10-16 21:33:33

Re: Recovering external drive

#6 2017-10-16 22:21:19

Re: Recovering external drive

#7 2017-10-16 22:38:45

Re: Recovering external drive

#8 2017-10-31 23:14:33

Re: Recovering external drive

#9 2017-11-01 03:46:04

Re: Recovering external drive

#10 2018-03-10 23:12:09

Re: Recovering external drive

#11 2018-04-22 06:45:41

Re: Recovering external drive

#12 2018-04-24 10:40:59

Re: Recovering external drive

#13 2018-04-24 18:03:03

Re: Recovering external drive

Board footer