Lvm luks partition recover
Hi there, this is my first post in this community and I hope to find any solution to my problem. In short, I'm not able to rescue/recover or mount my /home directory. What happend, I've installed Wheezy beta 2 if I'm not wrong a couple of months before it become stable, everything worked fine since now. My pc is equiped with a hybrid hdd 500gb + 32Gb ssd. When installed I decided to use encrypted LVM for the whole disk (hdd+ssd) and placed root+boot in the 32Gb ssd disk (/sda) and /home+swap in the 500Gb hard drive (/sdb). Everything has worked perfectly till 2 weeks ago when, while running on battery, the pc hybernate itself after some of inactivity time (this wasn't the first time and everytime I was able to start the pc, enter the passphrase and became running again with the previous session). This wasn't happend last time... after bios post (AHCI configured) I see a simple white cursor blinking on the top left corner. I tryed to remove battery and remove ram just to be sure it wasn't a "suspend on ram" issue but nothing. Running the live Wheezy (7.2) from dvd revealed many strange things (at last for me since I am noob on linux). I'm able to mount the lvm volume and read (whithout passphrase!) both Root and Boot partitions, so far I was happy but the whole 500Gb hard drive is shown as UNALLOCATED meaning that I cannot access any data inside it. I wasn't able to mount it in any way. After googling a while and tried some solutions I finally decided to ask your help. I really need to recover that data...
I found on this community two very similar issues (1st & 2nd) but to be honest I was not able so far to follow/test them since I am quite new on Linux and I'm afraid to lose everything if I follow my mind... Steps taken so far following google and suggestions out there: Code:
# fdisk -l /dev/sd? Code:
# blkid Code:
root@debian:~# cryptsetup luksOpen /dev/sda my500 Code:
root@debian:~# sfdisk -d /dev/sda Code:
Tue Dec 3 13:14:57 2013 Thanks in advance |
Apparently the root and boot partitions were not encrypted since you were able to read them without a password. The results from testdisk are inconsistent with everything on sdb being encrypted. I'm seeing what look like 2 LUKS partitions (16GB and 280GB), an unencrypted ext4 partition (32GB), and about 160GB of unallocated space. The good news is that with access to the root partition you should be able to look in /etc/lvm/backup and find files there that detail the LVM layout on sdb. If you would post the relevant file (as an attachment if you can -- your low post count might not permit that), that information would help confirm the correct partitioning of sdb.
FYI, testdisk always reports the size of LUKS partitions as just the size of the LUKS header plus key material since it has no way to determine the size of the payload. |
Quote:
Here is the content of sda Code:
# # Generated by LVM2 version 2.02.95(2) (2012-03-06): Mon Oct 14 23:57:20 2013 Thanks again. |
Excellent! That is showing a single physical volume using essentially the entire disk, so there must in fact be just one encrypted partition. I would guess that the encrypted partition had never been filled with random data, and the other stuff that testdisk found was just left over from previous use of the drive.
For safety, you should save at least the first 10 megabytes or so of the drive on a file, perhaps on your old root partition: Code:
mkdir -p /mnt/oldroot Then I would use fdisk to first delete the existing partitions, write out that empty partition table, and then run fdisk again in sector units mode (a recent version should default to that -- use the "u" command if yours does not) to create a single partition starting at sector 2048 (should be the default) and extending to the end of the disk (again, should be the default). You are affecting only the partition table and not messing with any extended partition, so this operation should be safe. Just be absolutely certain that you run fdisk on the whole drive, "fdisk /dev/sdb", and not on a partiton (/dev/sdb1). Do not use parted, gparted, or any other higher-level partitioning tool. Those will want to format the partition for you, and that would be fatal. You should then be able to unlock the encrypted partition and then access the LVM logical volumes within. You might need to run pvscan to pick up the LVM structure, though that might happen automatically when you unlock the partition. The reason for running fdisk twice is so that the the partition creation will be from a clean start and not picking up any bogus geometry from the current partition table. |
:banghead::banghead::banghead::banghead::banghead:
I followed everything carefully but there must be something wrong with the results... Everything gone fine, I was able then to enter the passphrase both using cryptsetup luksOpen and from the GUI (Caja and gnome-disk-utility) anyway I'm not able to mount the filesystem, Mate fm said "the unlocked device does not have a recognizable file system". Here are commands I issued and the results... please help me :( Code:
lmdemate64 naguera # fdisk -l /dev/sdb Code:
lmdemate64 naguera # cryptsetup luksOpen /dev/sdb1 restore |
I finally was able to enter the data partition :)... I'm so happy that I don't know how to explain :)...
Anyway, I got it work simply looking better into gnome-disk-utility, on the left menu, by default, I see "Devices" where usually I go when I have to do something like open a disk, mount or encrypt a volume (and format etc.), what I mess was above "Devices", I found another item I never noted before (noob) saying "Multi-Disk Devices" and immediately below "DATA - Logical Volume LVM2" and finally was there where I was able to mount definetively my lost lucks lvm partition LOL... I think I miss something at command line after cryptosetup luksOpen... don't really know, I have to study more.. I would like to say a BIG THANK YOU to rknichols, infact, without his help I would still be crying. Anyway, I would be very happy to know exactly what I should have had to do into command line to have the same results of the GUI... |
Quote:
Your original volume groups and logical volumes should now be available. See what "lvs" reports. Here is an example (your names will be different): Code:
# lvs Code:
# blkid /dev/oldtapes/* Code:
# fsck -n -f /dev/oldtapes/lvol0 |
You was probably replying to my second-last post when I posted the latest btw I'm currently backing up data into a safe place (390Gb of family and corporate data), then I will try absolutely the command lvm and the mount again just to be sure to learn what you have just teached me... Thanks again, your help was really appreciate.
PS. I like very much your signature and so I just copied-paste into my Skype status... It is true, I'm backing up on daily basis at least 10TB of corporate data (I'm an IT man working on MS environment), but most of the time you realize the importance of things only after you've lost, this does not justify what I have failed to do, but from now on I'll stay definitely much more careful! :) |
With encryption in particular, it is very easy for a single mistake or glitch to result in permanent and unrecoverable loss of all data. Besides backup, I recommend looking at the "luksHeaderBackup" function of the cryptsetup command. Don't be too concerned about the warning about protecting this file. Remember that anyone who has ever had access to the physical encrypted device has also had an opportunity to copy that header.
|
All times are GMT -5. The time now is 12:39 PM. |