Hey there,
Finally, as promised, I'm getting around to finishing this post on recovering lost data on Linux and Unix. I'm far too lazy to look through the insane drivel I posted while I had the flu, but I'm pretty sure this was supposed to go out last week. Perhaps it's all for the best ;)
This is going to be a two-parter, since it seems so incredibly convoluted to explain ;)
The method we'll be using for this walkthrough requires a few tools, plenty of disk space and a good deal of patience (most likely). The two main tools are found in The Coroner's Toolkit (TCT), which you can download for free from the preceding hyperlink. The two tools you'll need from this set of computer forensic tools are:
1. unrm: This command basically creates one gigantic file composed of all the free blocks on the partition you want to do your data recovery from (not to be confused with the partition on which you lost your data).
2. lazarus: This command takes the output of unrm and breaks it up into files (by block), which can make it simpler for you to find your lost data and restore it.
It's recommended, when using unrm, that you mount the partition from which you want to recover data, in read-only mode. If this is impossible, that's not a big deal. It's imperative that you create your unrm recovery file on a "different" partition than the one from which you will be recovering. You will also need to make sure that this separate partition has about 220% of the free space available on the partition from which you want to recover, available for use.
The breakdown on the 220% worth of disk space is pretty simple. On your recovery partition, you'll need 100% of the available free space on the partition from which you want to recover your lost data, just to copy all those free blocks over. Makes sense. Now, the other 120% is, actually, optional and dependant on whether you make use of lazarus or not. If you don't need it (you'll see if you do or don't as we move along), then you'll only need to have that 100% available on your recovery partition. If you do use lazarus, then you'll need an additional 100% for the duplicate blocks that lazarus will create from your unrm output, plus about an additional 20% for overhead (since lazarus will be tagging each block as containing data of a certain type, like audio, picture, text, etc)
From you, as noted above, we'll just need patience. You may get the desired response from this process immediately, but probably not. To prepare recovery from about 2GB of free space, expect unrm to take a minutes or so (only just slightly longer than doing a "cp"). To comb that free space with lazarus, expect to wait (assuming you sit through the entire thing), at least 6 or 7 hours. In all honesty, I left the process running overnight and found it finished when I returned. It had been running for approximately 7 hours when I left it, and "du" indicated that is wasn't even halfway done recreating the individual blocks.
So, for today, we're going to set up the situation and do things the easy way. That's right; for all the explanation above, we will only be using unrm today. Tomorrow, we'll get into lazarus, with a pointer back here to the heavy explanation of the whole process. I'm just trying to save virtual trees. ...or my sanity. ...we'll see ;)
THE SITUATION: You've created a text file, containing valuable information that you couldn't commit to memory, using your favorite text editor and saved it. Then, an hour or so later, you accidentally deleted it, realizing that you'd completely screwed up just seconds after pressing the enter key. Anybody "not" know that feeling? ;)host # cat /usr/THE_ALMOST_LOST_FILE
we'll just put some
semi-random text in
here to see if we can
find this later with
grep. For simplicity's
sake, we'll include the
word semi-unusual so that we
have something in this
file that probably won't
be in any other files
host # rm /usr/THE_ALMOST_LOST_FILE
host # cat /usr/THE_ALMOST_LOST_FILE
cat: cannot open /usr/THE_ALMOST_LOST_FILE
So, you're basically screwed (although the contents of your file would be much more compelling than those above ;)
The first thing we'll want to do is create a recovery area on a separate partition that has free space in the amount of 220% of the free space on the partition where we deleted our file (explanation above). We'll only be using 100% today (or would that be approximately 45% of the 220%?). Basically, we'll just need to have the same amount of free space on our recovery partition as exists on the partition we accidentally deleted our file on. We'll just assume that you can't unmount the old partition and mount it read-only (generally the case if you're working on a live system that other people are using ;) For this case, /usr/local looks like a good fit to recover data from /usr on.host # df -h /usr /usr/local
Filesystem size used avail capacity Mounted on
/dev/dsk/c0t0d0s3 5.0G 3.4G 1.6G 68% /usr
/dev/dsk/c0t0d0s5 49G 2.0G 47G 5% /usr/local
host # mkdir /usr/local/recovery
host # ./unrm /dev/dsk/c0t0d0s3 >/usr/local/recovery/the_found_file_I_hope
./unrm: impossible: unallocated meta block 4228499!!
.....
You'll see a ton of these "unallocated meta block" messages. Ignore them. They're perfectly harmless :)
When the unrm process is complete you will have created one gigantic file, equal (sometimes larger) to the size of the free space available on the partition where you deleted your file accidentally, with the name that you redirected unrm's output to. Let's check out that file:host # ls /usr/local/recovery/the_found_file_I_hope
/usr/local/recovery/the_found_file_I_hope
host # file /usr/local/recovery/the_found_file_I_hope
/usr/local/recovery/the_found_file_I_hope: data
host # wc -l /usr/local/recovery/the_found_file_I_hope
10481696 /usr/local/recovery/the_found_file_I_hope
host # du -sh /usr/local/recovery/the_found_file_I_hope
1.7G /usr/local/recovery/the_found_file_I_hope
host # egrep -il 'semi-unusual|later|random' /usr/local/recovery/the_found_file_I_hope
/usr/local/recovery/the_found_file_I_hope
And it appears that our file is actually in there :)
Now, since we're not going to use lazarus today, to chunk that huge file up into easy to digest blocks (one, or more, of which would be the text file we deleted), we'll need to get the info back the "old-school" way. This is where lazarus really comes in handy, because, in order for us to extract the file we want, we need to extract it "very specifically" from that huge recovery file. This is somewhat trivial with our text file (that we remember the entire contents of) but can be very tricky with binary data!
Even with text, getting it back from the one big file is going to be messy; especially at the beginning - for instance, we can't grep (using Solaris' grep, anyway) anything from the first line. I found it in line 5 of the huge file unrm created. To demonstrate what I mean, let take a look at line 5 (line 1 of our original text) and line 6 (line 2 or our original text).
Line 2 of our original file is normal looking:host # grep -n semi-random the_found_file_I_hope
6:semi-random text in
host # sed -n 6p the_found_file_I_hope
semi-random text in
But check out line 1! :host # grep -n some the_found_file_I_hope 2>&1|head -1
12:have something in this
It didn't get caught (???) Of course, grep has problems with it because the line actually looks like this in the recovery file:host # sed -n 5p the_found_file_I_hope
l¨oÿÿþp-B
8B0
BBÀÀÜ
LgØRytyt
Xyy
^yy
f}}
Co G
t££2£à£à}¥ ¥ O§p§pÄ §§oÿÿö¨Awe'll just put some
Ugly ;) Usually (mostly when you get directly on top of trying to recover your data) your deleted data will be in this gigantic block-file in sequence. If you wait too long, and you're still lucky enough to get most of it, you may find that your data is out-of-sequence. In our case, we can retrieve our file by simply printing out the lines, one by one, using a blanket "sed -n" print statement:host # sed -n 5,14p the_found_file_I_hope
l¨oÿÿþp-B
8B0
BBÀÀÜ
LgØRytyt
Xyy
^yy
f}}
Co G
t££2£à£à}¥ ¥ O§p§pÄ §§oÿÿö¨Awe'll just put some
semi-random text in§o+
here to see if we can
find this later with
grep. For simplicity's
sake, we'll include the
word semi-unusual so that we
have something in this
file that probably won't
be in any other files
Sure, it's not perfect (a little garbage to edit out), but it's better than nothing ;)
Tomorrow, we'll take a look at how lazarus can make this process much simpler. ...and take much much longer ;)
Cheers,
, Mike
Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.
