Hi, all!

I have a very specific problem and, of course, I need an equally specific remedy. So, I was dumb enough to wipe my /home folder a few days ago. However, I haven't touched the HDD (an 80Gb drive of which 60Gb is a single primary partition mounted as /home) after that at all. So I'm pretty sure all the data is still there.

I am aware that data recovery is not an easy task with ext3 file systems. I've already seen many posts that say that ext3 data recovery is a manual task which requires you to literally hand-parse the HDD searching for file data. So, what I'm interested in is a Live or Rescue CD that I can use to embark on this heroic mission.

EDIT: I only need to recover 1000+ jpg files so I guess the specific file type will make the task a bit easier, won't it?

Needless to say, I'm a bit new to this kind of stuff so a link to a detailed newbie-proof guide would also be welcome. Actually, I'm pretty confident I will eventualy be able to tackle somewhat more advanced guides, so, anything at all is good enough.

And yeah, it's worth all the time I've got. The data I wiped is pretty important to me... Ooo, and yes, I will learn to back it up next time.

Thanks!

you basically use grep to search for things you know are in your files. In your case, this is probably the ".jpg" in the filenames.

grep -a -B 1 -A 5 /dev/hda1 jpg

This will show you one line before and one line after the entry that shows the string "jpg". Most of the rest will look like junk. Once you know where these things are, you can increase the grep range to include more of the file. It's usually pretty obvious when you reach the ends of a file.

Of course, you could always just dump the contents of the drive to a text file and eyeball it line by line with a text editor (or use an editors search functions).

grep -a /dev/hda > hda1dump.txt
less hda1dump.txt

When you get what looks like your jpeg, copy and past it's extent to another file with the jpg extension, then see if you can view it.

And the lesson is - when using rm, make sure you limit the removal by adding a name feild... even when there are only files you want to remove in there. It is better to issue the command several times to get all the files than to go through this mess.

http://www.csummers.org/index.php/20...xt3-partition/

Two free products: recover and e2extract can be obtained over the web - they are for ext2, but have success on ext3.

Thanks for your reply, Simon Bridge. There are some things you could clear up for me, though. First of all, the HDD files are supposed to be on is empty. I guess the data is in there, but the inodes are all gone. So, what is grep doing when you

Ok, so I get some of it. "-a" is for "binary input as text output". "-B 1" is to grep out one line before, and "-A 5" for 5 lines after the found instance. But, does grep work with HDD raw content itself, or it works with files? And another thing. Grep will output binary data as text? So does that mean that binary and text data is the same thing and that it just depends on the way apps look at the data? (Sorry for this basic question, I'm just starting to enjoy this field... I'm a designer by trade, so... so much stuff to learn! )

Here what I thought I should do. Make an image of the partition (which is hdd1, btw) and work with simething (you pointed out that the something is the grep, indeed) to parse through that file. I would first disconnect the HDD and connect another one (40Gb should do it) to copy results on. Does that sound reasonable? I just don't want to risk corrupting the HDD contents.

I had already tried recover, and I think I also tried e2extract, and also debugfs. But it seems that there are no inodes that point to deleted files. So, I had to give up.

Thanks again for the tips.

1 members found this post helpful.

yep - you can answer this question for yourself by just doing it.Sort of. All data is binary. You can represent binary in lots of different ways - like I used to favour hex, giving two hex digits for each byte.

However, for the kind of search you are doing, it is more convenient to use plain text. Most of what you are looking for will just print gibberish on the screen because that will be stuff intended for the computer and not human eyes. But some of the data will be in the form of text strings. These strings are meaningless to the computer and are included for the human to use.

An example is the filename. The computer dosn't care what the file is called.

Another example is the device names and so on in the output of lspci. The computer dosn't actually know about these, they are stored as plain old strings in a file on an eprom on the pci card.

The kind of search you want to do requires patience, time, and experience.

For practise - copy some files and erase the copies. Then set to grepping for them. Text files are easiest, so try those first. Pay attention to how the file is organised besides the basic text part. See if you can spot the beginning of the file and the end-of-file marker. See if the file is stored all in one peice or in several bits. Then practise on jpegs - they'll look different and the block of data you want to copy will look like so much gibberish.

When you copy it, you are just copying bytes. So you need to know that the program doing the copying isn't adding extra bytes of it's own (like inserting carriage returns or adding markers which tell the computer this is a special file like a plain-text file). Probably it is best just to use grep with a pipe.Technically it is a bit late, but that would be prudent caution. However, grep only reads the data. So long as you don't do any writing you are fine.

Anything of interest you copy to another partition.That's pretty much what the delete thing is supposed to do. It means that your file system is more stable at the expence of losing files completely with the rm command.

Tanks for your time, your patience, and valuable advice. I've taken some time off the net playing with Kanotix so I haven't read your post until just now. I will take your advice and play with grep a bit (can hardly wait!). Thanks again.

I don't know if the original poster has already recovered his files
or still has an intact copy of the disk, but if not perhaps someone
else will find this page via Google (as I did) and find the info useful.

Since he is trying to recover jpeg images rather than some other
arbitrary data he's in luck. There are several jpeg recovery
tools around, mostly written by people who accidently formatted
a CF card. A hard drive in Linux is a file like any other of
course, so it can be grepped, and since we know what a JPEG header
looks like we can grep for those bytes which indicate the start
of a jpeg file. That's essentilly what these tools do, but while
the search for the headers the conveniently cut the data into
seperate files seperated at the point were the jpeg headers start.
This can normally recover most of your images. You'll also get
at least one or two large files that are NOT jpeg images - these
files have al of the data that came before or after the images.
More info and the actual software I used can be found here:

www . cs . washington . edu /homes/oskin/saveimg.html
(The spam protection on the board won't let you post any
URLs until you've made several posts, so I had to put in some
spaces in that URL to trick it. The spaces should be removed.)

keywords to assist people searching for this info:
jpg recover jpeg image picture CF card SD card Linux

This is a good first post raymore, well done

I think you can write the urls, they just won't be active. But quick - find another four posts to answer and you'll have full access. (See the "0 reply threads" in the Main Menue on the right.)

Maybe, and maybe not. I tried foremost (or whatever it was called, I forgot) to carve the data automatically. All of the images were corrupt exept those that were not from my digicam. Even MJPEG files were 'recovered' as series of perfectly OK jpeg files, but the photos I was looking for were corrupt. My guess is that Canon's JPG files contain some non-standard data that may have interfered with data carving, or that foremost is simply not very good with large jpegs.

Well, I really wanted to get my hands on grep, but my wife went berserk because I kept staring at "useless garbage" all the time without much progress, so I had to give up. I'll try that again, as well as the URL that you so kindly posted, later when I'm on vacation. Meanwhile, I'll keep the HDD 'on the ice'.

BTW, I second the "This is a good first post raymore". Thanks.

My Disk was parted like this:
hd1 5G FAT32 primary
Extended 75G
hd5 35G FAT32
hd6 swap 256M
hd7 5G ReiserFS
hd8 10G ReiserFS
hd9 rest ReiserFS
On hd1 was Winf**k-2k
Then I wanted to install Winf**k-98 again because of one game I had.
DAMN!!!!
All partition was lost and I had only a very old Bkup. On hd 7 was all my work of my company. I tried the rebuilt-tool but it couldn't find anything on an EXTENDED partition with reiserFS on it. Than I made this:
hda1 5G FAT32
hda5 70G extended
hda6 5G ReiserFS /
hda7 10G ReiserFS /company
hda8 rest ReiserFS /bkup
So, all my data should be in hd8 because my company-partition was above 40G.

Then I used this program:
http://foremost.sourceforge.net/pkg/foremost-1.1.tar.gz
have a look yourself how this program works, but it resored allmost all data I lost.

TRY IT

Sören

So, all my data should be in hd8 because my company-partition was above 40G.

Then I used this program:
http://foremost.sourceforge.net/pkg/foremost-1.1.tar.gz
have a look yourself how this program works, but it resored allmost all data I lost.[/quote]... foremost recovered all your data even though you repartitioned the drive?!!!! <gibber>

I'm gonna have to resort to erasing secure files with a magnet from now on!

Yes,
you can test this with a flashcard from a digital camera.
You may see photos from years ago when you didn't fill up the memory again.
For the flashcards I used:
./foremost -v -T -t jpg avi -i /media/sdc1 (sdc1 is the flashcard you may correct this)


Look also:

http://www.linuxquestions.org/questi...d.php?t=428962

It's the same, but a little better explained.

For secure deletation you can use secure-delete-3.1

Now you can open your RECOVER-COMPANY!!!

Sören

I too had the same problem and thanks to this post I am much closer to resolving it

0 members found this post helpful.

Necro-posting, The Black Art of reviving old threads, is frowned upon unless it has a specific and compelling reason. That obviously does not apply to you since you have not added anything substantial at all with any of your posts so far. So don't do that again.