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
fsckreturns `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
ddwith 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 luksOpenand successfully map the device here tho.
e2fsckcan'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.
hexdump -Con 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.
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?
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).
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?