[SOLVED] Where is the backup superblocks?

miceagol · 03-02-2010, 06:02 PM

Hi there!

When I inserted a 1 TB-drive into my new Qnap NAS, it removed my partition on that drive without notifying me first. The partition was replaced with two small partitions and a swap:

Code:

Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x000934a8

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1          66      530113+  83  Linux
/dev/sdb2              67         132      530145   82  Linux swap / Solaris
/dev/sdb3             133      121538   975193695   83  Linux
/dev/sdb4          121539      121600      498015   83  Linux

The damaged partition is /dev/sdb3.

I'm trying to locate a backup super block on that partition so that I can restore the data, but all default backup superblock locations given by mke2fs didn't work:

Code:

michaeka@trillian:~$ sudo mke2fs -t ext2 -n /dev/sdb3
mke2fs 1.41.9 (22-Aug-2009)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
60956672 inodes, 243798423 blocks
12189921 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
7441 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
	4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
	102400000, 214990848

The error I get when attempting to restore with these block locations is:

Code:

e2fsck 1.41.9 (22-Aug-2009)
fsck.ext3: Bad magic number in super-block while trying to open /dev/sdb3

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

Is there a way to retrieve the actual locations of the backup superblocks, or any other ways to guess their locations?

syg00 · 03-02-2010, 06:14 PM

Are you implying that originally the drive had just one partition - that presumably started at cylinder 1 ?.
What you're attempting will only be valid if your original partition started at precisely cylinder 133. Not very likely, but possible.
Try using testdisk to scan the drive for deleted partitions.

miceagol · 03-02-2010, 06:22 PM

Quote:

Originally Posted by syg00

Are you implying that originally the drive had just one partition - that presumably started at cylinder 1 ?.
What you're attempting will only be valid if your original partition started at precisely cylinder 133. Not very likely, but possible.
Try using testdisk to scan the drive for deleted partitions.

Yes, it contained only one partition that covered the entire disk. Do you mean that I should take the backup superblock location minus 133 to find the actual location?

I've tried using testdisk, but the tutorials didn't apply well to my case, so I fell off. I'll try a deep search again after making a backup image of the partition.

syg00 · 03-02-2010, 06:33 PM

Ugh - better hope those partitions haven't had mkfs or mkswap run against (any of) them.
If it was simply a matter of your partition being deleted and those added - without any of them being formatted, simply delete all those partitions and redefine your big one. Then try the mke2fs -n, followed by mke2fs for real.

If any of those new partitions have been formatted - especially sdb1, then you've probably lost the needed metadata for your original filesystem.

miceagol · 03-03-2010, 02:33 PM

Quote:

Originally Posted by syg00

Ugh - better hope those partitions haven't had mkfs or mkswap run against (any of) them.
If it was simply a matter of your partition being deleted and those added - without any of them being formatted, simply delete all those partitions and redefine your big one. Then try the mke2fs -n, followed by mke2fs for real.

So I can delete the new partitions and resize my old one to cover the whole disk. How do I redefine it? With gparted resize tool?

Quote:

Originally Posted by syg00

If any of those new partitions have been formatted - especially sdb1, then you've probably lost the needed metadata for your original filesystem.

The new partitions show up as ext3, so I guess they have to be formatted. The rest of the overwritten partition shows up as Unknown. So this means it is useless to recover its superblock?

syg00 · 03-03-2010, 05:03 PM

Just delete and re-define from fdisk. Won't help if they've been formatted - if you run an fsck after that it'll work, but for the smaller size of that sdb1 filesystem, not the (newer) partition that would actually cover the whole disk.
Best bet might be to see if photorec can find your data - from the same people as testdisk (does more than just photos).

Don't use gparted - it will resize the filesystem as well, and obliterate even more of the underlying data.

miceagol · 03-04-2010, 04:36 PM

Quote:

Originally Posted by syg00

Just delete and re-define from fdisk. Won't help if they've been formatted - if you run an fsck after that it'll work, but for the smaller size of that sdb1 filesystem, not the (newer) partition that would actually cover the whole disk.

I haven't done this before. Could you tell me the details of how you redefine with fdisk?

Quote:

Originally Posted by syg00

Best bet might be to see if photorec can find your data - from the same people as testdisk (does more than just photos).

I used photorec too. But I don't really know what to do with the recovered data. It was mostly music and movies on that disk, and all of it is just nameless bits and pieces of the original files.

syg00 · 03-04-2010, 07:58 PM

Basically straight-forward - as root get into fdisk, and use the "m" command as it suggests to get a list of all the commands.
- "p" to printout the current partitions
- "d" to delete each in turn
- then "n" for a new partition - take the defaults for start and end cylinder; will give you the entire disk again.
- "w" to write the changes to disk.
- "q" to quit.

You may need to reboot to get the updates recognised - maybe not.

As I said, I suspect you'll find just the filesystem from the smaller sdb1, but no harm in trying.

miceagol · 03-09-2010, 01:45 PM

Hmm, something happened. The file system was successfully modified by fdisk, and I then tried to search for superblocks at the backup location:

Quote:

michaeka@trillian:~$ sudo mke2fs -t ext3 -n /dev/sdb1
mke2fs 1.41.9 (22-Aug-2009)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
61054976 inodes, 244190000 blocks
12209500 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
7453 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848

This was the output of the attempt to use the first backup:

Quote:

michaeka@trillian:~$ sudo e2fsck -b 32768 /dev/sdb1
e2fsck 1.41.9 (22-Aug-2009)
/dev/sdb1 was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #0 (32311, counted=23830).
Fix<y>? yes

Free blocks count wrong for group #1 (32317, counted=32183).
Fix<y>? yes

Free blocks count wrong for group #2 (28250, counted=28244).
Fix<y>? yes

Free blocks count wrong for group #3 (32317, counted=32300).
Fix<y>? yes

Free blocks count wrong (126218, counted=117580).
Fix<y>? yes

Free inodes count wrong for group #0 (6629, counted=6621).
Fix<y>? yes

Directories count wrong for group #0 (2, counted=3).
Fix<y>? yes

Free inodes count wrong for group #1 (6640, counted=6520).
Fix<y>? yes

Directories count wrong for group #1 (0, counted=14).
Fix<y>? yes

Free inodes count wrong for group #2 (6640, counted=6634).
Fix<y>? yes

Directories count wrong for group #2 (0, counted=6).
Fix<y>? yes

Free inodes count wrong for group #3 (6640, counted=6635).
Fix<y>? yes

Directories count wrong for group #3 (0, counted=2).
Fix<y>? yes

Free inodes count wrong (33189, counted=33050).
Fix<y>? yes

/dev/sdb1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sdb1: 150/33200 files (0.0% non-contiguous), 14932/132512 blocks

The output says something about 33200 files, which looks like a number that could be from my deleted partition. Tried to mount using that superblock, and got:

Quote:

michaeka@trillian:~$ sudo mount /dev/sdb1 /home/michaeka/underholdning/ -t ext3 -o sb=32768
mount: wrong fs type, bad option, bad superblock on /dev/sdb1,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so

What does all this mean?

miceagol · 03-09-2010, 01:47 PM

I tried superblock 294912, but it continues forever with messages of inodes. This is an extract of its output:

Quote:

Inode 26487 has INDEX_FL flag set but is not a directory.
Clear HTree index<y>? yes

Inode 26487, i_size is 18088899802481867301, should be 0. Fix<y>? yes

Inode 26487, i_blocks is 94026934195481, should be 0. Fix<y>? yes

Inode 26614, i_size is 8112755350589936208, should be 0. Fix<y>? yes

Inode 26614, i_blocks is 117929936028238, should be 0. Fix<y>? yes

Inode 26486, i_blocks is 82712082179142, should be 0. Fix<y>? yes

Inode 26537 has compression flag set on filesystem without compression support. Clear<y>? yes

Inode 26537 has INDEX_FL flag set but is not a directory.
Clear HTree index<y>? yes

Inode 26537, i_size is 13193773333321313171, should be 0. Fix<y>? yes

Inode 26537, i_blocks is 201372665755169, should be 0. Fix<y>? yes

Inode 26438, i_size is 2377374745911240526, should be 0. Fix<y>? yes

Inode 26438, i_blocks is 1139857888, should be 0. Fix<y>? yes

Inode 26191, i_size is 2156164020090780720, should be 0. Fix<y>? yes

Inode 26191, i_blocks is 2507395769, should be 0. Fix<y>? yes

Inode 26526 has compression flag set on filesystem without compression support. Clear<y>? yes

Inode 26526 has INDEX_FL flag set but is not a directory.
Clear HTree index<y>? yes

Inode 26526, i_size is 11558143975656680214, should be 0. Fix<y>? yes

Inode 26526, i_blocks is 25057671131542, should be 0. Fix<y>? yes

Inode 26192 has compression flag set on filesystem without compression support. Clear<y>? yes

Inode 26192 has INDEX_FL flag set but is not a directory.
Clear HTree index<y>? yes

Inode 26192, i_size is 17898037124913362867, should be 0. Fix<y>? yes

Inode 26192, i_blocks is 4225433065, should be 0. Fix<y>? yes

Inode 26624, i_size is 15668180479231238518, should be 0. Fix<y>? yes

Inode 26624, i_blocks is 1846477826, should be 0. Fix<y>? yes

Inode 26236 has INDEX_FL flag set but is not a directory.
Clear HTree index<y>? yes

Inode 26236, i_size is 14544081225784882372, should be 0. Fix<y>? yes

Inode 26236, i_blocks is 1972132013, should be 0. Fix<y>? yes

Inode 26198 has compression flag set on filesystem without compression support. Clear<y>? yes

Inode 26198 has INDEX_FL flag set but is not a directory.
Clear HTree index<y>? yes

Inode 26198, i_size is 14229090292796177805, should be 0. Fix<y>? yes

Inode 26198, i_blocks is 2884396022, should be 0. Fix<y>? yes

Inode 26631 has illegal block(s). Clear<y>? yes

Illegal block #0 (1768607659) in inode 26631. CLEARED.
Illegal block #1 (3588494319) in inode 26631. CLEARED.
Illegal block #2 (438504565) in inode 26631. CLEARED.
Illegal block #3 (3436551252) in inode 26631. CLEARED.
Illegal block #4 (812537790) in inode 26631. CLEARED.
Illegal block #5 (1950062136) in inode 26631. CLEARED.
Illegal block #6 (4173597069) in inode 26631. CLEARED.
Illegal block #7 (1687456202) in inode 26631. CLEARED.
Illegal block #8 (3791411134) in inode 26631. CLEARED.
Illegal block #9 (1383909811) in inode 26631. CLEARED.
Illegal block #10 (2725847525) in inode 26631. CLEARED.
Too many illegal blocks in inode 26631.
Clear inode<y>? yes

Is this from the damaged partition? I really don't understand these outputs...

miceagol · 03-09-2010, 03:40 PM

I tried to run sudo e2fsck -y -f -v /dev/sdb1, which seemed to fix a bunch of things on the drive. The statistics at the end says:

Code:

/dev/sdb1: ***** FILE SYSTEM WAS MODIFIED *****

   75585 inodes used (0.12%)
   13057 non-contiguous files (17.3%)
      53 non-contiguous directories (0.1%)
         # of inodes with ind/dind/tind blocks: 53624/26784/5989
199118210 blocks used (81.54%)
       0 bad blocks
      37 large files

   71715 regular files
    3358 directories
     129 character device files
     161 block device files
     101 fifos
4294967197 links
      13 symbolic links (0 fast symbolic links)
      98 sockets
--------
   74980 files

When I try to mount the fixed file system with "sudo mount /dev/sdb1 /home/michaeka/underholdning/ -t ext2", I only see the lost+found folder. But the free space is only 125.4 GB, which is similar to the free space my old partition had.

Am I close to finding my files?

miceagol · 03-09-2010, 03:54 PM

Hahaha! I did it! I did it!

I found the files in the lost+found folder. Thank you so much for all your help!