I've been at this for days now, so I'm hoping you can help me!

Original setup: This is a 200GB firewire drive, originally formatted via Ubuntu 11.04 Disk Manager with a Master Boot Record, and a single Ext4 partition. The partition was encrypted via Disk Manager option "encrypt underlying file structure".

The unencrypted partition originally contained a number of text files, and 2 63GB Truecrypt File Containers which originally resided on 64GB USB sticks.

Accidental Format: A familiar story, I had another external with a similar setup and was planning on formatting one and using it as a backup for the original drive, which of course had no backup at the time.

  • In Disk Manager, I had the original drive partition unlocked and not mounted. I selected the underlying partition via GUI and clicked "Format Partition" as Ext4, no encryption.

Once I realized what was happening, I ripped the cable out and immediately made a copy with dd and am now working off that.

Status: Since I didn't mess with the front of the drive, the LUKS header and MBR are still original and intact and the partition is unlockable via Ubuntu popup dialog or command line. The unencrypted partition itself still has the same geometry, but since it received a partial format, the file system is presumably (partially?) jacked.

  • The new partition won't mount, and fsck returns `wrong fs type', bad superblock, etc.

  • If I boot into Ubuntu and plug in the drive without unlocking, /dev/mapper has a mapping with the UUID of the device (I'd copy it in here but I'm currently booted into Hiren's). I've noticed from plugging in other encrypted drives, they are mapped here by UUID on unlock, so I assume this is because the copy was made with dd with the partition still unlocked?

  • If I boot into Hiren's BootCD, and navigate to /dev/mapper, the above mapping isn't shown (I assume this is due to how Ubuntu handles encrypted drives). I can unlock via cryptsetup luksOpen and successfully map the device here tho.

  • fsck/e2fsck can't find a valid superblock on the mapped device on either Ubuntu or Hiren's, I've also tried every possible backup superblock to no avail.

  • TestDisk finds a series of junk partitions with weird sizes and filesystems which never existed on the drive. I'm assuming this is due to collisions when it scans across the TrueCrypt File Containers. As I understand it though, TestDisk is primarily for recovering partition tables, not file systems, yes?

  • PhotoRec only returns 3 junk files, as well as being useless for recovering the TrueCrypt File Containers since they are encrypted from the first bit to the last.

  • A hexdump -C on the mapped device shows 0's until line 00020000. (Does Ubuntu zero-out data on format by default??? If this is the case, I know I'm totally hopeless here.) Update: I'm guessing t his is where the file system is stored at, isn't it?

Question: I have a pretty low understanding of *nix command-line and low-level data storage, but have been learning a lot this week as I've been working on this. Since the format didn't complete, I have a hard time believing ALL the original superblocks are gone. The text files are expendible (they were essentially archived emails), but I'd very much like to have those TrueCrypt File Containers back. Unfortunately, I know this is maybe a slim chance because they're gigantic encrypted files inside encryption.

I've seen mke2fs -S suggested and am going to try that after I finish making a fresh copy of the bad drive. Is there any hope? Am I taking a wrong approach to this? :(

This data represented months of work, and is usually backed up, it only had no backup for the one day because I'm poor and was moving data around my hard drives trying to consolidate space. I figure if it took me that long to create it, it's worth spending a few weeks trying to get back, so I'm open to any amount of insane suggestions (like, couldn't I theoretically make a hexdump of the whole partition and recreate these 63GB files from that?).

Thanks in advance! :)


I have run mke2fs -S -t ext4 /dev/mapper/sdb1crypt (forgot to copy the results, going to try it again, so I will post it then) followed by e2fsck -y /dev/mapper/sdb1crypt which took about 10 hours to finish. On reboot, I found about 400,000 random files in lost+found folder. That can't be right, can it?

Update 2:

I've restored the backup to the accidentally-formatted state, and just for the hell of it, tried to grep the mapped device to see if it could find some file extensions I knew should be on it that aren't the TrueCrypt File Containers I'm looking for, and it picked these up immediately.

# grep -R "txt" /dev/mapper/sdc1_crypt
Binary file /dev/mapper/sdc1_crypt matches
# grep -R "psd" /dev/mapper/sdc1_crypt
Binary file /dev/mapper/sdc1_crypt matches
# grep -R "ai" /dev/mapper/sdc1_crypt
Binary file /dev/mapper/sdc1_crypt matches
# grep -R "eps" /dev/mapper/sdc1_crypt
Binary file /dev/mapper/sdc1_crypt matches

I also ran # grep -R "HALsGoneBad" /dev/mapper/sdc1_crypt, because I know I have no files named that and it's still searching (been like 10min).

What is grep finding, here? Does this mean my file system is partially intact somewhere? Gah! I feel like I'm so close!

I don't know how inode tables work, but I wonder, can I possibly peruse the inode table somehow and just look for one that references a 63GB file?

  • Even if formatting zeroed out the first 128k, doing so to the underlying disk should cause the first 128k of the encrypted volume to appear to be full of random data. Are you sure you formatted the raw disk not the encrypted volume? Which backup superblocks have you tried? If the first 128k is zeros you will certainly need to pick one above that. – psusi Oct 7 '13 at 1:29
  • Hi, thanks for the quick reply! Yes, I'm certain I formatted only the underlying filesystem, I tried to replicate the conditions, and if a device holds encrypted partitions AND they are unlocked, you can only work with the unlocked partitions or it will not let you proceed. I've tried superblocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872 which returns, The superblock could not be read or does not describe a correct ext2 filesystem. – ridgek Oct 7 '13 at 2:01

Your Answer

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

Browse other questions tagged or ask your own question.