(SOLVED) Several disk and ATA bus errors after fixing an unmountable drive

[leorait]

Hello there everyone. I'm experiencing my first big batch of problems with my NAS, so i'm here asking for a little bit of help.

My system is around 1 year old and it is a basic storage server for my small office with an light VM for basic tasks. The problems started back in mid december with the big thunderstorm season, after a powersurge fried my ups and led to some unclean shutdowns of the machine in the following weeks.

 

After an unclean shutdown due to a power outtage in 01/06, i booted up the machine and the system wouldnt find one of the disks. This problem was easily solved by switching the hard drive power cable, resulting in the system finding the drive and starting the array normally.
I Got a new UPS the next day, and the machine ran smoothly for a couple days, but then out of nowhere in the midle of a work day we lost acess to the files in the NAS, the array was stopped at the system tab with the same disk labelled "unmountable: no file system"

This filesystem check with the -L flag fixed that granting me acess to the files in the array, and i though the system was running just fine, with the exception that a lot of files and folders were randomly scrapped into an "lost+found" folder wich are stil to be salvaged. The scheduled parity check started a couple days after. The parity check usualy takes 6~8 hours, but when i got to check up the machine on the next day the system prediction was around 28 days, and i could hear the hard drive bay of the case making some noises. In the log i could see that the noises where in sync with the "ATA bus error" messages, afraid this could physically dammage the disk i end the parity check, and for the last 4 days we've been using the NAS normaly and i don't know how to proceed.

How do i know this one drive should or not be replaced? What is the reason behind this problem with the parity check? What can i do with the best interest of not losing any data?

Attached to this post there is an Syslog right after the attempted parity check and an overall diagnostics. Thanks in advance!

 

 

 

 

syslog.txt

drv-0-diagnostics-20210121-1743.zip

Edited January 27, 2021 by leorait
Problem solved

[JorgeB]

Looks more like a connection problem, replace cables on disk1.

[leorait]

On 1/22/2021 at 4:50 AM, JorgeB said:

Looks more like a connection problem, replace cables on disk1.

 
That hit right in the bullseye 🎯

I Could only manage to go pick up a couple of new sata cables today, replaced them and did a parity check that ran smoothly in under 6 hours.

I Can't thank you enough for the help! I would've easily replaced a disk before thinking in the cable itself!

One last question before tagging it as solved, is there any way to automatically manage all the files in the "lost+found" bin? it happened just in the day that i archived all of 2020 files, so theres a loooooot of random named folders and files

[JorgeB]

10 hours ago, leorait said:

is there any way to automatically manage all the files in the "lost+found" bin?

Not that I know of.

[itimpi]

10 hours ago, leorait said:

is there any way to automatically manage all the files in the "lost+found" bin

I am afraid this is a manual process.

 

For folders that have lost their names it tends to be relatively easy by examining their contents!

 

For files that have lost their names it is much harder.  You have to decide if they are important enough to justify the effort involved. If you think it is then the Linux 'file' command can be of use in at least determining what type of content each file has (and thus probably the file extension that you want). 

[leorait]

Well then, at least apparently I didn't lose any important files, so for the manual labor of recovering them.

Again, thank you all for helping!