LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - General
User Name
Password
Linux - General This Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.

Notices


Reply
  Search this Thread
Old 12-19-2015, 07:38 PM   #1
nr765
LQ Newbie
 
Registered: Dec 2015
Posts: 1

Rep: Reputation: Disabled
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
, I input password, this then creates /dev/mapper/backup (and also /dev/dm-0)

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
So the hdd is now inaccessible, I get the following when trying to mount it
Code:
mount: wrong fs type, bad option, bad superblock on /dev/mapper/backup,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.
fdisk -l /dev/mapper/backup

Code:
Disk /dev/mapper/backup: 2 MiB, 2097152 bytes, 4096 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x0a60a5a1

fdisk -l /dev/sdb1
Code:
Disk /dev/sdb1: 2 MiB, 2097152 bytes, 4096 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
fdisk -l /dev/sdb
Code:
Disk /dev/sdb: 1.8 TiB, 2000365289472 bytes, 3906963456 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x77e8a5da

Device     Boot Start   End Sectors Size Id Type
/dev/sdb1  *     2048  6143    4096   2M 83 Linux
dumpe2fs /dev/sdb1
Code:
dumpe2fs 1.42.12 (29-Aug-2014)
dumpe2fs: Bad magic number in super-block while trying to open /dev/sdb1
Couldn't find valid filesystem superblock.
photorec and testdisk don't help much since they scan the partition very quickly and don't find anything.

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
 
Old 12-20-2015, 12:19 PM   #2
unSpawn
Moderator
 
Registered: May 2001
Posts: 29,415
Blog Entries: 55

Rep: Reputation: 3594Reputation: 3594Reputation: 3594Reputation: 3594Reputation: 3594Reputation: 3594Reputation: 3594Reputation: 3594Reputation: 3594Reputation: 3594Reputation: 3594
Quote:
Originally Posted by nr765 View Post
Hello,
Welcome to LQ, hope you enjoy it, sad to see it is on such an occasion.


Quote:
Originally Posted by nr765 View Post
Have the encryption been damaged?
Yes.


Quote:
Originally Posted by nr765 View Post
Would there be a way to create a new partition table?
A partition table is only a static list of addresses, partition boundaries, and changing it doesn't affect the actual contents of the partition. You overwrote the disks partition table and one or more partitions with other data. The original data is lost.
 
Old 12-20-2015, 02:05 PM   #3
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 4,542

Rep: Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081
Quote:
Originally Posted by nr765 View Post
fdisk -l /dev/sdb
Code:
Disk /dev/sdb: 1.8 TiB, 2000365289472 bytes, 3906963456 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x77e8a5da

Device     Boot Start   End Sectors Size Id Type
/dev/sdb1  *     2048  6143    4096   2M 83 Linux
That looks like you overwrite the first 3MB (2048+4096 sectors) of sdb. Fortunately you are not using LUKS, so there is no issue with an overwritten LUKS header, which would be unrecoverable. Most of your filesystem should be OK, but you first need to find the correct starting point so that it will decrypt correctly.

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.)

Last edited by rknichols; 12-20-2015 at 02:21 PM. Reason: Fix typo in "2048+4096"
 
Old 12-20-2015, 07:46 PM   #4
syg00
LQ Veteran
 
Registered: Aug 2003
Location: Australia
Distribution: Lots ...
Posts: 19,621

Rep: Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530
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.
 
Old 12-20-2015, 09:07 PM   #5
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 4,542

Rep: Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081
Quote:
Originally Posted by syg00 View Post
The dd was done to /dev/sdb1 (mapped as dm-0), so 2048 certainly looks the correct spot.
Something is very strange, then, because that would not have touched the partition table. That would mean that the whole 2 TB disk had just a single 2 MiB encrypted partition on it. That's just not believable. Something else went on beyond what has been reported thus far.
 
Old 12-20-2015, 09:41 PM   #6
syg00
LQ Veteran
 
Registered: Aug 2003
Location: Australia
Distribution: Lots ...
Posts: 19,621

Rep: Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530
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.
 
Old 12-21-2015, 08:25 AM   #7
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 4,542

Rep: Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081
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.
 
Old 12-21-2015, 11:29 PM   #8
syg00
LQ Veteran
 
Registered: Aug 2003
Location: Australia
Distribution: Lots ...
Posts: 19,621

Rep: Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530Reputation: 3530
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.
 
Old 12-22-2015, 09:16 AM   #9
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 4,542

Rep: Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081Reputation: 2081
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] recover from deleted luks encryption partition unixedway Linux - General 12 01-16-2017 06:33 AM
[SOLVED] Lvm luks partition recover naguera Linux - Hardware 8 12-06-2013 09:31 AM
recover lost luks partition ehsdav Linux - General 10 07-09-2013 04:50 AM
Recover encrypted LUKS partition itinlopez Linux - General 3 11-30-2008 02:20 AM
recover FAT partition of external HD lbdgwgt Linux - Hardware 1 09-10-2007 07:24 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - General

All times are GMT -5. The time now is 03:20 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration