Just deleted my hard drive. Someone HELP!

[myk02k]

That's the spirit!

They're all numbers, right? Those'll be inode numbers for inodes that pointed somewhere, but for which there appeared to be no allocations. Some of those, perhaps many of them, may point to some of your data files.

I have recovered files from inode data in lost+found, but it's been a long, long time since I've done that.

Here's a good explanation of Unix inodes: Inode pointer structure.

Jim

Yup, the files are all numbers in the lost+found folder. Any further advice?

If this helps, GParted sees the hard drive as "unallocated", yet the drive is mounted and I can see a few files.

I just bought a new USB flash drive so that I can rely upon something other than the hard drive for school until I get my files back. After its formatted, I'll try testdisk again and another utility called extundelete, which came up after a few Google searches.

Thanks for the help!
-Mike

[GSF1200S]

Yup, the files are all numbers in the lost+found folder. Any further advice?

If this helps, GParted sees the hard drive as "unallocated", yet the drive is mounted and I can see a few files.

I just bought a new USB flash drive so that I can rely upon something other than the hard drive for school until I get my files back. After its formatted, I'll try testdisk again and another utility called extundelete, which came up after a few Google searches.

Thanks for the help!
-Mike

Any issue Ive had with filesystems has been fixed by fsck, so I apologize for not being able to help you more. Depending on how many files you have and their size and assuming you have another computer that you can put the files on (like a desktop or another laptop), you could setup an FTP server (assuming too that you dont have an enclosure for the drive) on the other machine and transfer the numbered folders and files to that machine utilizing a liveCD. If you dont have another computer, perhaps a friend would be willing to help?

Thats prolly not what you were looking for as help- I understand you mean to recover the filenames, etc. But as another poster on here said, if dd overwrote the journal, I dont think youd be able to get all that information back without taking it in and having some really expensive software scan the drive. Even then you might not get the fileinfo. You might have to go through them one by one- man I hope if thats the case there isnt too many files. At least you HAVE the files.

Good luck man.. it sucks and I wish I could do more to help you. Maybe someone else or a former poster will come up with a far better solution.

[J V]

Hey guys. Long story short, I was trying to mount an iso but was unable to because it was a raw CD. Someone on the forums posted to use a command "dd" and set it at /dev/sdb1. I know, it should've been set to a USB stick or clear partition, but the post was unspecific on and I inadvertently wiped my whole hard drive clean.

If there is SOMEBODY out there that can tell me how to recover everything before the DD, at the very least recover my files, please contact me. My AIM screen name is "myk02k" if you can IM me over posting here, but any advice will be appreciated.

Thanks!

dd requires an if, so there shoulden't be any way to recover the data sorry... mounting an iso doesn't require dd, methinks you should hunt him down and kill (report post) him for malicious commands?

[northrup]

If only the first 600 MB were overwritten, then the remaining however many GBs should still exist. If you can find, say, a hex editor that allows you to view the data on a hard drive, there's the possibility of having that extra step in retrieving the raw data. Then, if you can somehow split up that raw data into files, you're golden.

Hope this helps. I know how you feel. I've accidentally erased drives before with Linux (i.e. trying to install Damn Small Linux on a desktop from a USB drive and, instead of specifying the hard drive, specifying the USB drive and reformatting it). I wish you the best of luck

[jenaniston]

. . . The problem is that all the directory and inode information has been overwritten, so there's nothing to point to the files and directories anymore.
All your data is still out there, most likely, but the pointers to it are all gone.
. . .

I have read all this and this sounds right - and I also agree don't give up totally just yet.

to check if data exists there, try running hexdump on the partition . . . the output dumped to the screen (use ctrl-c to stop of course) can show that data IS in fact there.

But even then . . . "there's nothing to point to the files and directories anymore. All your data is still out there, most likely, but the pointers to it are all gone."

hexdump -C /dev/sda1

[myk02k]

After browsing through lost+found with Nautilus, I realized that there are many, MANY files in this folder than I thought. Each folder (designated with an inode #?) has multiple files stored within. If this is everything, it could be a long, long time before I can sort everything from my home folder back in order. Nevertheless, it seems like more files than I expected was found by e2fsck.

The issue at hand now is that Nautilus keeps freezing up when trying to display the contents of this folder.

I have read all this and this sounds right - and I also agree don't give up totally just yet.

to check if data exists there, try running hexdump on the partition . . . the output dumped to the screen (use ctrl-c to stop of course) can show that data IS in fact there.

But even then . . . "there's nothing to point to the files and directories anymore. All your data is still out there, most likely, but the pointers to it are all gone."

hexdump -C /dev/sda1

I honestly have no idea how to read the hexdump output. I'll have to educate myself a little bit before I can figure what all those numbers mean. I've never taken a computer course in my entire life (believe it or not).

[jenaniston]

. . . I realized that there are many, MANY files in this folder than I thought. Each folder (designated with an inode #?) has multiple files stored within.
. . .
The issue at hand now is that Nautilus keeps freezing up when trying to display the contents of this folder.

I honestly have no idea how to read the hexdump output. I'll have to educate myself a little bit before I can figure what all those numbers mean. I've never taken a computer course in my entire life (believe it or not).

Ohh no, no desire to read the hexdump output . . .
I only suggested to run hexdump to show that there is in fact data there - a trick from the linuxquestions forum . . .

you did NOT get all 0 's - that is all it was to reveal . . .

and you also found the files in lost+found . . . so good -
must be that the "pointers" are there too ? (a single file can have it's data in all sorts of different locations)

[myk02k]

OK I just ran an interesting program called extundelete. I used the "--restore-all" option.

--restore-inode ino[,ino,...]

Restore the file(s) with known inode number 'ino'.  The restored files are created in ./RESTORED_FILES with their inode number as extension (ie, inode.12345).

--restore-file 'path'  Will restore file 'path'. 'path' is relative to root of the partition and does not start with a '/' (it must be one of the paths returned by --dump-names).  The restored file is created in the current directory as 'RECOVERED_FILES/path'.

--restore-files 'path' Will restore files which are listed in the file 'path'.  Each filename should be in the same format as an option to --restore-file, and there should be one per line.

--restore-all Attempts to restore everything.

extundelete also can show the contents of the journal, Show process entries "on or before/after 'dtime'", show info on inode, show info on block, etc.

Here's what some of the output looked like, if it's of any use...

Restored inode 395627 to file RECOVERED_FILES/lost+found/#483390/E33FD061d01
Restored inode 395666 to file RECOVERED_FILES/lost+found/#483390/BB638EB1d01
Restored inode 395683 to file RECOVERED_FILES/lost+found/#483390/F4050140d01
Restored inode 395706 to file RECOVERED_FILES/lost+found/#483390/6E25EEE0d01
Failed to restore inode 581694 to file RECOVERED_FILES/lost+found/#581693/2007 - Live The Light It Up Tour:Inode does not correspond to a regular file.

I'm still having a rough time looking at the LOST+FOUND folder with Nautilus, as it keeps locking up. Should I move these files around to different folders so that I can sort through them?

By using Properties in Nautilus, the contents indicate 273,222 items totalling 319.7 GB, which sounds equal to the amount of data I had before I destroyed everything. Is there any easier way of sorting out LOST+FOUND rather than doing it by hand?

[JSeymour]

Should I move these files around to different folders so that I can sort through them?

NO! Absolutely not! You must not write to that drive at all!

As I tried to explain earlier: All those inode numbers are in lost+found because fsck thought they were inodes for stuff that didn't exist anymore. This is because you wiped-out a goodly portion of Linux' file structure with that dd command you executed. Now Linux thinks that the blocks all those "lost" inodes point to are free. Any writing to that disk may over-write valid, but "lost" data on it.

You should be mounting that corrupted filesystem read-only from this point on.

By using Properties in Nautilus, the contents indicate 273,222 items ...

Yeah, well, Nautilus probably wasn't designed with the idea of cataloging 273,222 directory items in one go.

Is there any easier way of sorting out LOST+FOUND rather than doing it by hand?

I'm not sure what you would suggest. How could any utility possibly divine what those inodes point to?

I'm wondering: Those URLs I pointed to earlier: Did you read them? You need to, so you'll understand just what you're dealing with.

Here's another that might be of use to you. I found it by just entering "restore file from inode number lost+found": HOWTO recover deleted files on an ext3 filesystem

I suggest you slow down and do some research and learning before you lose the one possible chance you have to recover your data.

Jim

[myk02k]

I appreciate the advice, especially because this is all unfamiliar territory for me. Unfortunately, before you mentioned to mount the disk as ro, it will no longer mount after I ran extundelete. I've tried to repair it using 'e2fsck -y /dev/sda1', but it continually hangs when attempting to fix multiply-claimed blocks.

I should've simply found and backed up my lecture notes when I had the chance. So now I'm back on square one. If I can't get the disk to mount again by tonight, I'm afraid I'll have to cut my losses. Although I found someone an hour away that can store an image of my disk for me, there's no point if I can't even mount the filesystem anymore.

This is what I get when trying to mount:

Error mounting: mount exited with exit code 32: mount: wrong fs type, bad option, bad superblock on /dev/sda1,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

dmesg | tail

[ 6291.045095] EXT4-fs (sda1): ext4_check_descriptors: Checksum for group 1 failed (61452!=60400)
[ 6291.045110] EXT4-fs (sda1): group descriptors corrupted!

EDIT:

Right now, I'm using an alternate superblock (the last one on my partition) and things are looking promising thus far.