| View previous topic :: View next topic |
| Author |
Message |
mole
Tux's lil' helper
Joined: 07 Nov 2009
Posts: 84
|
 Posted: Sat May 18, 2019 9:47 pm Post subject: Restoring GPT disk partition from MBR backup...? |
 |
|
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: | 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? |
|
| Back to top |
|
 |
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 55200
Location: 56N 3W
|
| Posted: Sat May 18, 2019 10:48 pm Post subject: |
|
|
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: | | 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.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
mole
Tux's lil' helper
Joined: 07 Nov 2009
Posts: 84
|
| Posted: Sat May 18, 2019 11:05 pm Post subject: |
|
|
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: | 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
|
| Quote: | 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! |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 55200
Location: 56N 3W
|
| Posted: Sat May 18, 2019 11:13 pm Post subject: |
|
|
mole,
The partition table must have been there to allow you to run fsck.
| Code: | | Read error at 1246/254/63 (lba=20033054) |
is a bad sign.
Thats one failed block.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
mole
Tux's lil' helper
Joined: 07 Nov 2009
Posts: 84
|
| Posted: Sun May 19, 2019 9:58 am Post subject: |
|
|
| NeddySeagoon wrote: | mole,
Try to mount the partitions without a partition table first.
| Code: | | 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! |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
