0

Disclaimer: I'm not very good at writing questions, and mine is a very specific scenario. So I'm just going to jump straight into the situation:

I was browsing my filesystem, and somehow managed to download the a tarfile containing two critical nodes (tarfile::todo/main and tarfile::todo/code) from my local FS, and write it to the same file. Once I realized what the downloader was doing, I quickly stopped it and checked the tarfile to find, to my dismay, that only a small chunk was left, and the rest was truncated off. I don't know why it didn't back up the existing file before writing something else to it, or why session.tar wasn't commmitted my git repo, but now the whole thing's gone. I'm a very careful user, but when I fuck up, it's absolutely catastrophic.

After extundelete failed to recover the file, I browsed around here to find this, which gives a method combining grep and dd to find and read the data directly from the hard drive.

More context:

  • My /home/user directory is mounted on a separate drive: /dev/sdb3
  • Today is day two trying to recover the files.
  • The output in the next paragraph was generated today.

Once I did the grep/dd combo, I got this output. How in the world do I use this to get my files back? I tried copying it into a .file.swp and recovering with vim -r in the hopes that it was a vim swapfile, but it isn't. I have never seen this format before, so I have no idea what any of it means.

I would really like to get this data back. As I said before, it's critical. It's the veritable basket that has all of my eggs. Losing it would be a painful blow to productivity and organization.

Braden Best
  • 2,213
  • If the file was overwritten, I was venture to say the possibilities of getting back are pretty dim, I am afraid. – Rui F Ribeiro Nov 19 '15 at 17:26
  • @RuiFRibeiro using the grep+dd method, I managed to get back a significant chunk of todo/code, i was hoping the same was possible for the other one. – Braden Best Nov 19 '15 at 17:29
  • @RuiFRibeiro Plus, I guess "overwritten" isn't quite the right word here. It overwrote a small chunk in the file elsewhere and cut everything else off. Kind of like reallocating an array. The data likely still exists, and is floating around somewhere. But the anchor to it is lost. – Braden Best Nov 19 '15 at 17:35
  • I am no stranger to finding thing in hard disks. A misture of patience, art and luck really. Good you managed to recover part of your hard work. – Rui F Ribeiro Nov 19 '15 at 17:38
  • Word. I wrote a script after giving grep a good hour or so to scan my drive, and then copied all of the inodes it gave me into the aforementioned script to generate 1MB-sized files named as "todo-main-[n]", and I actually managed to get something readable back in todo-main-14. Of course, it's intermingled with random binary garbage. And I also don't remember how long the file was in the first place, so I don't think I'm getting the whole file back, even with 30-something nodes copied. I'm keeping this question open in case someone does know how to utilize the column data ("this output") – Braden Best Nov 19 '15 at 17:49

1 Answers1

0

Well, I think I've pretty much found the solution. To begin, I'll start with the link I posted in the question.

From Mark Plotnick.

First run:

sudo grep -a -b "[text from deleted file]" /dev/[drive where it was stored]

Which will generate quite a bit of output. Such as:

13813610612: a bunch of text

You'll take the number and use it with dd to read directly from your hard drive, going around the filesystem.

sudo dd if=/dev/[same drive from before] \
        of=./salvaged \
        count=2000 \
        skip=$(expr [number] / 512)

So I wrote a script to use that technique and generated about a hundred 1MB files matching "tarfile".

I think my unorthodox decision to hold it all in a regular .tar file saved me, because I found the same data in multiple places on my hard drive. I found everything that I needed back several times over.

Now I just have to sort through over a gigabyte of random text/binary garbage. Ugh. That's a lot of work.

Braden Best
  • 2,213