ZFS Raid issue

[raycherry]

I have a FreeNas setup with two 1TB disks - ZFS Raid2 ( Ibelieve) . Unfortunately the partition table for the array has been deleted and I have lost access to the data on the disks. The data on the disks was not deleted and I believe it is still there.

My question is how do I rebuild/restore the partition table that was deleted (or access the data on at least one of the disks so that I can copy it off)?

Any help/suggestions would be gratefully received.

 

[Ericloewe]

zpool import -D is likely to be helpful, but you may need to manually recreate the partition table.

 

[sretalla]

manually recreate the partition table.

I recall somebody asking for some output from the community to help to find the partition information to use with dd to overwrite a bad partition...

Not sure if it will have exactly what you need, but maybe some help:

Unable to decrypt encrypted pools after reboot (GPT partitions gone on ALL drives?)

This is a follow-up to my original post this past Saturday. I am starting this new thread because I have learned a lot of new information over the past few days and have made some progress but have hit a wall. My hardware setup: Dell r720xd 128MB ecc memory SAS9200-8e-hp JBOD controller...

www.truenas.com

 

[raycherry]

Thanks for the reply.
I ran zpool import -D and then zpool list/zpool status and got back 'no pools available'
I've never needed to manually recreate a partition table before - any guidance on how to that would be gratefully received!

 

[sretalla]

I've never needed to manually recreate a partition table before - any guidance on how to that would be gratefully received!

It's all there in the threads I linked... but I agree it's very confusing if all you're wanting to know is how to take a working, partitioned disk and use its Partition table to replace a bad one on another disk (potentially in the same or another ZFS pool (but must be disks of identical size).

You start by taking the backup from a "good" disk (remembering must be the same size) to a file:
dd if=/dev/da0 of=/media/da0.mbr.backup bs=512 count=3

Then you can use that file to "restore" the GPT to another disk (let's say it's going to be da1):
dd if=/media/da0.mbr.backup of=/dev/da1 bs=512 count=3

The guy who put the thread together was solving a much more complex problem with a GELI encrypted pool and was also trying to come back from a situation where he lost all GPTs, so didn't have a good copy himself.

He notes that the correct site here is actually smaller than 3x512 bytes (actually 1280, not 1536), but there's sufficient padding in that area of the disk that it won't matter. (reference: https://www.truenas.com/community/t...pool-i-need-your-help-clone-of-gpt-mbr.85979/)


You will need to take your own steps to manage the risk here as far as performing potentially destructive operations on live disks... either take backups or be clear that all is already lost and it can't get "worse" by trying those commands.

 

[raycherry]

OK. I did follow the link and your right - it is confusing.
To summarize the above I create another zfs pool with one disk the same size as the 'bad' ones and then copy its partition table to one of the 'bad' disks in the original pool?

 

[sretalla]

If you have identical disks in the same pool, using one of them would be the easiest option.

It may warrant some investigation on how gptids are decided and stored (if it's in the gpt header, you wouldn't want to have a duplicate in the same pool... Nor the same box). I feel like it should be too big to fit in just over 1KB of data, but haven't had the time to test it myself for you.

 

[raycherry]

Your suggested solution worked!
The data has been recovered.
Many thanks for your help.