[SOLVED] Recover disc: Bad superblock, lost partition

rydman · 11-10-2013, 01:34 PM

Evening!

I had a Synology DS212J running with only one disk (DSM 4.3-3776).

The disk somehow crashed while away and made the DS unresponsive.

On the Synology forum, there is a guide howto access the disk using Ubuntu, and tried that, but was not able to mount/access it.

http://forum.synology.com/enu/viewto...?f=160&t=51393

While in Ubuntu, I checked the disk using mke2fs

Code:

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...?

unSpawn · 11-10-2013, 04:19 PM

Quote:

Originally Posted by rydman

The disk somehow crashed while away

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'.

rydman · 11-10-2013, 04:46 PM

Quote:

Originally Posted by unSpawn

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.

Code:

ubuntu@ubuntu:~$ sudo fdisk -l /dev/sda
ubuntu@ubuntu:~$

No output.

I have started to do a copy, so I can mess around with that one instead:

Code:

ubuntu@ubuntu:~$ sudo ddrescue -r3 /dev/sda /dev/sdf rescue.log --force


Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued:         0 B,  errsize:       0 B,  errors:       0
Current status
rescued:    72976 MB,  errsize:  17947 kB,  current rate:   29294 kB/s
   ipos:    72994 MB,   errors:       4,    average rate:   10111 kB/s
   opos:    72994 MB,     time from last successful read:       0 s
Copying non-tried blocks...

I have no idea in which order it copies the blocks, but guessing from 0? And those 4 errors where right in the beginning... What ever that tells me...

unSpawn · 11-10-2013, 06:13 PM

Quote:

Originally Posted by rydman

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.

descendant_command · 11-10-2013, 09:45 PM

Quote:

Originally Posted by rydman

While in Ubuntu, I checked the disk using mke2fs

Code:

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.

unSpawn · 11-11-2013, 01:39 AM

Quote:

Originally Posted by descendant_command

Ah ... mke2fs doesn't "check" the disk, it creates a new filesystem on it

No, it doesn't. You failed to notice he properly used "-n".

descendant_command · 11-11-2013, 02:00 AM

Ah ... I did indeed!
Carry on then ...

rydman · 11-11-2013, 01:15 PM

Quote:

Originally Posted by descendant_command

Carry on then ...

"Keep calm and carry on!"

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?

unSpawn · 11-12-2013, 05:09 PM

Quote:

Originally Posted by rydman

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)?

You told it to copy /dev/sda so it will copy the whole of /dev/sda.

rydman · 11-16-2013, 03:33 AM

Quote:

Originally Posted by unSpawn

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.

unSpawn · 11-16-2013, 04:22 AM

Quote:

Originally Posted by rydman

Code:

Retrying bad sectors... Retry 1

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.

rydman · 11-18-2013, 10:38 AM

Quote:

Originally Posted by unSpawn

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

unSpawn · 11-25-2013, 12:12 PM

Quote:

Originally Posted by rydman

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.

rydman · 01-14-2014, 01:45 AM

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!