1

I just deleted (accidentally) my second disk with dd if=/dev/zero of=/dev/sdb1. I noticed the wrong letter after 10 seconds, and 2GB of a 990GB partition were deleted (total disk space is 1TB). After realizing what I had done, I tried remounting it, without success. I ran a quick fsck before disconnecting the disk, and this is what I found:

fsck -y /dev/sdb
fsck from util-linux 2.29.1
e2fsck 1.43.4 (31-Jan-2017)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/sdb

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
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>
 or
    e2fsck -b 32768 <device>

Found a dos partition table in /dev/sdb

Of course neither e2fsck command works. Is there any way I can recover the disk, or should I buy another one and try to rescue the data?

1
  • backup superblocks are at 2^15 * 3^x * 5^y * 7^z (for x,y,z integers)
    – user313114
    Jun 7, 2017 at 4:54

1 Answer 1

2

(I note you ran the fsck command on the wrong disk - /dev/sdb, rather than /dev/sdb1 - so you might want some sleep/coffee and another set of eyes before doing anything further.)

The appropriate step to take at this point is to do a bit copy of the drive (using dd or ddrescue), and then use data recovery tools to see what you can get of a copy of the drive. Everything I do would be on the copy drive, in case I stuff up. There is risk of making things worse.

I would try and recover the data as follows:

  1. Find an alternate superblock by using mke2fs -n /dev/sdb1 - say yes to the prompt and record the numbers it gives you for alternative superblocks.
  2. fsck.ext4 -y -b XXXXX /dev/sdb1 (where XXXXX is the last superblock number from above).

  3. Mount the resulting system and get the data you can.

If this fails, try using testdisk and/or photorec to salvage what little you can.

7
  • I note that I have only done this once - as a result of this question - using a file as a block device - it appeared to work, but YMMV, Also, of-course the data in the first blocks is gone - if you are lucky that will be OS related.
    – davidgo
    Jun 7, 2017 at 5:11
  • After connecting the disk again, I only see the device, not any partitions. It shows up as /dev/sda (even if its the first device detected, this is my backup disk, it was 1 TB of data only, no OS files. I tried running mke2fs on the device and it showed: mke2fs -n /dev/sda mke2fs 1.43.4 (31-Jan-2017) Found a dos partition table in /dev/sda Proceed anyway? (y,N) y Creating filesystem with 244190646 4k blocks and 61054976 inodes Filesystem UUID: 37db2321-935a-4654-824f-20549ca82554 Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, ...
    – user134167
    Jun 7, 2017 at 22:45
  • After that, I ran fsck.ext4, to get the output: fsck.ext4 -y -b 214990848 /dev/sda e2fsck 1.43.4 (31-Jan-2017) fsck.ext4: Invalid argument while trying to open /dev/sda The superblock could not be read or does not describe a valid ext2/ext3/ext4 filesystem. If the device is valid and it really contains an ext2/ext3/ext4 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> or e2fsck -b 32768 <device> Is fsck.ext4 supposed to work on ntfs disks?
    – user134167
    Jun 7, 2017 at 22:46
  • Sorry to say, but you may have made/be making things worse by not working on a copy of the disk. My guess is you did the dd on /dev/sdb rather then /dev/sdb1 theby knocking out the partition information. I'd try cloning the disk, then on the clone see if testdisk can find partition information, write that out and then try the steps above, failing which I would blindly try and create a partition for the full disk - I would try using fdisk, and then again fdisk -c=dos if recovery fails. If that fails, I'd resort to using photorec to try and pull whatever meaningful fragments I could.
    – davidgo
    Jun 7, 2017 at 23:23
  • If your disk is NTFS, then running commands for an EXT filesystem won't help. (I can't be of much help either as I am not expert with NTFS. Indeed if it is NTFS you should probably be using Windows recovery tools and methods)
    – davidgo
    Jun 7, 2017 at 23:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .