Hi guys;
I have a core version of Truenas in ESXi virtual Server.
I Set a File (5TB) as a HHD & there was no redundancy for Raid or mirror data.
Because of a electrical power failure my ESXi hypervisor become failed & after reinstall ESXi and re register Truenas i found that the internal Structure of Truenas VMDK is corrupted.
my VMDK file is fully bind to VM & after Truenas boots Disk is detected and it’s size is correct but there is no any pool or even partition in disk.
its seems to lost Partition table and critical information so that disk shows as a unpartitioned Disk.
Is there any way to repair disk or Recover Pool or Data?
thx
There’s no repair utility for ZFS. Short of passing the VMDK to a Windows VM to run Klennet ZFS Recovery, I see no way to recover data.
The only proper way to virtualise TrueNAS is to passthrough the disk controller to the VM. Virtual disks can only be used for testing purpose, and no real data should be commited to virtual disk storage.
1 Like
In theory, if you have a clue on what the partition table looked like, you could try and re-create it.
But, I would only do so with a backup of your VMDK as if you make a mistake, further recovery steps might not be possible.
Please note that while I have successfully recovered more than a dozen Solaris VMs with missing partition tables, (and boot blocks), I had complete backups. Thus, the first time we tried to restore the partition table instead of performing a full restore, we had a fall back plan.
As to WHY those Solaris VMs / LDOMs were missing partition tables, that is another boring and too long a story.
1 Like
thx etorix
thx Arwen
could you please guide me about recovery tools or some solutions for recovery partition or repair VMDK?
I can tell more about my problem and situation if needed. 
Sorry, I have no experience with using TrueNAS as a VM under VMWare. Let alone with VMDK storage.
To be certain, you have tried this command in the TrueNAS Core VM?
zpool import
I tried looking up to see if ZFS had a “magic number” at the beginning of it’s data, but could not find one.
Their appears to be a block of 4096 byte block of zeros, or ignored data, at the beginning of a ZFS pool. I think this is a hold over when using an entire disk as a ZFS vDev member, so ZFS would skip any boot block or partition table.
Based on my own partition table recoveries under Solaris, I would guess a zpool import would not detect a pool on a disk if the pool did not start at 4096 bytes after the beginning of the disk or partition.
Your first goal should be a full backup of the VMDK because anything we suggest might destroy any chance of trying a second thing we might suggest.
Next, learn any TrueNAS Core / FreeBSD partition table program. I don’t know them well enough to even suggest how to use or learn it / them.
I did check zdb, the ZFS Debugger, and I could not find a method to scan for the start of a ZFS pool on a storage device. Nor do web searches help.
Your problem and others does suggest that a new feature of zdb should be made to scan a disk for pools, and write the offset from the beginning. Of course that won’t happen soon…
To be clear on one point, ZFS was specifically designed and tested to survive with existing data intact, on any un-expected shutdown. That means power loss, forced reboot or OS crash. Loss of ZFS pool data during such is always a result of bad hardware or poor configuration.