On my personal home computer running Kubuntu Linux 13.04 I'm having trouble mounting a partition that is very dear to me. My backup policy is to perform a backup about monthly, so I do have a backup from August :). Is there any way to recover the personal files that are on this drive?

The drive is a 1.5 year old 1000 GiB Western Digital Green drive, with home mounted on /dev/sdc2, the filesystem root on /dev/sdc6, and media files on /dev/sdc3. Therefore of course sdc2 would be the one to go! So far as I know there were no power outages or other such events during the life of the drive. I managed to get this information by running a Kubuntu LiveCD:

kubuntu@kubuntu:~$ sudo fdisk -l

Disk /dev/sdc: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes                                                                                                                                                                                                       Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00008044

  Device Boot      Start         End      Blocks   Id  System
/dev/sdc1   *        4094    88066047    44030977    5  Extended
/dev/sdc2        88066048  1419266047   665600000   83  Linux
/dev/sdc3      1419266048  1953523711   267128832   83  Linux
/dev/sdc5            4096     6146047     3070976   82  Linux swap / Solaris
/dev/sdc6         6148096    47106047    20478976   83  Linux
/dev/sdc7        47108096    88066047    20478976   83  Linux

kubuntu@kubuntu:~$ sudo mount -t ext4 /dev/sdc2 c1
mount: wrong fs type, bad option, bad superblock on /dev/sdc2,
  missing codepage or helper program, or other error
  In some cases useful info is found in syslog - try
  dmesg | tail  or so

  kubuntu@kubuntu:~$ sudo debugfs -c /dev/sdc2 
debugfs 1.42.5 (29-Jul-2012)

/dev/sdc2: Attempt to read block from filesystem resulted in short read while opening filesystem
debugfs:  quit

kubuntu@kubuntu:~$ sudo fsck /dev/sdc2
fsck from util-linux 2.20.1
e2fsck 1.42.5 (29-Jul-2012)
fsck.ext4: Attempt to read block from filesystem resulted in short read while trying to open /dev/sdc2
Could this be a zero-length partition?

kubuntu@kubuntu:~$ sudo fsck.ext4 -v /dev/sdc2
e2fsck 1.42.5 (29-Jul-2012)
    fsck.ext4: Attempt to read block from filesystem resulted in short read while trying to open /dev/sdc2
Could this be a zero-length partition?

kubuntu@kubuntu:~$ dmesg | tail
[ 2684.532855] Descriptor sense data with sense descriptors (in hex):
[ 2684.532858]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 2684.532876]         05 3f c8 b0 
[ 2684.532885] sd 5:0:0:0: [sdc]  
[ 2684.532893] Add. Sense: Unrecovered read error - auto reallocate failed
[ 2684.532898] sd 5:0:0:0: [sdc] CDB: 
[ 2684.532902] Read(10): 28 00 05 3f c8 b0 00 00 08 00
[ 2684.532917] end_request: I/O error, dev sdc, sector 88066224
[ 2684.532927] Buffer I/O error on device sdc2, logical block 22
[ 2684.532973] ata6: EH complete

Help me Unix & Linux, you're our only hope.

  • Can you mount the other (non-home) partitions? – Timo Feb 9 '14 at 20:24
  • Yes, all the other partitions can be mounted successfully. – dotancohen Feb 9 '14 at 20:24
  • @Timo I stand corrected, you're quite right, they're just not listed in order so I missed it. Comment deleted. – terdon Feb 9 '14 at 20:40

There might still be hope, but your drive seems to have hardware problems (my interpretation of the read error in dmesg output).

You should try to make a copy of what is recoverable from that partition onto another drive (to minimize disc access). Use ddrescue for that, it might take a while but gets most if not all of the recoverable data of the partition.

If possible start from another disc, from a Live CD, or connect the drive to a different computer that has its own Linux to boot from. The reason I would do so is that the read errors while doing ddrescue probably has an impact on the disc access speed on the other partitions.

Once you have that copy, lets call that the original copy, as file on another disc, make a copy of that copy. Then try to do a filesystem check on that copy. If that recovery scrambles the copy, you can start from the original copy and try once more, something else.

  • Thank you, I'm now cloning the partition with ddrescue to another physical drive. – dotancohen Feb 9 '14 at 21:23
  • Thank you. I was able to copy the disk with ddrescue and recover most of the files with e2fsck. The funny thing is that most of the unrecovered files were the newest files, for which I did not have a backup. I wonder if that is intrinsic to ext4. – dotancohen Feb 10 '14 at 9:13
  • @dotancohen I am glad you got at least some back. Would not call it funny though that you missed the most recent ones. I have too little knowledge about journaling filesystems to explain why that is. Why don't you put it up as a new question, or can I do that if you don't want to? – Timo Feb 10 '14 at 9:16
  • Yes, funny is not the right word, but that is my way of grieving! I will ask the new question as I am also interested. Thank you Timo! – dotancohen Feb 10 '14 at 9:18
  • Thank you, I asked here. – dotancohen Feb 10 '14 at 9:26

(I know this is an old question, I came across this problem myself and got my FS back to life without ddrescue, so I'll share the expericence for anyone else encountering this)

Ext filesystems store backups of the superblock -- for an occasion just like this one.

First, determine the locations of the backups (make sure you have the -n option! otherwise this will wipe the file system with a new one):

mke2fs -n /dev/sdxx

This is a test run (i.e. no write) of FS creation routine. It will let you know the offsets of where it would put superblock backups if it were creating a filesystem. If you know your FS block size to be something other than 4096, you must also specify the parameter -b {blocksize} to get the right numbers.

For 4096-sized blocks, first backup superblock will be at 32768. If the following operations fail with the same error message about bad superblock/short read, try the next superblock backup from the list mke2fs gave you.

Next, you can either mount the filesystem using the backup superblock like this

mount -o sb=32768 /dev/sdxx /mnt/sdxx

then explore the FS from your file manager, copy undamaged files etc.

Or, to actually fix the FS, you can run fsck with backup superblock like this

e2fsck -fy -b 32768 /dev/sdxx

Here -f makes it scan the disk even if it's not dirty and -y answers yes to all enquiries about fixing stuff. The -b option, aside from specifying the backup superblock, will make it update the original superblock with info from backup.

After this, you should have your filesystem back.

If e2fsck fails to write the main superblock If the superblock got corrupted because it's on a bad sector e2fsck will finish the run, attempt to update the superblock, and give you the following error message:

Error writing block 1 (Attempt to write block from filesystem resulted in short write)

Obviously, the main superblock isn't updated and the whole e2fsck run is in vain.

You need to hint the disk to remap that sector -- by writing zeroes to it. Thanks to @Keith for pointing this out: the next command can make a lot of mess if mistyped, so triple-check it before running. Here's the magic:

dd if=/dev/zero of=/dev/sdxx bs=4096 count=1 seek=0

This will write 1 4096-sized block of zeroes to sdxx at offset 0. Don't forget to account for different block size if that's the case for you.

After that you'll be able to write to superblock (which will be on a different physical sector transparently to you). Now, you run the e2fsck command above again and it should succeed writing the superblock allowing you to mount the FS normally.

Goes without saying Now you should backup the critical data to another physical drive and, if you still plan on using the filesystem, run

e2fsck -fccy /dev/sdxx

PS Kudos to @Nemo on this find: in case all of the backups of the superblock of your FS are corrupted, mke2fs/mkfs has the -S option that will re-create the superblock and group descriptors as if creating a new filesystem, without touching anything else. But you absolutely have to be sure your blocksize is right and the man page says you should run e2fsck after it and there are no guarantees about data being left for rescuing. Read the man page and throw a plus on this answer.

  • Thank you Ivan. I will give this a try, as I still have the old drive. – dotancohen Apr 1 '15 at 10:12
  • @dotancohen - I dunno... did you ever verify that the drive was definitely bad? I had some iffy stuff happen on a 3tb Green and I gave it up for lost for nearly a year - two years ago. It was just a filesystem problem which I corrected - and got all of my data. If you want to backup/replace superblocks use wipefs - you have it installed already and it is a linux tool designed for this purpose See its man page. About the disk - to verify whether it is physically bad use smartctl - you might have to install it. – mikeserv Apr 1 '15 at 10:27
  • 1
    @dotancohen - if you've never used it before it's going to look bad, probably. But it really isn't. It was only after I read this wikipedia article thoroughly that I realized my disk well within normal operating limits. But the categories are all named awful things and the column headings are the same with a bunch of cryptic numbers interspersed. Just compare your report closely with the data in the table there and be sure you understand where each failure threshhold is before junking it. – mikeserv Apr 1 '15 at 12:05
  • 1
    @Keith [wow I'm a year late] Nope, that won't wipe the disk, only the superblock on it. But yeah, you're right, I'll add a warning as if mistyped this command can obviously cause a lot of trouble. – Ivan Bartsov Dec 1 '17 at 18:16
  • 1
    @Nemo Thanks, didn't notice the -S thing before, good to know :) I'll put a link to that in the answer. – Ivan Bartsov Dec 1 '17 at 18:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.