[SOLVED] Recover disc: Bad superblock, lost partition
Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
ubuntu@ubuntu:~$ sudo mke2fs -n /dev/sda
mke2fs 1.42 (29-Nov-2011)
/dev/sda is entire device, not just one partition!
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
122101760 inodes, 488378646 blocks
24418932 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
14905 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
I thought maybe the sb was bad, and tried to mount using a backup
Code:
ubuntu@ubuntu:~$ sudo mount -o sb=98304 /dev/sda /mnt/nas
But that command never returns...
Any other tips or tricks I can test to access the disk? Or is it lost...?
What do you mean "the disk somehow crashed"? What was it doing at the time or what were the symptoms?
Did it you ever experience trouble with the disk before?
And how did you power down the NAS? Pulling the plug or controlled shutdown?
If "/dev/sda" actually is the NAS disk (usually that would be your first local one) what does 'fdisk -l /dev/sda' return? If unsure just run 'fdisk -l'.
What do you mean "the disk somehow crashed"? What was it doing at the time or what were the symptoms?
I was away for two weeks, and sometime during this period, it happened. So I didn't do anything, nor did I have any automated scheduled tasks so my best guess the NAS was idle. We did have major storm though, so it's very likely there were one or more power outages.
The only thing I could do with the NAS, was to login to the web gui, and there the 'recent log' window was full of 'read error on block zz' etc.
I tried to access the disk, both through the shared directories or using the DSM apps, but there was nothing I could do in the GUI, since as soon as I tried to do something, the log just filled up with more of those errors.
Quote:
Did it you ever experience trouble with the disk before?
Nopes.
Quote:
And how did you power down the NAS? Pulling the plug or controlled shutdown?
I tried to do a proper shutdown, but as everything I did (even pressing 'shutdown') just resulted in more error logs, I did pull the plug.
Quote:
If "/dev/sda" actually is the NAS disk (usually that would be your first local one) what does 'fdisk -l /dev/sda' return? If unsure just run 'fdisk -l'.
Yes, I have booted Ubuntu from CD with only the NAS disk present, so /dev/sda is the NAS disk.
I have no idea in which order it copies the blocks, but guessing from 0? And those 4 errors where right in the beginning...
Yes, from the start of the disk. Good thing you're making a backup to play with. Once you're don run 'testdisk' on the image with the "/debug /log" switches and post or attach the output as plain text.
ubuntu@ubuntu:~$ sudo mke2fs -n /dev/sda
mke2fs 1.42 (29-Nov-2011)
/dev/sda is entire device, not just one partition!
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
122101760 inodes, 488378646 blocks
24418932 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
14905 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
Ah ... mke2fs doesn't "check" the disk, it creates a new filesystem on it (and to compound matters, you have done it to the entire device rather than a partition.
Haul out your backups - what was there is gone.
You MAY be able to recover some specific filetypes with photorec from the raw disk data, but any (filenames/fragmented files/files without defined structures) are gone.
The copy is still running. It's a 2Tb disk and I am making a copy to an external USB 2.0 disk...erhmm...
So it's been running for a while now.
Code:
Initial status (read from logfile)
rescued: 0 B, errsize: 0 B, errors: 0
Current status
rescued: 1217 GB, errsize: 20703 kB, current rate: 44957 kB/s
ipos: 1217 GB, errors: 26, average rate: 15038 kB/s
opos: 1217 GB, time from last successful read: 0 s
Copying non-tried blocks...
If I recall correctly I had 1.3 Tb used on the disk, does this mean it willl end soon? Or will 'rescued' increase to 2TB (size of disk)?
And what does these numbers tell me? That it is had managed to copy 1217 GB and it has encountered 26 errors so far, for a total of 20703kB? And are these number good or bad?
Yes, from the start of the disk. Good thing you're making a backup to play with. Once you're don run 'testdisk' on the image with the "/debug /log" switches and post or attach the output as plain text.
Morning!
ddresucue is still running. I did read this can be quite time consuming, but now it's been running for almost a week...
Code:
Initial status (read from logfile)
rescued: 0 B, errsize: 0 B, errors: 0
Current status
rescued: 2 TB, errsize: 11104 kB, current rate: 0 B/s
ipos: 35776 kB, errors: 98, average rate: 4184 kB/s
opos: 35776 kB, time from last successful read: 1.9 d
Retrying bad sectors... Retry 1
Don't know if they interfer with each other, but I did run Testdisk the on copied drive.
It does seem to find a proper partition, but cant locate any files on the partition...
Code:
Using locale 'en_US.UTF-8'.
Sat Nov 16 09:49:08 2013
Command line: TestDisk /debug /log /dev/sdf
TestDisk 6.13, Data Recovery Utility, November 2011
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org
OS: Linux, kernel 3.8.0-29-generic (#42~precise1-Ubuntu SMP Wed Aug 14 16:19:23 UTC 2013) x86_64
Compiler: GCC 4.6
Compilation date: 2012-02-05T07:15:52
ext2fs lib: 1.42, ntfs lib: 10:0:0, reiserfs lib: none, ewf lib: none
Hard disk list
Disk /dev/sdf - 2000 GB / 1863 GiB - CHS 243201 255 63, sector size=512 - Initio ST2000DM001-1CH1, FW:3.01
Partition table type (auto): None
Disk /dev/sdf - 2000 GB / 1863 GiB - Initio ST2000DM001-1CH1
Partition table type: None
Interface Advanced
recover_EXT2: s_block_group_nr=0/14904, s_mnt_count=2/4294967295, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 488378646
recover_EXT2: part_size 3907029168
P ext4 0 0 1 243201 80 63 3907029168 [USB]
EXT4 Large file Sparse superblock Recover, 2000 GB / 1863 GiB
search_superblock
recover_EXT2: s_block_group_nr=0/14904, s_mnt_count=2/4294967295, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 488378646
recover_EXT2: part_size 3907029168
Ext2 superblock found at sector 2 (block=0, blocksize=4096)
ext4 0 0 1 243201 80 63 3907029168 [USB]
superblock 0, blocksize=4096 [USB]
To repair the filesystem using alternate superblock, run
fsck.ext4 -p -b superblock -B blocksize device
dir_partition inode=2
P ext4 0 0 1 243201 80 63 3907029168 [USB]
EXT4 Large file Sparse superblock Recover, 2000 GB / 1863 GiB
ext2fs_dir_iterate failed with error 2133571402.
Directory /
TestDisk exited normally.
Right now it's retrying bad sectors. That takes time.
Quote:
Originally Posted by rydman
Don't know if they interfer with each other, but I did run Testdisk the on copied drive.
Impatience ;-p Sure you can run Testdisk as long as you won't let it write anything.
Quote:
Originally Posted by rydman
It does seem to find a proper partition, but cant locate any files on the partition...
In essence you first re-establish partition boundaries, then recover the file system and only then look for files. Given the amount of disk I/O I wouldn't suggest you to run Photorec at the same time as ddrescue.
Right now it's retrying bad sectors. That takes time.
Phew... Indeed. 2-3 more days to go, at this speed...
Code:
Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued: 0 B, errsize: 0 B, errors: 0
Current status
rescued: 2 TB, errsize: 11104 kB, current rate: 0 B/s
ipos: 35482 kB, errors: 98, average rate: 2957 kB/s
opos: 35482 kB, time from last successful read: 4.2 d
Retrying bad sectors... Retry 2
Quote:
Impatience ;-p Sure you can run Testdisk as long as you won't let it write anything.
Impatience is a virtue
Quote:
In essence you first re-establish partition boundaries, then recover the file system and only then look for files.
And this I can do with TestDisk alone? Or do I need any other programs?
Quote:
Given the amount of disk I/O I wouldn't suggest you to run Photorec at the same time as ddrescue.
Have read about Photorec when googling to recover a disk, but never read into what it really does...
ps. First, I really appreciate your replies. Have been really helpful. And if I come out as a layman at this task, I am... hehe
And this I can do with TestDisk alone? Or do I need any other programs?
Sorry for the late reply. You could use 'fdisk' or 'sfdisk' if you know the exact boundaries but else Testdisk can often guess them OK. What you recover a file system with depends on what's left (and what you already did to destroy modify partitions). In some cases you can use testdisk to drill down directory trees and fetch a particular file, in others pointing fsck at a backup copy of the super block is enough to return a file system to a usable state and in others you would use a brute force header / footer carving tool like Photorec, Foremost or Scalpel.
Quote:
Originally Posted by rydman
ps. First, I really appreciate your replies. Have been really helpful. And if I come out as a layman at this task, I am... hehe
You're welcome. That's good to know. And don't sweat it because we all started out as laymen.
Once ddrescue finished, I ran testdisk on a copy of the copy. I had to do a deep search and eventually it did find a partition usable to extract the files!
Some of the files were lost, but most of them was recovered. Happy days! And thanks for the help!
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
