Invalid Partition Table

[KB1SPH]

So, let me start from the beginning...

I'm running a Dell PowerEdge R720 with a PERC H710 RAID controller.

I'm using VMWare ESXi to host virutal machines, one of which is FreeNAS (11.2-U2.1).

I was attempting to remove a drive that did not belong to the FreeNAS VM...or so I thought. I accidentally removed one that had lots of important files on it, and, of course, this was a single RAID 0 drive (I know...not smart). I had copied the files temporarily to this drive as I was redoing the other drives (which of course have already been wiped) and I was going to copy them back to the RAID 1 disks.

Anyway, I put the drive back in the system and had to re-create the virtual disk (without initializing it so that it would not wipe out the data) as I have read on other forums that this should make the disk come right back. However, nothing seems to be showing up.

fdisk -l shows this for the drive through ESXi:

Disk /dev/disks/naa.6b8ca3a0efd589002465f0e0173b8395: 999.6 GB, 999653638144 bytes
255 heads, 63 sectors/track, 121534 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/disks/naa.6b8ca3a0efd589002465f0e0173b8395 doesn't contain a valid partition table

In FreeNAS I run gpart show and the drive (da2) does not show up. If I run gpart show /dev/da2 it says, "gpart: No such geom: /dev/da2."
If I run fdisk /dev/da2 I get:

******* Working on device /dev/da2 *******
parameters extracted from in-core disklabel are:
cylinders=121534 heads=255 sectors/track=63 (16065 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=121534 heads=255 sectors/track=63 (16065 blks/cyl)

fdisk: invalid fdisk partition table found
Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
start 63, size 1952443647 (953341 Meg), flag 80 (active)
beg: cyl 0/ head 1/ sector 1;
end: cyl 701/ head 254/ sector 63
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>

When I originally added the drive to FreeNAS I had created an encrypted dataset, then within that a zvol that I used for iSCSI.

So...does the fact that it lists a partition 1 through fdisk mean everything is still there? Is there any way to fix the partition table and recover everything and re-import the volume? Please tell me there's a way!

If any further information is needed please let me know.

Thanks!

 

[Chris Moore]

I'm running a Dell PowerEdge R720 with a PERC H710 RAID controller.

Gotta get rid of that hardware RAID controller. Not compatible with FreeNAS.

 

[KB1SPH]

Yeah, eventually I'd like to get a controller for it that doesn't have RAID and I'll just do the RAID with ZFS, but this was an already established machine that I decided to put FreeNAS on.

That being said, any ideas on how I might be able to solve the problem at hand?

 

[Chris Moore]

When I originally added the drive to FreeNAS I had created an encrypted dataset,

Encryption on top of all the rest?

You might be able to recover from this, if it wasn't encrypted. I recall someone else with a similar problem not too long ago, but I don't think they had encryption. Please try a forum search.

 

[KB1SPH]

Also, any idea what cards (Non-RAID) I might be able to put into this server that I could just plug the existing cables into for the storage backplane to make it easier?

 

[KB1SPH]

Encryption on top of all the rest?

You might be able to recover from this, if it wasn't encrypted. I recall someone else with a similar problem not too long ago, but I don't think they had encryption. Please try a forum search.

Yeah, I was playing around with different options (some of the important files on the drive were tax and financial information) and later realized that I should have just used something in Windows to enrypt the files on the iSCSI drive instead of doing the encrypted ZFS. But I hadn't got around to changing that because I was re-doing the main storage drives (putting new ones in) anyway. So when I moved everything back over to the new (bigger) drives I was just going to do away with the encryption.

 

[Heracles]

Hey KB1Sph,

I think that the only valuable thing to save from this is experience, knowledge and skills. The recovery of the Raid-0 would have been lucky. Now that you tell us the drive was encrypted by ZFS, it is pretty clear that you are probably now beyond recovery...

Still, just to figure out exactly :
How the drive and controller were configured exactly ?
The drive was part of a Raid-0 managed by the PERC ? Or by FreeNAS ?
The PERC was PCI passthrough and presented to FreeNAS ? Or was the PERC presented to ESX and handled by the hypervisor ?
The drive was part of an ESX storage in which you created a VMDK for FreeNAS ?

How exactly was that ?

Not that I have any hope, but still let see what it was and what deserved to be tried.

 

[KB1SPH]

Hey KB1Sph,
How the drive and controller were configured exactly ?
The drive was part of a Raid-0 managed by the PERC ? Or by FreeNAS ?

Yes, the drive was in a RAID-0 on the PERC controller, only because there's no way to just use a disk directly without setting up a virtual disk.

The PERC was PCI passthrough and presented to FreeNAS ? Or was the PERC presented to ESX and handled by the hypervisor ?

Handled by the hypervisor...never really thought about passthrough.

The drive was part of an ESX storage in which you created a VMDK for FreeNAS ?

No, the drive was not actually used as a datastore. I used raw device mapping so that the FreeNAS could have direct access to the drive and all it's information. It showed up to FreeNAS just as it would if ESXi was not there in between. It was FreeNAS that I did the encryption through and I do have the key backed up.

I was hoping that if there's a way to restore the partition table that maybe FreeNAS would recognize it.

 

[Heracles]

Hi again,

Unfortunately, the drive that was passed through was not the physical drive. It was the virtual drive. As such, first step would be to restore the virtual drive. From what you described, that part already failed.

Once done, to restore the ZFS drive and its encryption would be next. Unfortunately, because of the encryption, a single bit wrong is enough to prevent the restore...

But in all cases, because first level of abstraction already failed, I doubt there is any reason to hope for any kind of recovery...

Sorry for your loss,

 

[Arubial1229]

When you ignore pretty much every best-practice scenario, this is the end result. Like Heracles said, all you can do is learn from the mistake.