Partition table recovery with testdisk

[Tony Su]

If the data on the disk is unaffected, you can easily recover your
disk in seconds if you use gdisk, which is the gpt version of fdiisk.

Commands for gdisk are similar to fdisk, but otherwise I assume you
know your way around the standard info like the command help, MAN
pages, etc.

I've easily replace the removed partition boundaries if I know what
the original were... So, for instance I usually use the distro install
disk layouts for a given disk size. Re-constructing the partitions
then is no different than if all the walls in a house were blown away
by a tornado leaving the furniture magically untouched. If I rebuilt
the walls and roof around the furniture, then anyone could walk into
the house and not notice any difference from before the tornado.

Tony

On Sat, Jul 29, 2017 at 7:54 PM, Kevin Keane Subscription

Thank you so much! Yes, I am working on a Linux box with that. I just send emails from my Windows laptop..
Wonderful, and detailed, writeup. I had already gotten about halfway through – gdisk told me that there was only a single large partition where there should have been three (I suspect somebody who didn’t know what he was doing had messed with the partition table, and then not rebooted, leaving me with the mess to clean up).
That’s where testdisk came in. It found two of the three partitions without a problem, but didn’t find the third one. I may end up playing it safe, recovering the data from the other partitions and rebuild the system.
Sent from Mail for Windows 10
Sent: Saturday, July 29, 2017 7:26 PM
Subject: Re: Partition table recovery with testdisk

I’m working on an urgent disaster recovery, and am looking for some
advice. We lost the GPT partition table (the protective MBR is still
in place). I already made a duplicate of the disk, and have started
analyzing it with testdisk.
Testdisk found three partitions (which is what I expected), but
misidentified one of them as a swap partition (it should actually be
an EFI system partition). I tried to change the partition type
manually to EFI/FAT32 but no luck - testdisk claimed that there was
no file system.
Where do I go from here without doing further damage?

If you think that testdisk has restored the GPT partition table, you can
then analyze the partitions with other tools. I'm also noticing that
testdisk hasn't been updated since April 2015. I think I would try
gparted <http://gparted.org/> instead.
I really hope you are using a Linux box to do the testing and analysis
since your e-mail says it's coming from Windows 10. If you are
attempting to use Windows for data recovery of a Linux system I can't
help you.
If at all possible, hook up the hard drive directly to a PC using a SATA
connection. It might be possible to work on the disk when it is in a USB
mobile rack but I wouldn't trust the controller chip for such an
operation. The hard drive should be the only disk in the PC.
Boot the computer using a LiveCD OS such as gparted-live or Knoppix. You
can use either a DVD or USB drive to boot the PC. After the system
$ dmesg|less
(60.0 GB/55.9 GiB)
[ 1.496199] sd 0:0:0:0: [sda] Write Protect is off
[ 1.496200] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
enabled, doesn't support DPO or FUA
[ 1.498182] sda: sda1 sda2 < sda5 sda6 >
[ 1.498639] sd 0:0:0:0: [sda] Attached SCSI disk
The key part is the "sda: sda1 sda2 < sda5 sda6 >". These are the
partitions on the hard drive that the system recognizes. If you can't
find something like that in dmesg then there is no partition table that
can be recognized. gpartd has some ability to rescue partitions and
might be needed if testdisk can't do that for you. gdisk also has some
ability to diagnose and repair a damaged GPT partition table. See the
man page for more info.
The next step is to try and figure out what is in each of the
partitions. The command for that is "blkid". So go through the
$ sudo blkid /dev/sda1
/dev/sda1: LABEL="root" UUID="4c94326f-496b-419b-8b5f-3d353b30918a"
TYPE="ext4" PARTUUID="19a2146a-01"
$ sudo blkid /dev/sda5
/dev/sda5: LABEL="swap" UUID="3d63b862-61ad-468a-9a1c-eb200bd25ae0"
TYPE="swap" PARTUUID="19a2146a-05"
You should have an identifiable type for each partition.
$ sudo gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.8
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 7814037168 sectors, 3.6 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 6F7FDEE4-CF0E-4171-BE61-8305AA30B2A6
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 7814037134
Partitions will be aligned on 2048-sector boundaries
Total free space is 3693 sectors (1.8 MiB)
Number Start (sector) End (sector) Size Code Name
1 2048 4095 1024.0 KiB EF02
2 4096 7806259199 3.6 TiB 0700
3 7806259200 7814035455 3.7 GiB 8200
Hopefully the partitions identified by gdisk are the same as what was
identified by the kernel and blkid.
If everything matches up, then I'd say there is some problem with
testdisk and the disk itself is fine.
If there is a discrepancy, then you need to determine what the real
problem is. Is it just that the partition type in the GPT is wrong or is
the file system in the EFI partition really hosed.
Fortunately, Linux will willing believe what you tell it about file
$ sudo fsck -t vfat /dev/sda1
If the partition is really FAT32 then the check should return an OK
result. If it comes back to you saying it can't figure it out then you
probably have a hosed file system.
Assuming that the file system check is OK then use gdisk to fix the
partition type..
If the EFI partition is hosed, all is not lost. If you have managed to
check the data partition and it is good (i.e fsck reports it is OK) then
you can reformat the EFI partition as fat32 (vfat) and use gdisk to mark
it as EFI. Put everything back to the way it was and use Super Grub Disk
<http://www.supergrubdisk.org/> to boot the system. Re-install grub from
the running system and it should put all your EFI files into their
proper place in the EFI partition.
Certain details have been omitted.
Gus
--
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
--
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list

[Tony Su]

Cool.
Always great to hear when a disaster can be avoided.

Tony

On Sun, Jul 30, 2017 at 11:00 PM, Kevin Keane Subscription

Thank you, Tony! Well, duh. If I knew the exact original boundaries, I
wouldn’t have been in this quandary in the first place!
But as it turns out, it actually ended up being very straightforward once I
realized what had happened. Testdisk was entirely correct in finding the
partitions, it just missed the first partition completely (and it was off by
a few sectors on the size of the last partition). Why? Turns out that
somebody had overwritten the first 100MB of the disk with all zeros using dd
(it was a script gone horribly wrong). So it didn’t just wipe the partition
tables, but also half of the partition I was looking for. No wonder testdisk
didn’t find it.
I now have all my partitions back and am confident that they are correct.
All I need to do is reconstruct the content of the EFI partition (which is
mostly just grub stuff, and grub.conf), and be done with it.
Sent from Mail for Windows 10
From: Tony Su
Sent: Sunday, July 30, 2017 4:35 PM
To: Main Discussion List for KPLUG
Subject: Re: Partition table recovery with testdisk
If the data on the disk is unaffected, you can easily recover your
disk in seconds if you use gdisk, which is the gpt version of fdiisk.
Commands for gdisk are similar to fdisk, but otherwise I assume you
know your way around the standard info like the command help, MAN
pages, etc.
I've easily replace the removed partition boundaries if I know what
the original were... So, for instance I usually use the distro install
disk layouts for a given disk size. Re-constructing the partitions
then is no different than if all the walls in a house were blown away
by a tornado leaving the furniture magically untouched. If I rebuilt
the walls and roof around the furniture, then anyone could walk into
the house and not notice any difference from before the tornado.
Tony
On Sat, Jul 29, 2017 at 7:54 PM, Kevin Keane Subscription

Thank you so much! Yes, I am working on a Linux box with that. I just send
emails from my Windows laptop..
Wonderful, and detailed, writeup. I had already gotten about halfway
through – gdisk told me that there was only a single large partition where
there should have been three (I suspect somebody who didn’t know what he was
doing had messed with the partition table, and then not rebooted, leaving me
with the mess to clean up).
That’s where testdisk came in. It found two of the three partitions
without a problem, but didn’t find the third one. I may end up playing it
safe, recovering the data from the other partitions and rebuild the system.
Sent from Mail for Windows 10
Sent: Saturday, July 29, 2017 7:26 PM
Subject: Re: Partition table recovery with testdisk

I’m working on an urgent disaster recovery, and am looking for some
advice. We lost the GPT partition table (the protective MBR is still
in place). I already made a duplicate of the disk, and have started
analyzing it with testdisk.
Testdisk found three partitions (which is what I expected), but
misidentified one of them as a swap partition (it should actually be
an EFI system partition). I tried to change the partition type
manually to EFI/FAT32 but no luck - testdisk claimed that there was
no file system.
Where do I go from here without doing further damage?

If you think that testdisk has restored the GPT partition table, you can
then analyze the partitions with other tools. I'm also noticing that
testdisk hasn't been updated since April 2015. I think I would try
gparted <http://gparted.org/> instead.
I really hope you are using a Linux box to do the testing and analysis
since your e-mail says it's coming from Windows 10. If you are
attempting to use Windows for data recovery of a Linux system I can't
help you.
If at all possible, hook up the hard drive directly to a PC using a SATA
connection. It might be possible to work on the disk when it is in a USB
mobile rack but I wouldn't trust the controller chip for such an
operation. The hard drive should be the only disk in the PC.
Boot the computer using a LiveCD OS such as gparted-live or Knoppix. You
can use either a DVD or USB drive to boot the PC. After the system
$ dmesg|less
(60.0 GB/55.9 GiB)
[ 1.496199] sd 0:0:0:0: [sda] Write Protect is off
[ 1.496200] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
enabled, doesn't support DPO or FUA
[ 1.498182] sda: sda1 sda2 < sda5 sda6 >
[ 1.498639] sd 0:0:0:0: [sda] Attached SCSI disk
The key part is the "sda: sda1 sda2 < sda5 sda6 >". These are the
partitions on the hard drive that the system recognizes. If you can't
find something like that in dmesg then there is no partition table that
can be recognized. gpartd has some ability to rescue partitions and
might be needed if testdisk can't do that for you. gdisk also has some
ability to diagnose and repair a damaged GPT partition table. See the
man page for more info.
The next step is to try and figure out what is in each of the
partitions. The command for that is "blkid". So go through the
$ sudo blkid /dev/sda1
/dev/sda1: LABEL="root" UUID="4c94326f-496b-419b-8b5f-3d353b30918a"
TYPE="ext4" PARTUUID="19a2146a-01"
$ sudo blkid /dev/sda5
/dev/sda5: LABEL="swap" UUID="3d63b862-61ad-468a-9a1c-eb200bd25ae0"
TYPE="swap" PARTUUID="19a2146a-05"
You should have an identifiable type for each partition.
$ sudo gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.8
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 7814037168 sectors, 3.6 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 6F7FDEE4-CF0E-4171-BE61-8305AA30B2A6
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 7814037134
Partitions will be aligned on 2048-sector boundaries
Total free space is 3693 sectors (1.8 MiB)
Number Start (sector) End (sector) Size Code Name
1 2048 4095 1024.0 KiB EF02
2 4096 7806259199 3.6 TiB 0700
3 7806259200 7814035455 3.7 GiB 8200
Hopefully the partitions identified by gdisk are the same as what was
identified by the kernel and blkid.
If everything matches up, then I'd say there is some problem with
testdisk and the disk itself is fine.
If there is a discrepancy, then you need to determine what the real
problem is. Is it just that the partition type in the GPT is wrong or is
the file system in the EFI partition really hosed.
Fortunately, Linux will willing believe what you tell it about file
$ sudo fsck -t vfat /dev/sda1
If the partition is really FAT32 then the check should return an OK
result. If it comes back to you saying it can't figure it out then you
probably have a hosed file system.
Assuming that the file system check is OK then use gdisk to fix the
partition type..
If the EFI partition is hosed, all is not lost. If you have managed to
check the data partition and it is good (i.e fsck reports it is OK) then
you can reformat the EFI partition as fat32 (vfat) and use gdisk to mark
it as EFI. Put everything back to the way it was and use Super Grub Disk
<http://www.supergrubdisk.org/> to boot the system. Re-install grub from
the running system and it should put all your EFI files into their
proper place in the EFI partition.
Certain details have been omitted.
Gus
--
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
--
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list

--
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list

[Kevin Keane Subscription]

Yes, as a last resort I’ll do that (we actually have a guy with that experience), but was looking to see if there is a way to repair the damage before Monday without further destruction.

 
Sent from Mail for Windows 10

 
From: Andrew Murphy <mailto:***@genkimind.com>
Sent: Saturday, July 29, 2017 2:02 PM
To: Main Discussion List for KPLUG <mailto:kplug-***@kernel-panic.org>
Subject: Re: Partition table recovery with testdisk

 


Send it to professional data recovery. If you are professional data
recovery, shit.

I’m working on an urgent disaster recovery, and am looking for some
advice. We lost the GPT partition table (the protective MBR is still in
place). I already made a duplicate of the disk, and have started analyzing
it with testdisk.
Testdisk found three partitions (which is what I expected), but
misidentified one of them as a swap partition (it should actually be an EFI
system partition). I tried to change the partition type manually to
EFI/FAT32 but no luck  - testdisk claimed that there was no file system.
Where do I go from here without doing further damage?
Sent from Mail for Windows 10
--
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list

--
KPLUG-***@kernel-panic.org
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list

[Kevin Keane Subscription]

I’m working on an urgent disaster recovery, and am looking for some advice. We lost the GPT partition table (the protective MBR is still in place). I already made a duplicate of the disk, and have started analyzing it with testdisk.

 
Testdisk found three partitions (which is what I expected), but misidentified one of them as a swap partition (it should actually be an EFI system partition). I tried to change the partition type manually to EFI/FAT32 but no luck  - testdisk claimed that there was no file system.

 
Where do I go from here without doing further damage?

 
Sent from Mail for Windows 10

 

[Gus Wirth]

I’m working on an urgent disaster recovery, and am looking for some
advice. We lost the GPT partition table (the protective MBR is still
in place). I already made a duplicate of the disk, and have started
analyzing it with testdisk.
Testdisk found three partitions (which is what I expected), but
misidentified one of them as a swap partition (it should actually be
an EFI system partition). I tried to change the partition type
manually to EFI/FAT32 but no luck - testdisk claimed that there was
no file system.
Where do I go from here without doing further damage?

If you think that testdisk has restored the GPT partition table, you can
then analyze the partitions with other tools. I'm also noticing that
testdisk hasn't been updated since April 2015. I think I would try
gparted <http://gparted.org/> instead.

I really hope you are using a Linux box to do the testing and analysis
since your e-mail says it's coming from Windows 10. If you are
attempting to use Windows for data recovery of a Linux system I can't
help you.

If at all possible, hook up the hard drive directly to a PC using a SATA
connection. It might be possible to work on the disk when it is in a USB
mobile rack but I wouldn't trust the controller chip for such an
operation. The hard drive should be the only disk in the PC.

Boot the computer using a LiveCD OS such as gparted-live or Knoppix. You
can use either a DVD or USB drive to boot the PC. After the system
boots, examine dmesg to see if the disk is recognized:

$ dmesg|less

Look for something like this:

[ 1.496188] sd 0:0:0:0: [sda] 117231408 512-byte logical blocks:
(60.0 GB/55.9 GiB)
[ 1.496199] sd 0:0:0:0: [sda] Write Protect is off
[ 1.496200] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 1.496217] sd 0:0:0:0: [sda] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[ 1.498182] sda: sda1 sda2 < sda5 sda6 >
[ 1.498639] sd 0:0:0:0: [sda] Attached SCSI disk


The key part is the "sda: sda1 sda2 < sda5 sda6 >". These are the
partitions on the hard drive that the system recognizes. If you can't
find something like that in dmesg then there is no partition table that
can be recognized. gpartd has some ability to rescue partitions and
might be needed if testdisk can't do that for you. gdisk also has some
ability to diagnose and repair a damaged GPT partition table. See the
man page for more info.

The next step is to try and figure out what is in each of the
partitions. The command for that is "blkid". So go through the
partitions and see if you can identify what they are. Examples:

$ sudo blkid /dev/sda1
/dev/sda1: LABEL="root" UUID="4c94326f-496b-419b-8b5f-3d353b30918a"
TYPE="ext4" PARTUUID="19a2146a-01"

$ sudo blkid /dev/sda5
/dev/sda5: LABEL="swap" UUID="3d63b862-61ad-468a-9a1c-eb200bd25ae0"
TYPE="swap" PARTUUID="19a2146a-05"

You should have an identifiable type for each partition.

Use gdisk to see the partition table:

$ sudo gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.8

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

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 7814037168 sectors, 3.6 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 6F7FDEE4-CF0E-4171-BE61-8305AA30B2A6
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 7814037134
Partitions will be aligned on 2048-sector boundaries
Total free space is 3693 sectors (1.8 MiB)

Number Start (sector) End (sector) Size Code Name
1 2048 4095 1024.0 KiB EF02
2 4096 7806259199 3.6 TiB 0700
3 7806259200 7814035455 3.7 GiB 8200


Hopefully the partitions identified by gdisk are the same as what was
identified by the kernel and blkid.

If everything matches up, then I'd say there is some problem with
testdisk and the disk itself is fine.

If there is a discrepancy, then you need to determine what the real
problem is. Is it just that the partition type in the GPT is wrong or is
the file system in the EFI partition really hosed.

Fortunately, Linux will willing believe what you tell it about file
systems in a partition. Try running fsck on the partition:

$ sudo fsck -t vfat /dev/sda1

If the partition is really FAT32 then the check should return an OK
result. If it comes back to you saying it can't figure it out then you
probably have a hosed file system.

Assuming that the file system check is OK then use gdisk to fix the
partition type..

If the EFI partition is hosed, all is not lost. If you have managed to
check the data partition and it is good (i.e fsck reports it is OK) then
you can reformat the EFI partition as fat32 (vfat) and use gdisk to mark
it as EFI. Put everything back to the way it was and use Super Grub Disk
<http://www.supergrubdisk.org/> to boot the system. Re-install grub from
the running system and it should put all your EFI files into their
proper place in the EFI partition.

Certain details have been omitted.

Gus

[Andrew Murphy]

Send it to professional data recovery. If you are professional data
recovery, shit.

I’m working on an urgent disaster recovery, and am looking for some
advice. We lost the GPT partition table (the protective MBR is still in
place). I already made a duplicate of the disk, and have started analyzing
it with testdisk.
Testdisk found three partitions (which is what I expected), but
misidentified one of them as a swap partition (it should actually be an EFI
system partition). I tried to change the partition type manually to
EFI/FAT32 but no luck - testdisk claimed that there was no file system.
Where do I go from here without doing further damage?
Sent from Mail for Windows 10
--
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list