dd'ed on an external HDD Luks partition, recover possible?
Hello,
So.. I guess it had to happen one day. I have a 2TB external hard drive with a single encrypted partition (ext4). It's generally on /dev/sdb. I mount it with Code:
cryptsetup create backup /dev/sdb1 At the same I was creating a Pi sd-card (Raspbian, 1.5Go) ... I though it was /dev/dm-0). So I did a Code:
dd bs=4M if=2015-11-21-raspbian-jessie.img of=/dev/dm-0 Code:
mount: wrong fs type, bad option, bad superblock on /dev/mapper/backup, Code:
Disk /dev/mapper/backup: 2 MiB, 2097152 bytes, 4096 sectors fdisk -l /dev/sdb1 Code:
Disk /dev/sdb1: 2 MiB, 2097152 bytes, 4096 sectors Code:
Disk /dev/sdb: 1.8 TiB, 2000365289472 bytes, 3906963456 sectors Code:
dumpe2fs 1.42.12 (29-Aug-2014) Have the encryption been damaged? Would there be a way to create a new partition table? since I know what it's supposed to be (single partition ext4)? Thanks, Nr |
Quote:
Quote:
Quote:
|
Quote:
If your partition was created with fairly recent tools it probably begins at sector 2048, so I would first try setting up partiton 1 to start at sector 2048 and extend to the end of the disk. Then, unlock the encryption and see if fsck can find a backup superblock in /dev/mapper backup. Note: I strongly recommend you save a complete image of the disk before you let fsck actually fix anything. It's entirely possible for those "fixes" to make a bad situation unrecoverably worse. (Playing around with the partition table for primary partitions (or GPT partitions, for that matter) is entirely safe.) |
The dd was done to /dev/sdb1 (mapped as dm-0), so 2048 certainly looks the correct spot.
Maybe try dumpe2fs with -o rather than fsck to see if there are any valid backup superblocks. |
Quote:
|
Given that the dm-crypt volume was open and active, maybe dm-crypt recognised a close event when the dd finished and truncated the volume.
Guess-work of course. |
dm-crypt does not adjust partition tables and does not even attempt to track the size of the encrypted volume. Attempts to read/write/seek past the end of the underlying volume result in the same I/O error you would get with a non-encrypted volume.
|
You are correct.
I just tested this scenario. The dd completes fine, even with the dm-crypt volume open. umount/mount shows the iso copied, not the original filesystem. But parted shows the partition as its initial (correct) size as you suggested. I eventually found a backup superblock I could use, but using it with fsck trashed everything. I <ctrl>-<c>'d it after a while, and the next mount found "too many file systems". Didn't bother with testdisk as I didn't have much data on the initial filesystem - for me this is broken beyond repair. I would recommend the OP only use something like photorec/testdisk, and not attempt a fsck. |
That 2015-11-21-raspbian-jessie.img file is only about 3.9GB, so most of the data on that 2TB drive is intact and probably worth saving. It's still an issue of finding the right starting point for the encrypted volume so that correct sector IVs will be calculated, and just an ordinary recovery issue after that. The root directory is almost certainly trashed, so everything will end up in lost+found after an fsck, but with luck, most of the subdirectories will be intact and still contain original file names.
As I said before, a full backup of the image is strongly recommended before recovery efforts. |
All times are GMT -5. The time now is 06:14 PM. |