Folks,

 

Couple of scenerios:

 

1) Failed MB and failed flash drive (i.e. lost config, no backup - yes, my bad - lesson learned, etc.) - but all disks and parity are known good.

 

Since I have no config back-up, I can not be sure that drives will come up in the same slots (in the new hardware) - so, even though I know the parity is good, I presume that I'll need to rebuild anyway??

 

Other than the (lengthy) parity rebuild, are there any other forseeable issues?  I.e. can I just assign all of the known good drives at random and start the parity calc?  As long as I'm sure about which is the parity drive, is there any risk to data?

 

 

2) let's say that I'm not 100% sure which drive is parity.  But I know all of the non-parity drives were in-use in the array prior to the hardware crash (by in-use, I mean assigned in the working array full of data - not "in-use" meaning actively being written during the hardware failure).  I would guess that it's safe to presume that the only drive WITHOUT a filesystem is the parity disk?

 

OR...

 

do I need to mount each drive outside of the array and copy data back into an 'empty' array in succession? (I know this will work, it's just extremely tedious).

 

Thanks in advance.

 

Randy

1) Failed MB and failed flash drive (i.e. lost config, no backup - yes, my bad - lesson learned, etc.) - but all disks and parity are known good.

 

Since I have no config back-up, I can not be sure that drives will come up in the same slots (in the new hardware) - so, even though I know the parity is good, I presume that I'll need to rebuild anyway??

You will need to re-assign all of the drives, and you absolutely need to identify and correctly assign the parity drive, but the data drives do not have to be perfectly assigned.  That only takes a few minutes, and then you will run the Trust My Array procedure (another couple of minutes), after which your array will be back up, with full parity protection.  A parity check will be running, to verify everything.

 

If you had some of the drives assigned to User Shares, then once the array is up and running, you will need to determine which ones were part of your User Shares and set them up again.

 

There is one other problem, that may cause a delay, involving your failed flash drive, if it had an unRAID license key on it.  If you were only using the free version, then no problem, setup another flash and follow the procedure above.  If you had a Plus or Pro license, you will have to wait for a replacement license key file for the replacement flash drive, since it is 'keyed' to the GUID of that flash drive.  You cannot assign the drives or run the procedure, until you have a new flash drive correctly prepared, and containing the new key file.  You will need to email Tom with an explanation, and request a key replacement.  Please see "If my flash drive dies or is lost, will I lose my license?"  He is usually very quick with replacements.

 

Other than the (lengthy) parity rebuild, are there any other forseeable issues?  I.e. can I just assign all of the known good drives at random and start the parity calc?  As long as I'm sure about which is the parity drive, is there any risk to data?

No parity calc needed, if you run the procedure above.  So long as you identify the correct parity drive, then there is no risk to data.

 

2) let's say that I'm not 100% sure which drive is parity.  But I know all of the non-parity drives were in-use in the array prior to the hardware crash (by in-use, I mean assigned in the working array full of data - not "in-use" meaning actively being written during the hardware failure).  I would guess that it's safe to presume that the only drive WITHOUT a filesystem is the parity disk?

That is not a completely safe assumption.  Parity is XOR'd across all of the data drives plus the parity drive, and in certain circumstances with an even number of drives, it is possible to have a pattern of bits in the early sectors that could closely approximate the start of a Reiser file system, enough to fool a file system identifying tool.  What you can assume is that the parity drive is the largest drive, or one of them if there are multiples of the largest size.  Then you could individually try to mount a Reiser file system on each drive, then check for good directories, and that should clearly identify which drives are data drives.

 

You really should have a backup of your flash drive, and a printout or screen capture or notes of your drive assignments, showing a table of drive serial numbers matched to unRAID disk numbers.

Excellent.  Thanks for the prompt response.

 

As for the flash drive, we happen to have 2 'empty' servers from Tom kicking arround awaiting prep for customer sites.  It's our own (older) system that has failed.  So we have a completely empty system c/w pro licenced flash drive ready to go.

 

Also, it's not that the flash drive is completely shot, it's just that I don't trust it's configuration data.  I'm not at all sure what has happened (as I'm not the only one who has tried to diagnose/recover this system), but the config on the flash does not match the drives that I KNOW are correct - size, model, and s/n are all way wrong.  As I'd said, we have a few servers arround in various stages of prep for customer sites - so there's a range of possibilities on why the config data is bad.

 

However, the nature of the MB failure assures me that the parity and data drives have not been touched other than initial spin-up and ID.  And, at first glance (I'll certainly double check), there was only one drive where a reiser-fs filesystem was not detected - and it was the drive which SHOULD have  been the parity drive.

 

So, I'll follow the Trust My Array proceedure (actually, I had tested this some time ago on a 'bench' system just to make sure I understood it) and we'll see what happens.

 

Thanks again.

However, the nature of the MB failure assures me that the parity and data drives have not been touched other than initial spin-up and ID.  And, at first glance (I'll certainly double check), there was only one drive where a reiser-fs filesystem was not detected - and it was the drive which SHOULD have  been the parity drive.

Odds are high you got it right.  If you are unsure, just leave it un-assigned when you initially start the array.  If all the other disks mount properly, then the remaining disk was the parity drive for sure.

 

Then, stop the array, assign the parity drive, and proceed with the trust-my-array procedure.

So, I'll follow the Trust My Array proceedure (actually, I had tested this some time ago on a 'bench' system just to make sure I understood it) and we'll see what happens.

 

Thanks again.

You are welcome.  Make sure you get the confirmation message in response to the "mdcmd set ... 99" command between pressing the button labeled "restore" and subsequently starting the array by pressing "Start".