I just deleted about 100 photos from an ext3 external hard drive that I really would have preferred to keep. With shift+delete (do not pass the trash, do not collect $200). So I went looking for an answer.
If you’ve looked around the ‘net for a way to recover files from an ext3 partition, you’ve probably found lots of people saying “it can’t be done, because the inodes get wiped”. Well that’s true. There’s no way to simply mark the inodes undeleted and have your files back, BUT your actual files don’t get wiped, and if you’re lucky, you may be able to retrieve some or all of them.
First step: after you delete something accidentally, DON’T WRITE ANYTHING TO THE PARTITION. If you do, you are likely to overwrite the blocks containing your files. This means, if you deleted something accidentally from your root partition, home partition, or any other system partiton, un mount it immediately. This may mean you need to turn of your computer, remove your hard drive, and put it in another computer as a slave. I was working on an external hard drive anyway, so I didn’t really need to worry, as nothing would get written to it without me telling it to write to it…
Second, I recommend you read this: Brian Carrier’s “Why Recovering a Deleted Ext3 File Is Difficult . . .”. It’s where I got most of my information from. Most wise is the cry of “don’t forget to backup anything important”. Unfortunately, I was working on an old backup with no redundancy. ie. I was screwed.
Third, you need The Sleuth Kit, and you need Foremost, both of which are in the ubuntu repositories, and are probably available packaged for most distros. You REALLY need to read the man page for Foremost, and it would be a good idea to read the man page for dls, a sleuth kit program.
Lastly, you need some spare space somewhere. depending on the files you’re looking for, you might need a lot of space. I had an empty 40gb partition, so I used that, but in the end I only needed 180mb of space to retrieve 160mb of photos (this is probably NOT typical)
The Magic phrase:
$ dls /dev/sdb5 | foremost -T -o/media/MUSIC/parish -tjpg
Ok, an explanation:
- dls simply reads a partition, straight out. Don’t ask me how or why. In my case, I needed to read /dev/sdb5.
- The output of dls is piped to foremost, which read from stdin by default
- -T timestamps the output directory. It isn’t necessary, but if the directory you’re outputting to is not empty, foremost won’t write to it.
- -o<dir> is your output directory. In my case, a folder in my spare partition.
- -t<filetype> is where I specified foremost should look for jpegs. Foremost actually looks for signatures such as the first few bytes of a file, to see if it matches a certain pattern. There are a set number of filetypes included by default (Read the MAN page), or you can create your own.
So that’s it. I ended up getting all 108 photos back, minus filenames, but that’s fine, because I usually just rename my files with the EXIF date/time data anyway.
Because dls only looks at unallocated block be default, the process ignored about 8000 other jpgs on the 95gb drive, and only recovered ones that had been deleted. Very handy for me. I left it go over night, but at a guess, I think it probably only took about 3 hours max (the hard drive is very full, so it probably only ran over about 5gb total).
so… it works, but it doesn’t join the blocks back together correctly, so I have my ~100 photos (jpeg files), but each of them is damaged about 10% into the actual image. I can still read the thumbnails, but not the whole image. If anyone has a good suggestion for how to fix this, please let me know.