armagedon41

I am assuming that I need to just put back the original disk in to disk 3 (now showing as new) then run the New Config with preserve current assignments set to all? (this is where I an not sure) And then assuming the array does not auto start, start it back up and let parity check run then everything should be back up with all the data in on all the disks.

I was able to mount it in unassigned devices. not sure what the next step would be to get it back in to Disk 3 without it clearing it.

mc is moving that data over slowly, 75 MB/s so have about a day and a half, might try and stop and unassign before its all done, but I will update either after the copy or if I plan to live on the edge 😃

I stopped the copy and did a scan, same result, stuck in "continuing"

May have been more power issues, I mounted (read only) my old disk 1 to start to copy the files back to the new disk 1 using mc and it would start to copy then die a few seconds in and the parity would have tens of thousands of errors and the new disk 1 would even unmount on one attempt. So I swapped out the power supply completely and the copy is working this time. Once this copy is complete I will drop to maintenance mode and scan disk 3, in the meantime if any one has any suggestion if the scan does the same thing it would be appreciated.

yeah, left it overnight and the "...." just kept getting longer then finally jumped to the next line with "continuing". I had to cancel it. I tried it a couple more times with the same result.

That was from the ui, ran it straight with just deleting the -n

Scan on disk 3 is showing Phase 1 - find and verify superblock... couldn't verify primary superblock - not enough secondary superblocks with matching geometry !!! attempting to find secondary superblock... .found candidate secondary superblock... unable to verify superblock, continuing... ................................................................ unable to verify superblock, continuing... Disk 1 is looking good, mostly empty but expected. Still just that disk 3 oden-diagnostics-20250202-1138.zip

Ok changed the splitters and more or less in the same state At least no parity errors this time oden-diagnostics-20250131-2345.zip

Doing Molex to sata splitting, only have 2 2way splitters on different branches so it should be fine but I suspect the one has gotten loose over time so I will try and replace it just in case.

Yeah I have power splitters, I think that what was giving me the original intermittent issue with disk 4, so at the start of this I moved the power around to hopefully resolve the issue, which clearly did not work out. I have some new splitters on the way to at least swap out the one that I think was causing the issue.

Array is all sorts of unhappy As it sits, Disk 1 should be empty (mostly) as it was the drive I was syncing at the beginning of this but I have the original disk that I hope is readable. and disk 3 was good before all this chaos. If I could get 3 remounted with its content, I could format disk 1 (as since parity is written over there would be no rebuilding that directly) or remount the old disk 1 in the same way (if possible) then get parity up to snuff I would be good (all though I would most likely need some fixing of dockers and internal content but at least I would have the contents back). oden-diagnostics-20250131-0933.zip

I've been having on and off issues with my array for some time and things kinda came to a head today. I have been trying to get a parity check to complete so that I can do some playing with my disks and get things fixed but my disk 4 kept hard resetting causing the parity check to take forever. Then for whatever reason my disk 1 threw an error and went emulated so I ended up pulling the drive and replacing it, during the sync the disk 4 was causing the same issues and the sync was going to take several years. So I stopped the sync and the array, messed with the power cables of the drives as that is what I think was causing the issue, when I brought up the array multiple drives failed to mount, ironically not drive 4 but rather drive 1 (the one that was emulated) 3 and 5. Went to maintenance mode and scanned them, when the drives went back up 1 and 3 remained unmountable but 5 returned good. Unraid then decided to run the parity check and quickly disk 3 thew an error and went emulated as well.... I only have one parity drive so this is obviously not good. So now I have disk 1 and 3 unmountable, but the parity check ran and completed (quite quickly). I am currently assuming disk 3 is actually ok just with a read error during all the chaos, I also have the original disk 1 (currently not connected) which I believe is more or less correct but I haven't mounted it anywhere to check. At the exact second I have the array mounted in maintenance mode. Any clue on what my next steps should be to try to get these drives back up with the least amount of missing data. oden-diagnostics-20250131-0019.zip

For anyone that lands on my unfiltered stream of consciousness here is the official docs on redoing the docker image. https://docs.unraid.net/unraid-os/manual/docker-management/#re-create-the-docker-image-file

I'm an Idiot, after the mover finished ran the scrub again from the cache disk and saw there were no errors.... then I realised the first run was ran on the docker vdisk, reran that and yeah same errors. So switching appdata back to the cache share and moving, once that is all done I guess I am going to delete and recreate the docker image. Is there a definitive procedure for this? there a lots of posts and such on it but they are all slightly different.