trillium

Original array was 2 parity + 10 data Disk7 and 10 were 4TB drives replaced w/ 12TB drives. First drive was replaced using the 'safe method' from the link above (which is the drive that is now unmountable).

Safer method step 4 of Replacing Multiple Data Drives with a Single Larger Drive. Removed 4TB drive that was copied to disk7 from disk10 to replace w/ 12TB tower-diagnostics-20250201-1835.zip

Looking for recommendations for my path forward. Followed the below as I was going to replace 2 4TB drives with 12TB. https://docs.unraid.net/legacy/FAQ/replacing-multiple-data-drives/ For reference I'll explain what I've done so far and how I ended up in this state using the /mnt/dsk locations. 4TB drive - disk 7 Stopped array, powered down and replaced disk7 with a 12 TB. No errors on SMART and latest preclear scripts used (as recommended). Array started and rebuild commences. Rebuild finishes successfully. Executed the following rsync command: rsync -avX /mnt/disk10/ /mnt/disk7 This completes successfully. Stopped and powered down the raid, pulled the 4TB that was disk 10 and replaced it with another 12 TB. Upon array coming back online, the original 12TB (disk7) is in an "unmountable: wrong or no file system" state. The 12TB (disk10) mounted successfully. I ran xfs_repair on disk7 via the GUI with the array in maintenance mode. No luck (no superblocks found). So I have an unmounted 12TB (which has the contents of 2 of my 4TB drives), a 12TB drive that is online (with nothing on it), and the two original 4TB that have been pulled but still have the data on them (drives have not been plugged in anywhere else). What is my best path forward?

Wanted to toss up a hearty THANK YOU! I had seen Hoarder awhile ago but hadn't jumped in to getting it to work. Tried over this past weekend to get it working on my unraid server using the docker compose recommendation and couldn't get past issues with Chrome. Something in docker networking wasn't playing along well. I abandoned the effort and went with the community apps. Something I learned along the way - the default INFERENCE_CONTEXT_LENGTH (2048) doesn't handle some URLs and was causing errors in the Hoarder logs. Since I am running local oLLama, I bumped this up quite a bit and have gotten no failures on generating tags. It's an item of note - was getting about a 50% success rate on auto-tag generation prior to the change

Not sure if I am missing something obvious but I've had multiple back to back drive failures. Last week Disk 2 went into a disabled state. All attempts to remove from array, re-add failed. Drive was toast. Added a 6TB drive as parity, allowed it to rebuild, then re-assigned my old parity drive (after clearing it) to disk 2. Success. Woke up yesterday to finding that Disk 4 had gone into a disabled state. Did the stop array / disable / start array / stop array / enable / start array and left it rebuild overnight. Woke up to the attached. Disk 4 is disabled again. Attaching diagnostics in hopes someone can point out something obvious that I am overlooking at this point. Is it data corruption? Are my drives actually failing at this rate? I have a spare 6TB HD Red at the moment that I can put into Disk 4 slot and let it rebuild but I am hesitating because what if it causes another drive to disable. Item of note: This build has been running quite stable for several years and only started having disk problems when I started moving my media library over to the server and running Plex. Not sure if increased i/o was the trigger or not. tower-diagnostics-20230827-1013.zip

Running into a similar issue. Under previous downloads I'm getting the message "Book Persistence Disabled"