EDIT: Still had a backup of my old config folder. Copied the whole folder to my new (fresh 6.8.1) USB stick, rebooted, and had everything back the way it was before. Also learned that you can identify your parity drive by assigning all drives as data drives, NO PARITY DRIVE, and then starting the array. Old parity drive will appear as having a file system that can't be read.

 

I upgraded the guts of my server and and trying to bring the array back up, but I don't have a backup of my previous bzroot and bzconfig files. I can get into the interface just fine but I'm scared to start assigning drive for fear of losing data. I'm 95% certain I know which drive was my parity drive. A couple of questions:

 

1. Is there a way to determine with certainty which drive was the previous configuration's parity drive?
2. What steps should I take to get back a working server with the old configuration without risking data loss? I'm happy to endure an entire rebuild if necessary. I have 11 drive in total.

 

Thanks in advance for the help.

Edited January 25, 20206 yr by Wildcat76

What do you mean by this?

Quote

Have backups of "shares" and "plugins"

Are you talking about the config/shares and config/plugins folders from your flash?

 

Do you not have a backup of the whole config folder from flash?

 

That whole config folder is everything about your configuration and you can put that config folder on a new install and be going just like before.

Validate this, but one trick I recall is ... Dont assign anything as parity.

If you assign all drives as data then any old parity drive(s) will likely say unknown filesystem and can't be mounted.

However, if you assign a data drive as new parity it will begin overwriting it immediately and your old data will be lost.

I did make a backup of the entire drive, unfortunately I accidentally (and rather embarrassingly) overwrote the bz files when I was trying to get a new stick formatted with 6.8.1. I have backups of all of the files from the old stick except bzroot, bzconfig, and go.

 

A dumb mistake that I won't make again, but now I'm just trying to get back to a stable working condition with no data loss.

 

What would happen if I assign a slot to all of the data drives and then start the server? Would it just rebuild the parity drive without writing anything to or deleting anything from the data drives?

16 minutes ago, Wildcat76 said:

I have backups of all of the files from the old stick except bzroot, bzconfig, and go.

You don't need those because they are in a new install and they don't change except with an upgrade.

 

As I said, all you need is the complete config folder.

 

Just prepare flash as a new install, copy the config folder from your backup to that new install, and you are good to go.

11 minutes ago, BRiT said:

Validate this, but one trick I recall is ... Dont assign anything as parity.

If you assign all drives as data then any old parity drive(s) will likely say unknown filesystem and can't be mounted.

However, if you assign a data drive as new parity it will begin overwriting it immediately and your old data will be lost.

Looks like we have a winner. The drive I suspected was the old parity drive did indeed have an unreadable file system when I mounted them all as data drives (with nothing mounted as parity). I'll confirm that the important data is all there and accessible, then stop the array, assign the parity drive, and let it rebuild parity.

 

Thanks so much for the help!

But unless you restore that complete config folder from your backup, you won't have any of your settings. You will have to set everything up again.

 

And that config folder would have taken care of your disk assignments too. In fact, you could have even skipped the parity rebuild.

9 minutes ago, trurl said:

But unless you restore that complete config folder from your backup, you won't have any of your settings. You will have to set everything up again.

 

And that config folder would have taken care of your disk assignments too. In fact, you could have even skipped the parity rebuild.

Well, I haven't done that yet. I'll try the config folder copy and see if that works first.

56 minutes ago, trurl said:

But unless you restore that complete config folder from your backup, you won't have any of your settings. You will have to set everything up again.

 

And that config folder would have taken care of your disk assignments too. In fact, you could have even skipped the parity rebuild.

Success! That brought everything back as before. I love this freaking community. Thanks so much!

I would still do a correcting parity check, just to make sure your interim steps didn't get things out of sync. I'd expect a (large) handful of parity corrections, and a subsequent non-correcting check should come up with zero errors. If it doesn't, collect diagnostics and attach them here for analysis.

There will be a few sync errors due to mounting the disks read/write without parity.

2 hours ago, jonathanm said:

I would still do a correcting parity check, just to make sure your interim steps didn't get things out of sync. I'd expect a (large) handful of parity corrections, and a subsequent non-correcting check should come up with zero errors. If it doesn't, collect diagnostics and attach them here for analysis.

Running a parity check now. Should be finished in a day. Fingers crossed.

Edited January 25, 20206 yr by Wildcat76

Parity check complete with a little under 1000 errors (all corrected). I'll take it. Thanks again to everyone for your help!

12 hours ago, Wildcat76 said:

Parity check complete with a little under 1000 errors (all corrected). I'll take it. Thanks again to everyone for your help!

At your leisure be sure to do a non-correcting check to ensure all is good.

 

The last check on file should ALWAYS be a non-correcting check showing zero errors. If that situation changes, you need to investigate why and correct the issue until you get there. A zero error parity check is your assurance that if a disk fails, it will be emulated and 100% rebuildable.

On 1/26/2020 at 11:17 AM, jonathanm said:

At your leisure be sure to do a non-correcting check to ensure all is good.

 

The last check on file should ALWAYS be a non-correcting check showing zero errors. If that situation changes, you need to investigate why and correct the issue until you get there. A zero error parity check is your assurance that if a disk fails, it will be emulated and 100% rebuildable.

Done. Non-correcting parity check completed with zero errors. Praise be.

Edited January 27, 20206 yr by Wildcat76