Re: All data "gone," lost+found is left.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Aside from the info Andreas provided, you could try e2salvage. It is
designed to go through the disk block by block and reconstruct the directory
structures from that.

It's advisable (always do that before trying disaster recovery) to make an
image backup of your drive first though (try dd -if /dev/hdX -of <file or
device name>)
Note that when -of is a device, the device will be overwritten with the -if
device data. Also realize this is a bit-for-bit copy, so you'll need  *at
least* the same amount of free space as the *total amount* of bytes the old
device has...

http://project.terminus.sk/e2salvage/

Oh, another thought: I assume you are sure the drive was not part of a RAID
set?

HTH

--FP
----- Original Message -----
From: "Patrick Hendricks" <hendripa@onid.orst.edu>
To: <ext3-users@redhat.com>
Sent: Sunday, January 19, 2003 1:08 PM
Subject: All data "gone," lost+found is left.


> So you know, I don't know too much about file systems.
>
> Here is what I did:  I have two linux boxes.  the first box had many
> hardrives in it, but needed to be used in other ways.  So I took 4
> harddrives out of it and placed it in the other Linux box.  I thought it
> would be able to read these right away. (maybe this was my mistake?)  I
> could mount all of the drives in there.  three of my drives had all
> their data remain intact, but the fourth one did not.  all that remained
> on the 4th drive was the lost+found directory.
>
> I'm sure the data is still there, it's just eluding me.  sadly I don't
> know how to find it.  Thought I found dump2fs which tells me that it
> needs recovery.  don't know how much help this will give:
>
> dumpe2fs /dev/hdg1
> dumpe2fs 1.32 (09-Nov-2002)
> Filesystem volume name:   <none>
> Last mounted on:          <not available>
> Filesystem UUID:          1c762a60-0820-4ad1-9e61-ea5066870851
> Filesystem magic number:  0xEF53
> Filesystem revision #:    1 (dynamic)
> Filesystem features:      has_journal dir_index filetype needs_recovery
> sparse_super
> Default mount options:    (none)
> Filesystem state:         clean
> Errors behavior:          Continue
> Filesystem OS type:       Linux
> Inode count:              3751936
> Block count:              7502347
> Reserved block count:     375117
> Free blocks:              7376401
> Free inodes:              3751925
> First block:              0
> Block size:               4096
> Fragment size:            4096
> Blocks per group:         32768
> Fragments per group:      32768
> Inodes per group:         16384
> Inode blocks per group:   512
> Filesystem created:       Sun Jan 12 20:33:30 2003
> Last mount time:          Sun Jan 19 17:16:18 2003
> Last write time:          Sun Jan 19 17:16:18 2003
> Mount count:              2
> Maximum mount count:      22
> Last checked:             Sun Jan 12 20:33:30 2003
> Check interval:           15552000 (6 months)
> Next check after:         Fri Jul 11 21:33:30 2003
> Reserved blocks uid:      0 (user root)
> Reserved blocks gid:      0 (group root)
> First inode:              11
> Inode size:               128
> Journal UUID:             <none>
> Journal inode:            8
> Journal device:           0x0000
> First orphan inode:       0
> Default directory hash:   tea
> Directory Hash Seed:      0c75b950-e953-450b-a622-0108fc922004
>
>
> Any help is appreciated.
>
> Thanks,
> Pat
>
>
>
> _______________________________________________
> 
> Ext3-users@redhat.com
> https://listman.redhat.com/mailman/listinfo/ext3-users
>



_______________________________________________

Ext3-users@redhat.com
https://listman.redhat.com/mailman/listinfo/ext3-users

[Index of Archives]         [Linux RAID]     [Kernel Development]     [Red Hat Install]     [Video 4 Linux]     [Postgresql]     [Fedora]     [Gimp]     [Yosemite News]

  Powered by Linux