gooner_47

Noticed 3 parity errors in one of the checks. Ran it a second time just to see if it was a one off occurence, but got the same 3 errors again. Ran it a third time with "Write corrections" checked but although during the check it said something along the lines of "Corrected 3 errors" (can't remember the exact wording now), it has finished with 3 errors again: nebula-diagnostics-20230609-0717.zip

This is a Robocopy issue. Ran the following command and all was fine, the destination folder didn't "disappear". Key part is the "/A-:SH" flag at the end. robocopy /E /R:5 /W:2 "D:" "\\NEBULA\Backups\FiLaptop\New 06-01-2023" /XF ._Thumbs.db /XD "D:\$RECYCLE.BIN" /A-:SH Stackoverflow post Blog post with the solution to "unhide" the folder again, and the flag to add to robocopy command to prevent this happening in the first place

So as a new server won't be on the cards for a while, I stopped all the docker containers, turned off autostart and rebooted in the hope this would help with any memory issues for the purposes of the diagnostics. I've managed to recreate the issue: Manually create an "06-01-2023" folder on the server, from within windows file explorer (in case the problem was folders created by Robocopy itself) Start robocopy running with robocopy /E /R:5 /W:2 "D:" "\\NEBULA\Backups\FiLaptop\06-01-2023" /XF ._Thumbs.db /XD "D:\$RECYCLE.BIN" Click in the command prompt to pause robocopy after a few minutes Open file explorer and finder, in both the "06-01-2023" folder is not visible However, entering the path manually in explorer does then display the contents of the folder Out of curiosity I then tried manually typing out the folder name "04-01-2023" from the original post where I first saw the behaviour and all of the contents were then displayed To test this the other way, I created a "Test" folder within finder on the mac, and that was immediately visible on both machines: So then I created another, empty folder on the Windows machine, closed explorer and reopened it and it was visible on both machines So then I started wondering if it was robocopy copying files into that directory that was "hiding" it Ran the following robocopy /E /R:5 /W:2 "D:" "\\NEBULA\Backups\Test created by the windows machine" /XF ._Thumbs.db /XD "D:\$RECYCLE.BIN" The icon for the directory then changed to indicate it was a hidden item (paler) Sure enough the next time I reloaded file explorer it was gone SO after all that debugging, it looks like the problem is that the result of running robocopy on a directory on the server, is to hide it from view on both windows and mac. Diagnostics here nebula-diagnostics-20230106-0710.zip At this point I'm not sure if this a robocopy "feature", or an Unraid issue. What do you think, is this something that warrants further investigation? I will do some more searching to see if others have encountered the same behaviour with robocopy - unraid or not.

Yeah. A new server is in the works. Is that what's caused this then?

nebula-diagnostics-20230105-1416.zip

Ran a robocopy command on a windows laptop to copy some files and directories to the Unraid server: robocopy /E /R:5 "D:" "\\NEBULA\Backups\FiLaptop\04-01-2023" /XF ._Thumbs.db /XD "D:\$RECYCLE.BIN" This completed successfully, but I cannot see this folder in either Windows explorer (from the same laptop that the robocopy command was run), or Mac finder: The files definitely exist on the server though: What could be causing this, is it a permissions thing? Edited to add - the reason for running this robocopy command is because the D drive on the Windows laptop out of the blue has become unable to create folders on it. The existing files are all still visible and you can open them, but you just can't edit or create anything new. Windows Error checking on that drive states "Repair this drive" so there is clearly something amiss which I am yet to investigate. First priority was just to get the files backed up in case the drives dies. I wonder if this is related somehow to not being able to see the folders in finder or windows explorer.

It passed the extended SMART test (attached) Samsung_SSD_870_EVO_500GB_S5Y1NF1R403281P-20221230-1044.txt

I've had the occasional notification about reallocated sectors on the cache disk recently. Is this anything to worry about? nebula-diagnostics-20221230-0921.zip

I mean the server/PC case. I shucked the drive, which Unraid didn't recognise at first, so then I had to tape up the sata pin 3 and it was fine.

Disk is in the case and parity is syncing, eta 2 days. Is this the check you're referring to?

Any general guidance on the best way to check this disk before I shuck it? I'm on mac and have the disk connected via usb still in its enclosure I've tried WD life guard and it does not find the drive (apparently a common problem) I've tried smartctl and it says "operation not supported by device" (apparently it can't be used on external drives) I've seen badblocks recommended very regularly but it seems it was not originally designed for large disk sizes and the -b 4096 flag won't help anymore I'm aware of Unraid's preclear but I'd need to have shucked the drive first to use that Edit - hmmm, just read about someone who ran badblocks over USB 3 on a 12TB drive and it took about a week. I only have USB 2 and a 20TB, it sounds like the time taken to do this with it still in the enclosure may be way too long, even if I could get it running. Should I just shuck it then use preclear in Unraid to check for drive problems?

20TB on the way (thanks credit card!). Pretty good deal on the WD Elements drives for any UK folks reading - £304.99, works out to £15.25/TB. https://www.amazon.co.uk/Elements-Desktop-External-Hard-Drive/dp/B09TYZCN61/ref=cm_cr_arp_d_product_top?ie=UTF8&th=1 Will this work? Turn off machine Remove old parity drive and replace with new 20TB on same sata port Start machine Stop array Assign 20TB to parity and let it build

"Errors occurred - Check SMART report" The report is attached, is this a replacement situation?! And if so, how urgently does this need to be done? Not a great time, money-wise, as I'm sure others are experiencing. Also (and as 6TB is now on the lower end of drive capacity) in the interests of future-proofing - considering the parity drive needs to equal or exceed the largest data drive, and space saving inside the chassis, should I buy as big as I can afford, to allow me to buy bigger data drives than just 6TB going forward? WDC_WD60EZRX-00MVLB1_WD-WXP1H643RWPX-20221101-1057.txt

Thanks. The error was after the SMART extended test. Would it give any useful information to run another extended test now and post more diagnostics? Should I be looking to replace this drive regardless?

Parity drive has a read error. Diagnostics attached. What's the best course of action? nebula-diagnostics-20221101-0718.zip

Bump on this. Just a suggestion for that setting in case it's any improvement, but if it's more suited as it is, then all good. Also just wanted to say thanks very much for guiding me through the process, very much appreciated.

What does Unraid set this to by default? As I’m pretty sure I wouldn’t have changed this setting without knowing the consequences. If it sets it to “Yes”, wouldn’t it make more sense, based on the advice in this thread, to default it to “No”?

Is that this setting? "Write corrections to parity disk"

I can see further research is definitely required as I believed differently. Parity seems less capable than I originally thought. With reference to my post above - does the parity only become corrupt if it runs after the drives corrupts? i.e. would parity be intact in the following situation: all drives fine (no corruption) run parity and it completes successfully drive x fails STOP parity from running (so it does not know about the corruption) In that scenario would parity have more success in rebuilding the drive? If so, is it almost better to only run parity checks on demand (as opposed to an automated schedule), when you know 100% there are no problems with any of your drives?

I do. They run on a monthly schedule The last successful run was on the 4th September. Is it possible that the 2 subsequent runs (by which point I believe the drive problems had surfaced) corrupted things?

I will educate myself further once I get past this problem. Particularly I would like to try and understand why parity in this case doesn't appear to have helped. I was under the impression that a parity drive (while absolutely not negating the need for a backup) was able to (effectively) bring a drive back from the dead with no loss of data, but this doesn't seem to be the case? I would like to know what I could have done differently, if anything, to avoid this situation.

Does that include the lost+found folder? Will that still be available after rebuilding disk 3 onto the new disk?

Ok, what are the steps to do this? Does this copy the emulated disk contents onto the new disk, making that disk 3? Is there a way to find out which data could have been lost, without mounting the old drive? How will I know without going to the actual overall share and attempting to open the file? Will it show, but just fail to open? Or will it not show at all?

nebula-diagnostics-20221019-1205.zip

Connected old disk 3, changed UUID in UD settings. Click Mount button and the button text changed to Mounting for about 5 minutes, but it didn't seem to work, button changed back to Mount again. Also noticed writes are increasing, is this expected?