wheel

Rebuild+sync starting now - thank you both so much for the guidance!

No SMART warnings on the dashboard, just general fear of a mostly-aged array, and yes, I absolutely misunderstood the New Config process if that makes the disabled Disk 1 unrecoverable even with the “old” parity back. I was mostly working off older posts (generally non-dual parity) that seemed to focus around using New Config to “trust” the old parity when no data changes had been made to the array, but it’s sounding like (by starting the process of upgrading the second parity disk but getting a disabled data drive during that second parity sync) I already broke Dual Parity when starting the new dual parity sync, there’s no getting Dual Parity protection back from the old 12tb Parity 2 drive, and my best shot at quickly re-establishing Dual Parity at this point is hoping cables from my LSI card to the five-drive hotswap cage containing the disabled Disk 1 were the issue - rebuilding Disk 1 using the current 16tb single parity is my only safe path there, and the added drive stress of syncing the new Parity 2 shouldn’t be much (or even any) riskier than just rebuilding Disk 1 in a first operation before separately syncing Parity 2 afterwards, right?

Thanks for the new plan! My only concern is how many older (6+ year) drives are in the array, which is what led to the dual parity setup in hopes of being ready for what feels like an inevitable two-drive failure some day when it takes over a day to rebuild any of the 12tb-sized disks. Just wanting to make sure I’m understanding before starting the rebuild - are you saying after replacing cables I should NOT mess with New Config and the old 12tb Parity 2, just turn it back on now as-is with the single 16tb Parity 1 intact, and use only that single parity to rebuild Disk 1 (having moved the new 16tb Parity 2 back into the system, being synced from blankness in the same rebuild operation)?

Post-errors, pre-shutdown diagnostics: tower-diagnostics-20260224-2106.zip

v6.12.14 I THINK I’ve figured out what to do through researching others’ posts in the past, but wanted to make sure before crossing a point of no return: Dual-parity setup. Had two 12tb parity drives going, and upgraded Parity 1 to 16tb last week. After that successful upgrade, I ran a non-correcting parity check on the mixed 16tb/12tb dual parity, which came back clean. No additional data was written to the array during or after this upgrade. Immediately following this successful upgrade and parity check, I replaced the other 12tb drive from the Parity 2 slot with a new 16tb drive, and started rebuilding parity on that drive. In the middle of that Parity 2 rebuild, one of my data disks threw up 4000+ sequential read/write errors, so I stopped the Parity 2 rebuild. Short smart test came back OK, but I don’t trust that data disk due to a number of factors, including age and heavy use, and can easily replace it with another. I have now removed the new 16tb Parity 2 drive and replaced it with the old 12tb Parity 2 drive that made it through the non-correcting parity check earlier today. The questionable data disk shows up in the array list, and the hover tab says “Disk disabled, content emulated,” as expected. It sounds like my next steps should be: -Change Parity 2 from “no device” to the old 12tb Parity 2 disk in the drop-down GUI menu -Tools -> New Config -> Retain Current Configuration: All -> Apply -Check “Parity is already valid and start the array” -Stop Array, Shut Down -Replace disabled HDD with backup replacement HDD (must be same size? Or could use larger replacement?) -Power On, Re-Assign replacement data HDD in drop-down GUI menu -Start Array, Let Data Drive Rebuild, Non-Correcting Parity Check ….and then I’ll return to my original process of upgrading that 12tb Parity 2 to 16tb afterwards. If I am missing any steps or should be doing anything different, any confirmation or guidance would be really appreciated!

Great - thanks for the confirmation! I successfully set up a new flash drive (manual setup, copying entire flash drive backup config directory over, overwriting a fresh 6.11.5's existing config directory files), started up the system, got into the GUI, and re-assigned all the parity drives ("disk0" as Parity 1 and "disk29" as Parity 2) and data drives that had been added/replaced since the last full flash drive backup two years ago. So far, so good! One weird problem I can't find a solution for by searching: on the main page, I get the "Invalid, missing, or expired Registration Key" error. Under the registration tab, all of my old registration info (including the former Flash GUID) is listed. Other posts discuss a "replace key" button that might be greyed out, but the only option available (and it's not greyed out) on my screen is a button that says "Fix Error." I'm inclined to just click "Fix Error" under the assumption it will reconcile my new Flash GUID with the old one (since it's an original license from 2011 and has never been moved to a second flash drive since original purchase), but feel so close to the finish line here that I wanted to double-check before potentially messing something up that I can't search and find a confirmation post for (nothing showing up in results for "Fix Error" specifically, as a button). I'd greatly appreciate anyone putting my mind at ease here before clicking the "Fix Error" button, and am incredibly thankful for confirmation I figured out the Parity 1 / Parity 2 situation through guesswork!

Lots of regret here, but making the best of what I have to work with: Recently (within the past 24 hours) completed a parity check on an Unraid 6.11.5 box. Zero errors, all good. Went to replace an old drive with a larger, new drive, and system did not recognize the new drive. Tried a second new drive, and system would not boot. Tried to change boot order through BIOS, and could not select the flash drive as a boot option. Plugged the flash into my laptop, and it’s not recognized at all - totally dead. I should be good on the key replacement (have a full flash backup from a couple of years ago, after upgrading to v6), but I’m struggling to find records identifying which two drives are Parity 1 and Parity 2. The flash backup had different (smaller) Parity 1 and Parity 2 drives at the time. I DO have a diagnostic file from ~18 months ago that was captured at a time where Parity 1 and Parity 2 were the drives that are currently being used as Parity 1 and Parity 2. Through the diagnostics, I’ve managed to figure out which two drives are the parity drives - but is there a way to confirm through the diagnostics which was operating as Parity 1 vs. Parity 2? My best guess currently is that “disk0” (in an array naturally going up to disk18) was Parity 1, and “disk29” (with no disks identified between 19 and 28, with cache apparently being listed as 30?) was Parity 2, but I don’t feel confident about this at all without checking here first. tower-diagnostics-20240620-1904.zip

Volume UNRAID created 6/30/2012 1:40pm Volume Serial Number is *** Windows is verifying files and folders... File and folder verification is complete. Windows has scanned the file system and found no problems. No further action is required. (Disk space allocation numbers)

I *was* able to access the unraid webpage when upgrading to 6.12.13, and I pulled diagnostics as a safety measure then. The boot process is hanging at some point (I didn't see how far it got on screen before hanging at the flashing cursor). I can't really pull any new information without a reboot or power down (and maybe not even then). Thanks for the response!

I have an older unraid box that's been used only as cold storage (with regular parity checks and drive replacements) and almost never connects to the internet (can't think of any times this decade outside of unraid upgrades in recent years). As a result, it rarely gets updated. I wanted to add the Parity Tuning Plug-In to this box so I could pause and resume with shutdown during extremely long parity checks (dual parity, larger drives). I checked the forum announcements in the 6.9s and 6.12s and didn't see any obvious warning flags about upgrading directly from 6.8.3 to the newest release through the unraid GUI, so I backed up my flash drive, pulled diagnostics, and gave it a shot. Upon installation, the unraid GUI prompted me to reboot my system. I did that, and the screen's hanging at a blinking cursor. I'm thinking the boot order may have been changed by my BIOS automatically, but I'm hesitant to just shut it down at this point without checking in here first. Is there some massive mistake I could have made in upgrading directly from 6.8.3 to 6.12.13, (that I should try and fix now before shutting down or rebooting to try and change my boot order in the BIOS)? Thanks so much in advance for any guidance anyone can provide!

I have no idea how exactly the move went down during the "windows lag" moments, but the "missing" subfolder (and all of its subfolders) straight moved into another (adjacent) subfolder. I'm double-checking to make sure everything is still there, but this is looking more and more like user error solved by find /mnt -iname maneuver. Thank you SO MUCH for steering me in that direction!

I can probably guess at a decent amount of them, but one for sure should be (edited)/

I think I may have done a poor job of explaining myself initially: HD is gone. The files within HD are gone. The file size of those files (multiple terabytes on each of the 18 drives in the array) is still being taken up by SOMETHING, but I can't see or access it anymore because the folder named "HD" (which once contained them) has disappeared from both my user shares (where it was a subfolder of "features") and from each individual disk it was on (where it was a subfolder of each disk's "features" folder). This occurred immediately after trying to move a folder from "HD" to "HD-2" (both within the "features" folder) on a user-share level (not share-to-disk or vice-versa) using Windows SMB. Windows SMB lagged, which I didn't realize, and I tried to move the same folder a second time. When Windows caught up with itself, I saw the folder get "moved" twice (two successful moves of the same folder). After that, /HD (in user shares and on disks alike) was invisible and inaccessible from SMB. I really wish I had captured diagnostics at this point, but I've had so many "inaccessible" SMB issues that were resolved by a simple reboot over the years that I just went ahead and did that instinctively. Once the system was back up and running, with "HD" still missing, I went through Telnet/MC (which has previously shown me folders that had been "missing" over SMB until the SMB issues were resolved) and saw the "HD" folders were ALSO gone on that side of things (i.e., not JUST an SMB issue), I came here with my questions. I had no idea one folder being moved in a weirdly-Windows way could potentially lock me out of a massive pile of data, but here I am, confused and lost, really hoping I'm not about to spend the next few months moving what folders did survive over to some other storage solution before I have to wipe all 18 of these drives and start replacing things from scratch. Edit: for additional clarity, I'm guessing this is dozens of TB total. My "free space" in the array has been stable at about 10TB free both before and after the "disappearance" of the HD folder, which is what gives me hope that its contents are salvageable (since they still seem to exist somewhere across the drives, if only as dead bits taking up space).

total 40

Bad news: after upgrading ram and running xfs_repair without -n on every drive (and receiving the following results on each drive), (edited) is still missing on SMB and Telnet (but its data is still clearly "taken up" from the array"). Diagnostics attached (and I also have a set of diagnostics I took before exiting maintenance mode for the repairs, if that helps). Any more ideas would be seriously appreciated! Getting a little more concerned that something weird happened, now. Thank you both for all of the help so far! Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 2 - agno = 0 - agno = 1 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done