Multiple Problems - Raidz5

[valhallen282]

.
My hint would be as follows

Code:

gpart create -s GPT <device>
gpart add -a 4k -b 128 -s 2G -t freebsd-swap <device>
gpart add -a 4k -t freebsd-zfs <device>
geli restore /path/to/geli/metadata/backup.file /dev/gptid/<rawuuid of freebsd-zfs partition of disk>

Or at least something like that. I wrote the above from memory so please if you opt to give that a shot; please double-check the commands against what FreeNAS expects. You can now try to import the pool and see if it works. You'll need your keys to do that.

I haven't been able to find the exact commands. Since whatever data was on is lost and I have no way to make a DD copy as everything here is closed. I don't mind experimentation on these. Could you help?

Right now, I am making forensic copies of all drives plus the boot/system pool (just for safety, maybe there is some metadata left to use). Two disks at at time, it will probably take me till the middle of the week.

Did you get through making the copies? There's a bunch of ideas over at the Jira link too. Also, looking through test disk from got recovery only shows a single Sun Solaris Partition on my drives. I'm going to check with mfsBSD next. Tonight probably.

 

[PhiloEpisteme]

I haven't been able to find the exact commands. Since whatever data was on is lost and I have no way to make a DD copy as everything here is closed. I don't mind experimentation on these. Could you help?

The gpart commands above are correct as far as I know. The FreeBSD gpart man pages should be useful as a cross reference. The geli command is correct as well. That geli command isn't using the User Keys though, those are the keys you typically interact with; set passphrases on; etc. Instead, it is using the metadata which typically lives in the last part of an encrypted partition and it contains the geli master key; something that you typically never interact with. If you did not ever run geli backup you'll have no luck restoring your geli metadata in this way and short of recovering the bits for the metadata after the pass with /dev/zero you're out luck unfortunately.