gooner_47 Posted October 19, 2022 Author Share Posted October 19, 2022 nebula-diagnostics-20221019-1205.zip Quote Link to comment
JorgeB Posted October 19, 2022 Share Posted October 19, 2022 Old disk appears to be in really bad shape, so for now we can forget about it, disconnect it from the server and rebuild disk3 using the new disk. After that is done you can try using ddrescue on the old disk to see if it can recover some data, but it looks unlikely. Quote Link to comment
gooner_47 Posted October 19, 2022 Author Share Posted October 19, 2022 3 hours ago, JorgeB said: rebuild disk3 using 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? Quote Link to comment
JorgeB Posted October 19, 2022 Share Posted October 19, 2022 2 minutes ago, gooner_47 said: Ok, what are the steps to do this? With the array stopped assign te new disk as disk3, start array to begin rebuilding. 3 minutes ago, gooner_47 said: Does this copy the emulated disk contents onto the new disk, making that disk 3? Yes. 3 minutes ago, gooner_47 said: Is there a way to find out which data could have been lost, without mounting the old drive? Only if you have a list of what should be there. 3 minutes ago, gooner_47 said: 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? Any missing data will not show in the share, it might be in the lost+found folder with a generic name. Quote Link to comment
gooner_47 Posted October 19, 2022 Author Share Posted October 19, 2022 18 minutes ago, JorgeB said: Yes. Does that include the lost+found folder? Will that still be available after rebuilding disk 3 onto the new disk? Quote Link to comment
JorgeB Posted October 19, 2022 Share Posted October 19, 2022 Yes, everything you see in the emulated disk will be in the rebuilt disk, you should really try to understand how Unraid and parity work to emulate a disabled disk, it would make things much easier. Quote Link to comment
gooner_47 Posted October 19, 2022 Author Share Posted October 19, 2022 (edited) 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. Edited October 19, 2022 by gooner_47 Quote Link to comment
JorgeB Posted October 19, 2022 Share Posted October 19, 2022 On 10/18/2022 at 3:12 PM, JorgeB said: That's what parity is for, but since the emulated disk had a lot of filesystem corruption it suggests parity wasn't 100% valid. Quote Link to comment
JorgeB Posted October 19, 2022 Share Posted October 19, 2022 Do you run regular parity checks? Quote Link to comment
itimpi Posted October 19, 2022 Share Posted October 19, 2022 3 minutes ago, gooner_47 said: 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? What parity does is bring a dead drive back in the state it was at when it went dead. If the drive was already corrupted then you will end up with a corrupted drive. Quote Link to comment
gooner_47 Posted October 19, 2022 Author Share Posted October 19, 2022 3 minutes ago, JorgeB said: Do you run regular parity checks? 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? Quote Link to comment
gooner_47 Posted October 19, 2022 Author Share Posted October 19, 2022 11 minutes ago, itimpi said: What parity does is bring a dead drive back in the state it was at when it went dead. If the drive was already corrupted then you will end up with a corrupted drive. 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? Quote Link to comment
itimpi Posted October 19, 2022 Share Posted October 19, 2022 3 minutes ago, gooner_47 said: 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? Scheduled checks should still be run, but they should be set to be non-correcting. That way if you get any errors reported you can look into why and a mis-behaving drive does not corrupt parity. Correcting checks should only be run manually if you have corrected whatever may have caused errors during the non-correcting check. Quote Link to comment
JorgeB Posted October 19, 2022 Share Posted October 19, 2022 14 minutes ago, gooner_47 said: Is it possible that the 2 subsequent runs (by which point I believe the drive problems had surfaced) corrupted things? Yes, if they were set to correct the errors, also note that the previous check already found some errors. Quote Link to comment
gooner_47 Posted October 19, 2022 Author Share Posted October 19, 2022 2 minutes ago, itimpi said: Scheduled checks should still be run, but they should be set to be non-correcting. That way if you get any errors reported you can look into why and a mis-behaving drive does not corrupt parity. Correcting checks should only be run manually if you have corrected whatever may have caused errors during the non-correcting check. Is that this setting? "Write corrections to parity disk" Quote Link to comment
JorgeB Posted October 19, 2022 Share Posted October 19, 2022 Yes, that should be set to "no" Quote Link to comment
gooner_47 Posted October 19, 2022 Author Share Posted October 19, 2022 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”? Quote Link to comment
gooner_47 Posted October 21, 2022 Author Share Posted October 21, 2022 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. Quote Link to comment
JorgeB Posted October 21, 2022 Share Posted October 21, 2022 Just a suggestion for that setting in case it's any improvement It would be an improvement, I've made a request to see if it can be changed. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.