Recover Partition-Table still present in running system

The extents of the partitions can be read from /sys/block/sda/sda1/start, /sys/block/sda/sda1/size and so on. The values are in sectors. Write down these values before doing anything else, especially rebooting.

Once you have the values, you can recreate the partitions with fdisk. Use the u command to switch the unit to sectors, then create the partitions by entering

• n
• primary/logical/extended
• partition number (except for logical partitions: do them in order)
• initial sector
• + size in sectors

Almost two years have passed since the question was asked. We were in exactly the same situation yesterday: We have a Linux Software RAID Level 1 with 2 disks. One of the disks broke down and had to be replaced. We had the disk exchanged and then wanted to copy the partition table from the remaining (working) disk to the new disk. Unfortunately, we copied the empty partition table from the new disk to the old disk. Luckily, we immediately discovered this before rebooting the machine, so the correct partition table was still active in the kernel. Here is what we did to resolve the issue:

• We extracted partition data from the /sys/block/ file system as described in Gilles` answer.
• Our system uses a GUID partition table, so we couldn't use fdisk but had to use gdisk instead.
• gdisk works pretty much the same as fdisk except there is no need to specify u for sectors.
• We created partitions with the exact data as extracted from /sys/block/. There are other answers to similar questions that say to decrease the partition size by one, but that was not neccessary for us.
• With a guid partition table there is no longer a distinction between primary and extended partitions.
• The sys/block file system contains no information about file system types, so we extracted them with mount.
• With a guid partition table, there is no longer a bootable flag. If the partition table to restore is from a bootable disk, there must be a partition with type BIOS boot partition (usually the first partition).

After writing the partition table with gdisk, we were able to reboot the system and everything was running just fine.