Wrong partition size

English Hardware
1

Hello everbody,

my home server has 2x2TB Hard Disks installed. This two Hard Disk are both crypted with crypsetup LUKS Format.

So, I changed the hardware of my server a little bit and I don’t know what went wrong, but one of the two HDDs now has a “damaged” partition. The partition has now only a size of 2048KB instead of 1.67TB. The other space now is marked as “not allocated”. Well, I thought to myself “just redo this with testdisk” but this doesn’t seem to work.
Testdisk doesn’t find any other partition which would make sense.

So, is it possible just to append the free space to this partition again without losing any data?

Regards
ReCon

2

On 2014-06-30 23:26, linuxrecon wrote:
>
> Hello everbody,
>
> my home server has 2x2TB Hard Disks installed. This two Hard Disk are
> both crypted with crypsetup LUKS Format.
>
> So, I changed the hardware of my server a little bit and I don’t know
> what went wrong, but one of the two HDDs now has a “damaged” partition.
> The partition has now only a size of 2048KB instead of 1.67TB. The other
> space now is marked as “not allocated”. Well, I thought to myself “just
> redo this with testdisk” but this doesn’t seem to work.
> Testdisk doesn’t find any other partition which would make sense.

being encrypted, testdisk probably can not even look inside, and the
outside does not make sense.

We need more info. What exactly— sorry, I’m terribly tired, I’ll try
to suggest tomorrow. Ping if I forget.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

3

Well, pictures say more than words so:

This is, what gparted is saying. As I said, the unallocated part at the end should go to sdb5, which is actually only 2048KB in size.

https://dl.dropboxusercontent.com/u/6205092/1-gparted.png

And this is what TestDisk is saying. Before that I was able to open sdb5 with cryptsetup.

https://dl.dropboxusercontent.com/u/6205092/2-testdisk_overview.png

And the last thing I actually can provide is the overview of testdisk when I’m trying to go into the opened luks partition with testdisk:

https://dl.dropboxusercontent.com/u/6205092/3-testdisk_opened_crypt.png

After more than 3 days of testing and searching the web, it seems that this data is lost. I would be happy if I at least could access one of the two HDDs and recover whats possible to recover, but it seems that testdisk can’t handle LVM devices and there is no other tool to dive into broken LVM Volume Groups.

4

On 2014-07-01 08:56, linuxrecon wrote:
>
> Well, pictures say more than words so:
>
> This is, what gparted is saying. As I said, the unallocated part at the
> end should go to sdb5, which is actually only 2048KB in size.
>
> [image: https://dl.dropboxusercontent.com/u/6205092/1-gparted.png]

Ok, I see.

Well, this is “almost” typical for an LVM install. It is done first on a
small partition, to which you can later add other LVM spaces (sorry, I’m
not an LVM expert, so I’m not using the correct terminology).

What you have is:

  • A plain sdb5 partition.
  • On top of this, there is an encryption layer.
  • This layer is decrypted as “/dev/mapper/crypt/”
  • On top of “/dev/mapper/crypt/” there is an LVM layer (container, I think)
  • Inside of that LVM container you can create partitions. If you are
    not going to create partitions, IMHO you should not be using LVM.

To grow this, you’d have to grow sdb5, then grow the encrypted later -
and as far as I know, this is not possible.

You may create another partition, sdb6, encrypt it, and add the top to
the existing LVM. Don’t ask me how, as I said, I’m not an LVM expert.

I would erase sdb5 and create it again with the correct size.

> And this is what TestDisk is saying. Before that I was able to open sdb5
> with cryptsetup.

Testdisk can do nothing, because what it sees is encrypted, it looks as
random data, and it can find no structure.

> After more than 3 days of testing and searching the web, it seems that
> this data is lost. I would be happy if I at least could access one of
> the two HDDs and recover whats possible to recover, but it seems that
> testdisk can’t handle LVM devices and there is no other tool to dive
> into broken LVM Volume Groups.

There can be nothing inside the LVM, it has only 20 MB. You could try
to find out if there is something in the empty space beyond, what would
be sdb6.

You talk of two disks, but in sda I do not see anything similar. It is
impossible, sda is only about 150 GB, so it is impossible that it can
hold anything similar to what is in sdb, which is a disk of close to 2 TB.

I hope you have your data backed up elsewhere.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

5

Sorry, sda is just ja test disk, totally empty.

What I wanted to say: sdb is the one with the problem lvm partition. sdc is the one with the fine lvm partition.

I used the server for over a year or so with exact that combination. Two HDDs with LVM and encryption on top of it. Just changed hardware now and it seems that something terribly gone wrong. That must be the reason why in sdb5 the size is only 2048K. The “unallocated” GBs / sectors does actually contain data.

If I would delete the partition now everything is definitely lost, due to the fact that the whole LVM partition is encrypted … is there any way to just mount, for example, sdc5 without lvm to just get the data again?

6

On 2014-07-01 15:46, linuxrecon wrote:
>
> Sorry, sda is just ja test disk, totally empty.
>
> What I wanted to say: sdb is the one with the problem lvm partition. sdc
> is the one with the fine lvm partition.
>
> I used the server for over a year or so with exact that combination. Two
> HDDs with LVM and encryption on top of it. Just changed hardware now and
> it seems that something terribly gone wrong. That must be the reason why
> in sdb5 the size is only 2048K. The “unallocated” GBs / sectors does
> actually contain data.

Then, use data mining recovery tools on the empty space, such as
photorec. But notice that if the data was encrypted, they will find
nothing at all. If they did, encryption would be broken!

So, if sdb5 was at some time bigger, and you know the exact location,
exact to the start and end LBA numbers, you can reconstruct the
partition, and then try if cryptsetup can open it, manually. There is
just a small chance that a tool such as gpart can find that partition,
if it existed.

> If I would delete the partition now everything is definitely lost, due
> to the fact that the whole LVM partition is encrypted … is there any
> way to just mount, for example, sdc5 without lvm to just get the data
> again?

If you delete sdb5 you lose 2 MB of data, nothing more.

Of course you can look at the device without LVM: just look at
“/dev/mapper/crypt/”

It is impossible to try anything else unless you find out what exactly
you did with that hardware migration. At least from my side: I can only
make guesses, and I have already spent them.

My guess is simply that you created that sdb at the current 2 MB size,
and there never was more.

I’m sorry.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

7

I can say for 100% that this is not the fact but anyway, I understand what you’re trying to say.

Thanks for your help so far. I think I just go for my last backup now … it’s a little bit older but as you said, on encrypted devices it is nearly impossible to recover data … I think using the backup is the much more simpler way :slight_smile:

8

On 2014-07-01 17:36, linuxrecon wrote:
>
> robin_listas;2651900 Wrote:
>>
>> My guess is simply that you created that sdb at the current 2 MB size,
>> and there never was more.
>>
>
> I can say for 100% that this is not the fact but anyway, I understand
> what you’re trying to say.

Well, you see, several LVM creation tools do just that, on purpose.

> Thanks for your help so far. I think I just go for my last backup now
> … it’s a little bit older but as you said, on encrypted devices it is
> nearly impossible to recover data … I think using the backup is the
> much more simpler way :slight_smile:

Absolutely.

You see, a data mining recovery tool, such as photorec, recovers files
by looking for patterns. As the filesystem is encrypted, it is
impossible to search on the raw device and find anything at all, because
it is giberish, on purpose.

It is only possible to search for files on the decrypted filesystem, ie,
on “/dev/mapper/crypt/”, and this one is only 2 MB of size. Maybe it was
bigger before, but now it is 2 MB, and there is no way of going beyond.

You can, arbitrarily, recreate the partition to the entire disk, but
unless you get the exact same sector count and placement, it is useless.
If you can place it there, and the manual call to cryptosetup to open an
existing device in there succeeds, then and only then you can attempt
recovery.

As to finding the partition layout… on a traditional mbr disk, sdb5 is
a logical partition. There is a pointer on the previous partition that
says where #5 starts, and #5 has a pointer to #6 if it exists. I guess
that testdisk may scan the entire sector count trying to find the
pattern that says “this is a logical partition first sector” or “this is
the last sector of a partition”. Maybe it get clues from other patterns
on the data. But the data is giberish… because it was encrypted.

Which explains, more or less, why testdisk can not find any bigger
partition, accepting your claim that it was in there.

On a GPT table, the table entries are fixed, and the old one was erased.
I don’t know if it is possible to scan the disk and find a possible old
partition layout.

I hope I managed to explain it somewhat… :-?

If this is at all possible, try “guespart”. I think the actual name is
gpart.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)