2

I was installing Ubuntu to the internal disk in my main machine, with all external drives unplugged for safety - then discovered I had accidentally chosen the external drive and it wasn't unplugged. (Seeing three drives not two listed as installation targets should have tipped me off, but I guess my IQ was low that day.)

The external drive, in compliance with Murphy's Law, was my backup drive with all vital current files. Poof! The last few months of work gone. Now the drive shows only the stuff I normally expect in / on any Linux machine. It mounts showing as ext4, but the disk was (I'm 98.5% sure) originally ext3.

However, the installation did not finish. Whatever files got copied, clobbered only a fraction of the disk. df reports only 1% of the space used. Maybe the bulk of my valuable files are okay, and could be recovered with some tool?

There are other questions on this site about file recovery, but many are for Microsoft Windows, or for malfunctioning disks, or some other situation. I'm on Linux with a physically healthy external disk. I'm fairly sure that the more recent and more important files are in multiple copies on that disk, so if one copy is clobbered there's hope to get the second copy.

Improve this question

2 Answers 2

Reset to default
2

testdisk has saved my bacon in the same situation quite a few times - i've once rolled back an accidentally formatted disk back to its original state - though in this specific case, since both the current and original file systems are similar, dding the drive to avoid user error is not a bad idea.

Improve this answer
4
  • Testdisk looks powerful, and might do the job. Now how to figure out how to use it with no prior experience and without further risk to the clobbered data?
    – DarenW
    Commented May 10, 2011 at 14:36
  • if possible, make a copy of the drive with DD. there's a howto on how to use testdisk on their site.
    – Journeyman Geek ♦
    Commented May 10, 2011 at 15:28
  • +1 Much less hackish and a better solution for binary files than grep/perl.
    – new123456
    Commented May 11, 2011 at 0:38
  • Whew, turns out I had a copy of my bacon on a laptop that I took in for repair, and just got back. The drive I was going to try testdisk on, having very little newer stuff, is now safe to toy with. I will experiment with testdisk for educational purposes.
    – DarenW
    Commented May 11, 2011 at 1:25
0

There are specialized tools for this kind of work, but they'll cost you and you could possibly do this with grep.

Most filesystems have no reason to overwrite the disk when they are created. So, if you can unmount the partition and not use it, then you have a chance of recovering most of the files.

However, if these files are in binary, this will make it tricky. Most text files can be grep'd for by the text within them. You'll have to go about separating them by hand if you choose the grep route, or find out the magic number of the file format and use that.

Good luck, and make sure not to get eaten by a grue.

Improve this answer
2
  • How can grep search files that can't even be listed by e.g. ls? Besides, most of the files are images, spreadsheets and tarballs.
    – DarenW
    Commented May 10, 2011 at 14:34
  • @darenw You don't grep for files, you grep for data bygreping the raw HDD (something like /dev/sda) for bytes. Read the second link (the cyberciti) - it explains the process well.
    – new123456
    Commented May 10, 2011 at 20:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .