Hi all,

 

Long time user of Unraid. Never really posted much on the forums but I'm really in a bad situation and need some advice.

 

Had minor issue a few days ago where web interface locked up and was unable to access any network shares. I'd saved diagnostics to the flash drive and pulled it out of the server and into the laptop to have a look what was happening. By this time it was getting late and I'd decided to leave it for the next day. Anyway, a few days went past before I had chance to have a look due to various reasons.

 

Now here's the (not) funny bit. When I've gone back to the laptop, the flash drive is missing. After much hunting and cursing it turns out my partner has reformatted for other purposes it as she thought it was our spare stick. :'(

 

I don't have a backup of my config. Is there any way to get my server back online without losing the data on the drives?

 

I've reformatted the flash, reinstalled unraid but I'm not sure how to proceed. To add to matters, My parity drive and one of my data drives are identical so i'm unsure how i'd tell these apart. The machine was put together a few years ago so I'm not sure which drive would be in which slot.

 

Thanks in advance,

 

Jason

 

 

Do you have a copy of the key file?

 

Do you have a recent syslog saved anywhere? We can get your drive assignments from there assuming you haven't change them since taking the log.

 

If not, the usual advice is to avoid assigning any drive to parity. You don't want to accidentally have a data disk overwritten with parity.

 

If you assign all drives to data slots, then if everything is OK you should have only one drive listed as unmountable or unformatted. That would be the parity drive. And you can browse the other drives to see what's on them if you want to assign certain folders/files to certain disk slots.

 

Your data should be safe as long as you don't overwrite any of it with parity.

I do have the key file. I don't have a recent syslog unfortunately.

 

I have assigned the drives as you mentioned and tried to start the array however the web interface has now been stuck on 'Mounting disks....' for over 10 minutes and appears unresponsive.

 

I can telnet into the machine

See v6 help in my sig for how to get diagnostics from command line.

Sorry trurl! That was very amateur of me. In my panic i completely forgot to attach the log you guys need to actually help

tower-diagnostics-20160910-0254.zip

Have you done a memtest recently?

I have not ran a memtest since the first time I built the machine. I've left it on since your post and no errors have been found.

Try setting up the flash again.

Right, I've re-created the flash from scratch.

 

I've also dug through some old emails and found an old screenshot which leads me to believe I know what the parity drive is.

 

To be safe, I decided to repeat the steps above and assign all drives to data.

 

As soon as i tried to start the array, it gets stuck at mounting disks and the web ui became unresponsive again.

 

I have attached another diagnostics report.

 

I presume one of the drives must be faulty however they have all passed the smart test upon boot.  I'm not sure not to proceed now.

tower-diagnostics-20160910-0559.zip

Disk4 is making unRAID crash, you need to run xfs_repair.

Johnnie isolated your bad disk for you => what I'd do now is a New Config assigning all of the disks EXCEPT disk 4 and the disk you THINK is parity to the array ... then Start it and confirm that all of the disks are good [Do NOT format any disks if it shows any unmountable or unformatted disks].

 

Assuming all disks look good; then Stop the array; assign your parity disk; and then Start the array and let it do a parity sync.

 

Once that's done, you can then attach disk 4 as an "unassigned device" and see if you can recover the data from it.

 

You can try to repair the disk while maintaining parity, doing like this:

 

- new config and assign only both 4tb Seagates as data disks

- start the array, the unmountable one is parity

- do another new config and assign all disks, don't forget to trust parity

- start array in maintenance mode, repair disk4

- if repair is successful start array normally and do a parity check, because you started with parity unassigned it will find and correct a few sync errors

How long should xfs_repair take usually for a 2TB drive? It's been running for hours.

Just to emphasize the point, don't miss the "... don't forget to trust parity ..." comment in Johnnie's outline of the steps.

 

The actual "trust parity" option is a checkbox that says "parity is already valid" => which SHOULD be true since you clearly weren't running the server without the flash drive.

 

How long should xfs_repair take usually for a 2TB drive? It's been running for hours.

If it's looking for a secondary superblock it can take several hours, up to the same time as full disk scan.

How long should xfs_repair take usually for a 2TB drive? It's been running for hours.

 

Also, if you're repairing an unassigned disk you have to use the partition, e.g.:

 

xfs_repair /dev/sdx1

 

Obviously, parity won't be maintained like this.

Hi Johnnie,

 

When you say use the partition, how do I identify this as I may have done this wrong?

 

I ran the command 'xfs_repair /dev/sdg'. It returned 'Sorry, could not find valid secondary superblock' eventually

 

I have assigned both 4tb drives with a new config and established that cache is the drive I expected it to be.

 

I'm worried about starting array with parity assigned as even after checking the box to trust parity it still warns me data will be deleted from that drive when the array is started.

Hi Johnnie,

 

When you say use the partition, how do I identify this as I may have done this wrong?

 

I ran the command 'xfs_repair /dev/sdg'. It returned 'Sorry, could not find valid secondary superblock' eventually

 

I have assigned both 4tb drives with a new config and established that cache is the drive I expected it to be.

 

I'm worried about starting array with parity assigned as even after checking the box to trust parity it still warns me data will be deleted from that drive when the array is started.

In your case, sdg is the device, sdg1 is the first (and should be only) partition, which is what you want to use.

 

Just ran the command

 

ERROR: The filesystem has valuable metadata changes in a log which needs to

be replayed.  Mount the filesystem to replay the log, and unmount it before

re-running xfs_repair.  If you are unable to mount the filesystem, then use

the -L option to destroy the log and attempt a repair.

Note that destroying the log may cause corruption -- please attempt a mount

of the filesystem before doing this.

 

Should I run with -L? I presume the will affect integrity of parity if I do? Previous attempts at mounting this disk through the web interface didn't go so well so I'm not sure trying to mount it is such a good idea

 

 

Should I run with -L?

 

Yes

 

I presume the will affect integrity of parity if I do?

 

Using -L doesn't have anything to do with maintaining parity, running xfs_repair (in write mode) on the device (sdX1) will always make your parity out of sync, to maintain parity on need to use the mdX device in maintenance mode, see my post in reply #11 above.

johnnie / trurl / gary

 

Thank you guys so so much for all of your help. I've repaired the disk and managed to mount it. All data appears to be in tact and I have a parity check running now.

 

Cannot begin to thank you guys enough for all of your help. Absolutely fantastic.

 

Going forward, I'm now off to research a way to automatically back up my config to prevent anything like this happening in the future.

 

Thank you all again.

Going forward, I'm now off to research a way to automatically back up my config to prevent anything like this happening in the future.

Community Applications plugin has a feature that will backup your flash to your server. Of course you have to have your server booted up in order to access that backup.

 

The main thing to beware of with a backup of your flash drive is be careful that you don't restore a copy that doesn't match your current drive assignments. There has been more than one case of a user who upgraded parity, reused old parity as data, then later restored an old flash backup that still had his old parity (now with data on it) as the parity drive. After booting unRAID began to write parity over his data on the old parity drive. Your drive configuration is stored in a file named super.dat. If ever in doubt you can delete that file and unRAID will let you reassign all your drives.

 

You can of course put your unRAID boot flash in your PC and copy its contents to a folder there.

 

Your flash drive can be accessed over the network. It is the share named flash. You can copy it to your PC that way.

 

One more thing about super.dat. It also stores the started/stopped status of your array. If you copy your flash over the network with the array started, then later use that backup, unRAID will think you have booted from a condition that was not stopped and will start an automatic correcting parity check due to unclean shutdown. You can still access the flash share after stopping the array, so you should stop before copying your flash over the network.

 

 

Going forward, I'm now off to research a way to automatically back up my config to prevent anything like this happening in the future.

Of course you have to have your server booted up in order to access that backup.

Technically no.  The destination can be another smb share on a different computer (or anything mounted via Unassigned Devices)

The main thing to beware of with a backup of your flash drive is be careful that you don't restore a copy that doesn't match your current drive assignments. There has been more than one case of a user who upgraded parity, reused old parity as data, then later restored an old flash backup that still had his old parity (now with data on it) as the parity drive. After booting unRAID began to write parity over his data on the old parity drive. Your drive configuration is stored in a file named super.dat. If ever in doubt you can delete that file and unRAID will let you reassign all your drives.

.

.

.

One more thing about super.dat. It also stores the started/stopped status of your array. If you copy your flash over the network with the array started, then later use that backup, unRAID will think you have booted from a condition that was not stopped and will start an automatic correcting parity check due to unclean shutdown.

The backup that CA makes renames that file so its not going to be an issue.  (Also creates a text file with the drives assignments current as of that backup)