I had an unclean shutdown due to a power outage this morning and when I restarted the array, disk 5 showed as unmountable: no file system. I tried xfs_repair in maintenance mode, but it couldn't find the superblock because of a bad magic number. I'm not sure how to fix this. Any help is greatly appreciated. I've attached my diagnostics to help out.

hpdl380pg8-diagnostics-20230608-0932.zip

32 minutes ago, lostengineer said:

tried xfs_repair

Did you do this from the webUI or from the command line? Easy (and common) to get the command wrong. 

According to syslog it looks like you have formatted disk5. Since the array isn't started, can't tell if it is mountable now, but I would assume after format it would have a mountable empty filesystem.

14 minutes ago, trurl said:

Did you do this from the webUI or from the command line? Easy (and common) to get the command wrong. 

I used the command line because I couldn't find the webUI button for it. I was following the wiki instructions.

 

My exact command was 

xfs_repair -v /dev/md5

It had the comment about the primary superblock magic number then for the secondary block it just endlessly printed out "......" in the command line. Perhaps I didn't let it run long enough.

You are using an old version of Unraid, which has an old version of xfs repair.

3 minutes ago, trurl said:

According to syslog it looks like you have formatted disk5. Since the array isn't started, can't tell if it is mountable now, but I would assume after format it would have a mountable empty filesystem.

To be completely honest, that drive may have still not had any data on it since I formatted and installed it a few months ago. On the array webUI, it's file system shows as "auto" instead of XFS. That could also be part of the problem.

If you are sure it was formatted XFS, then the command line you used was correct.

 

Start the array in normal mode and post new diagnostics.

2 minutes ago, trurl said:

If you are sure it was formatted XFS, then the command line you used was correct.

 

Start the array in normal mode and post new diagnostics.

Here they are. It has also started a parity-sync/data-rebuild which will probably take about 7 hours. 

hpdl380pg8-diagnostics-20230608-1036.zip

Since disk5 is unmountable, it is rebuilding an unmountable filesystem.

 

After rebuild, try repair again. Be sure to capture the output so you can post it.

Parity and rebuild finished and were fine. I've started the xfs_repair again and will just let it run. A few posts online say it can take quite a while, so I'll update when I have the output.

For future reference, we usually recommend repair before rebuilding, especially if rebuilding on top of the same disk. Even better is to rebuild to a spare so the original disk is unchanged and provides another option for recovering data.

I tried running the xfs_repair, but every time my PC goes to sleep, the terminal resets so I can’t see the results of the repair. Is there a way to run it and log to a file?

 

I did actually try adding another disk to the array to put in place of the unmountable drive, but it also showed as unmountable.

5 hours ago, lostengineer said:

I did actually try adding another disk to the array to put in place of the unmountable drive, but it also showed as unmountable.

No reason to expect a replacement disk to be mountable if the emulated disk is not mountable. That is why repair before rebuild is the best way. The only thing that can be rebuilt is the contents of the emulated disk. How could it be otherwise?

Do you have backups? Parity is not a substitute. You must always have another copy of anything important and irreplaceable.

59 minutes ago, trurl said:

No reason to expect a replacement disk to be mountable if the emulated disk is not mountable. That is why repair before rebuild is the best way. The only thing that can be rebuilt is the contents of the emulated disk. How could it be otherwise?

I had assumed the disk being unmountable was a hardware issue, not an array issue. I guess that makes sense why the replacement drive didn't work either. I've started xfs_repair again. If the web terminal keeps resetting, I may have to setup SSH.

1 hour ago, trurl said:

Do you have backups? Parity is not a substitute. You must always have another copy of anything important and irreplaceable.

There's nothing important or irreplaceable on the server, so I don't have any data backups currently. I used to use backblaze when I had important documents saved.

 

I do have a backup of the Unraid flashdrive and my appdata though.

Ended up using SSH instead of the web terminal since it kept resetting. I'll update again once it has finished.

On 6/8/2023 at 10:46 AM, trurl said:

Since disk5 is unmountable, it is rebuilding an unmountable filesystem.

 

After rebuild, try repair again. Be sure to capture the output so you can post it.

Okay, I finally got it to complete and it ended with. 

................Sorry, could not find valid secondary superblock

Exiting now.

 

Honestly at this point, i'm fine with just sacrificing whatever data was on the drive to get my array back to being complete and fully mountable.

13 hours ago, lostengineer said:

Honestly at this point, i'm fine with just sacrificing whatever data was on the drive to get my array back to being complete and fully mountable.

You can just format the disk, other option would be to use a file recovery util like UFS explorer to see if it could recover the data.