Mindstab.net

Well, because I'm a cocky moron I was working on a new project but hadn't "gotten around to putting it in a git repo" or backing it up at all and sure enough I accidentally deleted one of the files that was over 25% of the project. Severed me right I suppose. Well, I didn't want to let that go. Too much work and hassle to redo, I'd already done a lot of bug tweaking on it. So I decided to investigate file recovery on Unix. Long story short, not so great, no fancy programs to go looking for your files. However, there's always the DIU approach. So I started by grepping the harddrive (/dev/md/5) for a unique-ish string in the file and having it print out the an appropriate number of surrounding lines to get the file back.

 
grep -a -A 1000 -B 100 "import netpipe" /dev/md/5 > results.txt
 

The '-a' switch makes grep treat binary files like text files, so it'll work on devices, the '-A' switch tells grep how many lines to print After the line with the text we want is found and the '-B' switch tells grep how many line to print Before the line we want. I choose the numbers because the line I was looking for was clearly nearer the top of the file.

However this approach failed with grep giving me a ran out of memory error.

So a little more googleing and I found the solution, this little baby of a shell script

 
for ((skipamount=1 ; skipamount < 88188637184 ; ))
do
dd if=/dev/md/5 of=./testhex bs=1024 count=1024 skip=$((skipamount+=1024))
echo "Sector" $skipamount of 85899345920 echo "S" $skipamount>> ./found
echo >> ./found
grep "import netpipe" ./testhex --binary-files=text -A 1000 -B 100 >> ./found
done
date
echo "Done"
 

It's not pretty and you'll have to hand edit it to your particulars but essentially it reads over the hard drive picking out 1MB chunks piece at a time and running grep on those. The positive side of this is that it actually succeeded on running over my whole hard drive. The catches are that the found file is somewhat polluted with lines stating where it is, but this is actually handy because the other catch is that since we're pulling discreet 1MB chunks off the hard drive it's possible the file you are looking for will be arbitrarily split across them and you won't get all of it in your results file. But all the extra information in the fill will tell you exactly where to look and you can just use 'dd' to go in and get a more proper sized chunk with your whole file.

Anyways, a long story short, I found my file and was able to recover it. Hooray!

Also, a note! Crucial to deleted file recovery is to minimize writing to the drive the file was deleted on. Recovery works because the only information actually deleted are the pointers in the filesystem tree. The actually contents of the file are still on the drive, but now are as far as the file system is concerned, adrift in unused space and free to be allocated to be written over by the next program. So try to shut things down and stop writing to the partition with the lost files and run the recovery on a different partition or your recovery might overwrite your target!