Data Recovery? Volume seen, no pools (probable cause: lost partition table)

[Sasayaki]

Heya all,

I have a FreeNAS setup with RaidZ and 4x3tb hard drives. Today I did something really, really dumb and switched the drives from the onboard SATA to an Adaptec RAID card, and when I went to create the JBOD I instead initalised them as a RAID array. That faint clicking sound that lasted about half a second across all the disks pretty much stopped my heart.

I expected the worst, but when I reset the drives to their original configuration I set the wrong disk as boot drive (I was having a very bad day) and the system said: "This is a FreeNAS data disk and cannot boot.". Gave me hope something remained.

When I finally actually booted it, the Volume could be seen in FreeNAS, but there are no pools there and its status is Unknown. I'm guessing the RAID card erased the partition table but didn't touch anything else.

Is there any way I can recover this partition table? I have backups, of course, but they're a little old and I had just finished a marathon sprint with a bunch of work I'd hate to lose. It seems like there should be a simple fix to this.

Can upload screenshots if it will help but there's not much to tell.

Edit: I watched the boot sequence. As it found each of the disks it said:

GPT Rejected, may not be recoverable.

So that doesn't sound good.

Edi2t: Putting in as much diagnostic information as I can. Here goes. If more is needed, let me know!

Output of camcontrol devlist is:

<ST3000DM001-9YN166 CC9E> at scbus3 target 0 lun 0 (ada0,pass0)
<ST3000DM001-9YN166 CC9E> at scbus4 target 0 lun 0 (ada1,pass1)
<ST3000DM001-1CH166 CC43> at scbus5 target 0 lun 0 (ada2,pass2)
<ST3000DM001-9YN166 CC4H> at scbus6 target 0 lun 0 (ada3,pass3)
<TOSHIBA TransMemory PMAP> at scbus10 target 0 lun 0 (da0,pass4)

Output of sysctl kern.disks is:

kern.disks: da0 ada3 ada2 ada1 ada0

Output of gpart show is:

=> 63 7870401 da0 MBR (3.8G)
63 1930257 1 freebsd [active] (942M)
1930320 63 - free - (31k)
1930383 1930257 2 freebsd (942M)
3860640 3024 3 freebsd (1.5M)
3863664 41328 4 freebsd (20M)
3904992 3965472 - free - (1.9G)
=> 0 1930257 da0s1 BSD (942M)
0 16 - free - (8.0k)
16 1930241 1 !0 (942M)

 

[cyberjock]

Ok.. few questions:

1. Do you have backups?
2. Is this data worth paying for? I *may* be able to recover it, but I do it as a service outside the forums. And I can't make guarantees(obviously). I did manage to get about 90% of the data from one pool in a similar situation.
3. Is this a business or personal?
4. How many TB of data is on the pool(guesstimate.. doesn't have to be exact)?
5. Why on God's green earth would you move drives from an ideal controller such as onboard to such a horrible choice(RAID controller)?

 

[Sasayaki]

Thanks for replying!

1. Do you have backups?

Yes, but they don't include the last week's big streak of work. Figures I'd get a bit slack on backups right before something like this happened, but the backups do exist.

2. Is this data worth paying for? I *may* be able to recover it, but I do it as a service outside the forums. And I can't make guarantees(obviously). I did manage to get about 90% of the data from one pool in a similar situation.

It's for my home business but it's not worth paying for since I'm in Australia, the data is largely backed up and recoverable.

3. Is this a business or personal?

Part business, mostly personal.

4. How many TB of data is on the pool(guesstimate.. doesn't have to be exact)?

Approximately 4.5tb, of which only about 100gb is truly important and the rest I'll consider a drive cleaning exercise.

5. Why on God's green earth would you move drives from an ideal controller such as onboard to such a horrible choice(RAID controller)?

Because I am stupid and dumb and also stupid. I was having some minor trouble with occasional read checksumming errors since I swapped motherboards and I figured it might be because of the onboard SATA controller. I figured this would be an easy way to test it, but one slip of the finger meant it was initialised as RAID instead of JBOD.

It was dumb but, well, not catastrophic. I have backups but I will lose some work.

 

[Sasayaki]

I updated my original post with as much information as I could.

 

[cyberjock]

First: I'm glad you have backups. Despite the fact you wouldn't pay for it, I hate reading threads of people talking about how their entire adult life is in photos and video that is now forever locked away in an unusable pool.

I would just recreate the pool from scratch and do a restore from backup. Do NOT do this drunk, tired, etc. You have already seen what a single slip-up can mean. Don't think that if one is bad two must be good. ;)

If you are having check-summing problems I'd create a thread and provide as much info that you have on the problem, hardware you are using, etc. But Adaptec is the very wrong way to go. Even without your error you are losing several tools to help identify problems because your RAID controller will abstract the drives, even in JBOD mode. I sold my 3 Adaptecs because of this. :( Both Adaptec and Highpoint are two very dangerous games to play with when using ZFS. Unfortunately for me, I owned plenty of both brands.. so I had to invest money in yet another controller(because 7 of them wasn't enough...)

 

[Sasayaki]

Heh, this is true.

I'm kind of thinking about that week's work though. It's a shame to go to waste, and there's a lot of other people who have had similar problems who might be able to fix it.

If you're happy to keep helping me I'd love to try and work through this problem if we could -- I'm having a little trouble with gpart recover in-so-far as it doesn't seem to recognise my disk. Alternatively, I could just give up and save me the hassle.

If you could PM me a rough quote to fix this, though, I'd be interested. Obviously you don't have to reply in this thread if you don't want to, but I would really like to get the data back if I could; there's some good work there and I'd like to keep it.

 

[Sasayaki]

Some further investigation reveals that GEOM is probably unlikely to be able to probe the disks. I say this because 'gpart show ada0' says "no such geom".

I'm really not sure what that means, but it's likely that the GPT was completely overwritten by the RAID card. If possible, how can one recreate it?