I accidentally formatted one of my drives and I'm hoping that I can recover a major part of my file system as I 'only' did a quick format.

After installing a second identical hard drive, I quick formatted the wrong drive by accident via Ubuntu's (14.04) Disks-Application. The drive was in ext4-format before and I did the quick format to ext4 again. There was only a single partition on the drive. Just a few seconds after the damage had been done, I unmounted the drive to avoid accidental writes.

The files I am after are in binary format (with no extensions as far as I am aware such as .npy .t7 .mat), some are .txt files.

Reading through forums and blogs, I understood that Testdisk+Photorec might be able help recover the lost partition. I gave Photorec a quick try but since most of the important files are binary and have no file signature I ended up having thousands of useless .txt files and non-readable .mat files. Testdisk on the other hand, displays inconclusive prompts as far as I understand. I did not yet attempt to perform a deep scan, as I expect the information to be at the very beginning of the drive (the drive is 8TB). See the following Testdisk snapshots for more info:

Partition selection screen

Advanced menu after selecting None as partition type

  • Selecting EFI-GPT or Intel as partition type results in Testdisk telling me that there are no partitions available.

Analysis of the drive (after selecting None-type) results in the partition that is empty (except for an empty lost+found). In contrast, analyzing the drive after selecting the GPT-type results in many identical entries of this type: ext4 0 0 1 972801 80 63 156280533168


superblock 0, blocksize=4096
superblock 32768, blocksize=4096
superblock 98304, blocksize=4096
superblock 163840, blocksize=4096
superblock 229376, blocksize=4096
superblock 294912, blocksize=4096
superblock 819200, blocksize=4096
superblock 884736, blocksize=4096
superblock 1605632, blocksize=4096
superblock 2654208, blocksize=4096


  1. What does Ubuntu do specifically to the drive when selecting quick format? Can we infer from that whether it is (im)possible to recover the file system at all?

  2. Can I recover parts of the structure using Superblocks? Somewhere I read that a backup superblock is written at position 1024. Is that recoverable or has that been cleared via quick format as well?

  3. What options except file recoveries like Photorec or Scalpel remain for me to recover my file system? I know the full paths of some of the most important files I want to recover.

  • Partition Table Type might/should be Intel, try it with that option :) – FatalMerlin Jan 18 '17 at 14:17
  • I am unsure, but you might me able do "format" / declare the drive as ext4 with fdisk again and the files might be back (depending on what you formatted to) – FatalMerlin Jan 18 '17 at 14:18
  • Selecting, Intel as type does result in the same list of identical entries as when I would have chosen GPT, e.g.: Linux 0 0 1 972801 80 63 156280533168. – Max Jan 18 '17 at 14:24
  • I formatted from ext4 to ext4. So that resolves that :) – Max Jan 18 '17 at 14:25
  • Well, then get some coffee, order a pizza and start the deep search (only the last step ist mandatory for this instruction set). – FatalMerlin Jan 18 '17 at 14:29

I was successfully able to recover all my files using a backup Superblock! After TestDisk was not able to help me, I tried an approach from a related question. For the sake of clarity, here the steps I took to recover my file structure:

  1. Make sure your drive is unmounted.
  2. Find out your backup Superblocks via

    dumpe2fs /dev/<drive-id> | grep -i superblock

    e.g. dumpe2fs /dev/sdb | grep -i superblock

  3. Check the file system based on one of the Superblocks but do not apply any changes yet to see whether this particular Superblock is structurally intact.

    fsck.ext4 -v -n -C 0 -b <Superblock> /dev/<drive-id>

    e.g. fsck.ext4 -v -n -C 0 -b 2654208 /dev/sdb

    -v makes the command verbose to show more details, -n makes sure no attempts to fix the file system are made by always answering 'no' to each prompt, -C 0 displays a progress bar and -b defines the starting position of a Superblock given by the previous step.

  4. If a suitable Superblock has been found, let fsck.ext4 fix your file system by replacing the -n with -y to accept all fixes automatically.

    fsck.ext4 -v -y -C 0 -b <Superblock> /dev/<drive-id>

  5. Reboot and mount the drive.

In my case, the first level of directory names could not be recovered. Thus they could all be found based on their inode name in the lost+found directory, which is hidden.

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.