accindentially wiped external hard drive

Asked by aaronvdc on 2013-12-28

hello!

I accidentially burned a img to my external hard drive.
Now my hard drive has two partitions: one for the img I burned, en the other partition is unrecognizable.
I lost all my data om the external HD, do you have a solution for that?

Thanx

Question information

Language:
English Edit question
Status:
Solved
For:
Image Writer Edit question
Assignee:
No assignee Edit question
Solved by:
aaronvdc
Solved:
2013-12-30
Last query:
2013-12-30
Last reply:
2013-12-28
rpkrawczyk (rpkrawczyk) said : #1

Bad news here, if you really overwrote the sectors on the disk then they are gone. You could try a tool like "testdisk" or "skalpel" and see if it can recover anything. This may be possible if you do not overwrote everything.

I recovered everything with a recovery program. thanx for your help

I recovered everything with a recovery program. thanx for your help

Same bad news: I also wrote a 200MB partition image (intended for an SD) over (the wrong) 1TB external USB drive. Approx 300GB of the target drive device had data. The free version of "WinZip System Utilities Suite" was able to identify and report the size and character of the original partition as 1TB. After scanning for a day, it reported that it had identified approx 2,500,000 files. It also required $40 to actually recover the files. I had no confidence that number of files was actually the image of files in their originally-linked and directory-structured configuration. I therefore aborted the process, feeling that WinZip had become ransom-ware. I then scanned with the Recuva software, which was unable to identify the underlying partition, and claimed to have identified only the 5 files contained in the small new image. I also noticed a disturbing new "recycle" entry in that directory after the Recuva scan. There are other "Questions" from others who have also made the same mistake as I made.

The "make a copy/Read" option would work to avoid this (probably common) user error IF this software automatically (if it is 'small') or after a prompt (see following) saved (to RAM, or in the program directory) an image of the data on the destination media before a "Write." Recognizing the enormity of this potential issue, ALL users would be grateful to see what the OS believes is the size of the target partition/drive. If the size of the image to be copied was also presented, any feedback would raise flags in the mind of the user. Users of this program probably have to run it repeatedly to acquire the desired result, because experimentation and adjusting procedures can be expected. Because of the difficulty in predicting how long or how many times the process is repeated (including repetition after subsequent efforts fail,) the "accident" of writing over the unintended device becomes more likely at 5am after working on it for 12 hours. "The next attempt will work" (after the 50th attempt) grossly amplifies the probability of disaster. Another way to reduce these mistakes would be to order the dropdown in the reverse order, or simply select the "last" (highest) device in the destination list dropdown. As it is, the "default" device is the 1st encountered, which is most likely to be a semi-permanent USB drive. From the notes, it appears the this program is used most often for devices that have been mounted last.

I will try the above referenced programs, "testdisk" and "skalpel" mentioned above to see if they recognize the big partition.
 As a guess, the very big USB drives most likely to be overwritten by accident are probably backup disks, as in my case. Although I had archived information from 20 years of rarely-used disks, other than using it for storing large video and sound media, the potentially-lost data, in my specific "typical" case, could be found elsewhere. My potential loss is primarily in the days of labor required to organize the "backup" which obviously would become the primary source for that data in the last 3 short months of use.

I hope that this summary is helpful when considering the UI design (re: device dropdown selection) and functionality (pre-write options) that might be incorporated in future versions. Thank you for writing and maintaining this unusual and concise tool. There are several other previous blog entries that also refer to these issues. Human "errors" have not yet been redefined to be called "exceptions," so these exceptions precipitate considerable angst, self-reproachment and embarrassment, which surely skews your feedback :-) :-(

I believe that "Skalpel," mentioned above, is probably a reference to "Scalpel," which is a tool for Unix/Ubuntu systems.
Here is a link to a list of potentially-helpful tools:
http://www.forensicswiki.org/wiki/Tools:Data_Recovery

Tobin Davis (gruemaster) said : #6

I agree with some of these suggestions (adding drive size to the dropdown, adding more info to the warning before Write operations). We are already looking into this (and a slew of other enhancements) for 1.0.

But doing a backup prior to doing a write is an exercise left to the user. This program is perfectly capable of doing that, just change the filename and do a read first (we do suggest that on our main sourceforge page). Some users use this to do mass writes (writing to multiple SD cards from 1 image in parallel), and this would just overload the system needlessly. If you had actually selected the SD and it overwrote both your SD & your 1TB USB drive, that would be a critical issue we would focus immediate attention to (like the issue I am now debugging involving a USB Floppy and wiping out the C: drive).

Having had to do recovery on all of my old 8-bit & 16-bit Atari archives not too long ago, I do feel your pain. For that reason, I keep any backup drives detached when not actually in use.

Thanks for your quick response.  I have initiated an issue in a Seagate dialog.  They are probably the biggest supplier of this type of USB portable backup drive, so I am hoping to post a general recipe for this kind of accidental overwrite.  They know what is supposed to be in that space, where the backup definition tables are, and also have their SeaTools support program.  Their FAQs didn't address this technical issue, but I imagine my solution is essentially the same as any corruption in the first "file" on their drives.  Good point on making the backup, however, it is a 1TB drive, and it didn't occur to me to first read that tiny space for the (wrong) FAT.  The obvious solution would have been to disconnect that device, but every time I wrote the image to the correct device, I was pretty sure it was the last time (hah!  If a person isn't basically optimistic, ANY technical programming or utility program usage would be overwhelming.)  Human
 errors are usually not categorical exceptions.  Self deprecation is a general and pointless result.  When computers become forgiving, I will crawl back under my rock.