Unmountable drive after power outage.

[BorisBee]

I had a sudden power failure and after powering back up my docker containers would give an execution 403 error and my array was doing a parity check automatically. I googled a bit and it seemed that the cause could be from corrupted or docker image that can no longer be found such as if it was split up on several disks and that you should try to do a clean reboot of the system and that might solve it.  So I did a clean reboot after pausing the parity check and when the server came up disk2 is now unmounted and says "Unmountable: Wrong or no file system". 

 

I am wondering what the recommended steps to do.  Is there a way to force mount the disk and have it check the parity, do I need to format the drive and then rebuild parity after adding it back to the array, or is there another solution?

 

*Edit* I also am realizing now that the server is reporting I have no docker containers anymore.  I hope this isn't as bad as it sounds to me
 

I've attached the diagnostic files below.

 

Thanks.

nas-diagnostics-20230701-1939.zip

Edited July 1, 2023 by BorisBee

[BorisBee]

I ran xfs_repair -n on the drive while in maintenance mode and it came back with several issues that it wants to fix. I may run that and see if that lets me mount the disk and worse case just format and rebuild parity if someone doesn't have another solution.

[BorisBee]

Ok I ended up running xfs_repair -L and the disk will now mount in my array.  I do have some files in lost+found but it's not too many.  My question now is if I run a parity check will those files be replaced? and I noticed that many of the files in lost+found are named with a number and not the actual filename.  Is there a way to find out what the original filename was?

 

I'm going to prioritize getting this server on a UPS so I don't have any more sudden shutdowns.

Edited July 2, 2023 by BorisBee

[itimpi]

When you run the xfs_repair parity is updated in real-time with the results of the repair so parity cannot help with recovery.  Files /folder in the lost+found folder are ones where the repair process could not retrieve all the path information and has assigned a cryptic number instead.   You can only figure out the original names by manually examining the contents (the ‘files’ command can help to get the file type (I.e. extension) to see if you can work out what they were.   In most cases it is easier to recover files from backups (if you have them). 

[BorisBee]

Ok thanks for the information.  I'm currently running a parity check and it's about 50% done but I noticed that my sync errors corrected jumped up to 521884 from about 135.  What exactly is the parity check doing? My array seems otherwise fine other than missing a few files from the corrupted disk.  Luckily I have a list of files that were on that disk and I will compare it with the disk afterwards to find out exactly what's missing. The rest of the files seem to be there and are able to be browsed.