Restoring GPT disk partition from MBR backup...?

[mole]

Hi all,

I've just had an SSD lose its partitions - first it became corrupted with a sudden power loss, I'd fsck'd it and it would boot (but not properly - mounted ro and I have to remount it rw to start services, etc). Once fsck was showing no errors, I updated @system then moved it to another PC for an @world update.... and that's when it lost the partitions. The PC I moved it to is generally compatible - same chipset, processor, etc - but is a poor UEFI implementation which assumes GPT on disks 2TB or larger, and this disk is below 1TB.

So now I have:

Code: Select all

GPT fdisk (gdisk) version 1.0.4

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: not present

Creating new GPT entries in memory.

Command (? for help): p
Disk /dev/sdc: 58607766 sectors, 223.6 GiB
Model:  SUV400S37240G  
Sector size (logical/physical): 4096/4096 bytes
Disk identifier (GUID): 05DC1998-095D-497B-B112-ABC742DBB3A2
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 5
First usable sector is 6, last usable sector is 58607760
Partitions will be aligned on 256-sector boundaries
Total free space is 58607755 sectors (223.6 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name

Command (? for help): q

It has a fair amount of important data on it. I have a backup of the partition table, but that was taken when the format was MBR - I've recently updated it to GPT and don't have a backup after converting it. It had four primary partitions when it was MBR, I added a fifth to for OpenBSD after conversion, but that was just by splitting the fourth partition - I'm sure the start of it wasn't changed.

Does anyone know if / how I could restore the partitions - to GPT or MBR - and recover data using the old partition boundaries I've backed up? Or any other method to detect partition boundaries or recover files?

[NeddySeagoon]

mole,

Run testdisk. The first time through do not let it write the partition table. It may find a few false positives.
Try to mount the partitions without a partition table first.

Code: Select all

mount -o ro,offset=<Bytes> /dev/sda /mnt/someplace

will try to mount the filesystem that begins <Bytes> from the start of sda.
If you know the starts already, you don't need testdisk.

When you have a damaged filesystem, do not write to it. That can make things worse. You first step should be to make an image of the drive or affected filesystem.
That's your undo for attempted data recovery.

fsck is a bad thing. It guesses what the filesysem metadata should be and makes it self consistent.
It does this without regard to user data, so if often makes a bad situation worse.
Look in lost+found at the top level of the filesystem. Hopefully, its empty. It contains filesystem fragments that fsck didn't know what to do with.
The numbers are the i-node numbers the fragments occupy. Some of your valuable stuff may be there.

-- edit --

You don't wipe out a GPT disk label by accident. There are two copies, one at the start of the drive and one at the end.
I would have expected one copy to survive.

[mole]

I'm running testdisk just now; going to leave it overnight as it's slow in this mode, then I'll try the mount command you've suggested.

Code: Select all

Disk /dev/sdc - 240 GB / 223 GiB - CHS 3648 255 63
Analyse cylinder  1247/3647: 34%
Read error at 1246/254/63 (lba=20033054)

check_FAT: number of bytes per sector mismatches 512 (FAT) != 4096 (HD)
  Linux filesys. data          255      56831      56576
  Linux filesys. data          255      56831      56576
  Linux filesys. data          255      56831      56576
  Linux Swap                 56831      56832          2
  Linux Swap                 56832    2211837    2155006
  Linux filesys. data      2211840   10526590    8314751
  Linux filesys. data      2211840   10526590    8314751
  Linux filesys. data      2211840   10526590    8314751
  Linux filesys. data      2211840   10526590    8314751
  Linux filesys. data      2211840   10526590    8314751
  Linux filesys. data      2211840   10526590    8314751
check_FAT: number of bytes per sector mismatches 512 (FAT) != 4096 (HD)
check_FAT: number of bytes per sector mismatches 512 (FAT) != 4096 (HD)
check_FAT: number of bytes per sector mismatches 512 (FAT) != 4096 (HD)
check_FAT: number of bytes per sector mismatches 512 (FAT) != 4096 (HD)
check_FAT: number of bytes per sector mismatches 512 (FAT) != 4096 (HD)
check_FAT: number of bytes per sector mismatches 512 (FAT) != 4096 (HD)
  Linux filesys. data      3022077    3022077          1 [Compressed]
  Linux filesys. data      2211840   10526590    8314751
  Linux filesys. data      2211840   10526590    8314751
check_FAT: number of bytes per sector mismatches 512 (FAT) != 4096 (HD)
  Linux filesys. data      2211840   10526590    8314751

You don't wipe out a GPT disk label by accident. There are two copies, one at the start of the drive and one at the end.
I would have expected one copy to survive.

Yes it's odd. I really can't think how that happened.... I did run fsck a few times with different options, but I can't see how that would have affected partitions. Thanks for your help!

[NeddySeagoon]

mole,

The partition table must have been there to allow you to run fsck.

Code: Select all

Read error at 1246/254/63 (lba=20033054) 

is a bad sign.
Thats one failed block.

[mole]

mole,

Try to mount the partitions without a partition table first.

Code: Select all

mount -o ro,offset=<Bytes> /dev/sda /mnt/someplace

will try to mount the filesystem that begins <Bytes> from the start of sda.

Thankyou so much!! I didn't know you could mount a partition like that.

Using the partition boundary from the MBR backup the data partition has mounted I've opened a few files without any problem, some will no doubt be corrupt but I've a full backup from the end of last year and some important work is mirrored to a laptop so hopefully lose much at all.

I've also found the reason - the server CPU or motherboard (probably disk controller) has failed in some way. I've repaired the server disk and it works fine in a (compatible) desktop machine, but if I boot it back in the server disk errors and then kernel panics appear again. The SSD lost its partitions when I switched disks and put it in the server to run fsck - that's when it went from being corrupted from a power off to losing all partition data.

Now to get the data onto a good USB disk. Thanks again!