Rinny

I think I may be able to recover 10TB of data. 🤞. I should probably delete all the ExoDos/RetroeXo files and redownload them after everything is copied... it's ~1.6TB as a set.

I have a paid version from years ago that's still works well. Will try the rebuild onto the physical then.

@trurl & @JorgeB - I wanted to check if the parity was actually holding valid data. Using xfs_db -r /dev/md7p1, I looked at inode 128. Even though the drive wouldn't mount, the directory structure returned a (good) status for the root entries. Since I couldn't see files in the GUI, I ran a raw search on the emulated partition for known file extensions (.mp4, .png, etc.). The terminal returned clear file paths and executable headers from my shares. Seems like the data is there and being correctly calculated by parity? The 'Fatal Error 117' appears to be a metadata issue preventing the mount, but the raw data is intact? I have a new 18TB drive ready to go. Should I proceed with the data-rebuild onto the new physical drive first and then attempt xfs_repair on the physical disk? I've read that trying to perform complex xfs_repair on an emulated drive is not as stable.

I actually disabled every VM and Docker that would use the Array when disk 6 was deactivated. I wanted to reduce the risk as much as possible. For the most part, the only apps that are on the mirrored cache nvme drives were running (bitwarden, swag, etc). should i try force log zeroing? "xfs_repair -L /dev/md7p1" ?

Thanks. I did send the broken Disk 7 to Kotor data recovery today, awaiting a free eval. Will await for others about on alternative ideas if there are any. Thanks for the help @trurl .

I was thinking about what you mentioned earlier today: *Emulated disk7 is unmountable. When disk6 became disabled, it would be emulated while the array was still started, up until you did New Config. Emulated disk6 would have been written to, at least the initial failed write and maybe more. So the array could be out-of-sync with physical disk6, which means it can't accurately emulate disk7" Would reverting from the flash backup to before when disk 6 had to be emulated allow disk 7 to be mounted? Or would the array still be out of sync with the initial failed write?

I'm thinking about restoring the config from 12/29 and using Disk 6. The initial problem was with Disk 6 generating crc errors until Unraid removed/deactivated it from the array. I didn't think it was the controller at the time so I purchased a new 26TB drive instead. The array was running on depreciated mode while the new drive was being delivered. I also purchased new mini SAS to Sata cables just in case. When the new drive arrived, I used the onboard mobo SATA to pre-clear it which took 112 hours. The major issue happened when I swapped Disk 6 with the new drive and reconnected all the drives to the new cable, I broke the L connector on Disk 7 (ruining all my plans to copy the files from emulated disk 6 to it) so I swap the new drive back with Disk 6 and then swap the new drive with Disk 7. After getting to Unraid (I didn't start her array), the new pre-cleared drive, now connected to the LSI HBA, started getting CRC errors that I realized the controller is bad. So with the realization that disk 6 is still working perfectly, except Unraid removed it from the array, I thought about using parity + disk 1-6 to recover disk 7 onto the new 18tb drive I purchased today (not the 26tb one I precleared). The flash backup from 12/29/25 should contain the old config where disk 6 wasn't removed from the array and Unraid not emulating disk 6? Would that resolve the issue where we can't get disk 7 emulated now?

I did, but the page just refreshes and doesn't do anything else. Did the new diagnosis log provide any information? I still have a flash backup from 12/29/25 before all these issues. If I need to revert, what files are needed to be replaced for the array configurations?

Here it is. unraid-diagnostics-20260128-1834.zip

Check Filesystem Status xfs_repair status: Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... clearing needsrepair flag and regenerating metadata sb_icount 109504, counted 32 sb_ifree 295, counted 29 sb_fdblocks 1768782218, counted 4394060169 - 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 - agno = 15 - agno = 16 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 2 - agno = 1 - agno = 3 - agno = 11 - agno = 5 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 12 - agno = 13 - agno = 15 - agno = 14 - agno = 4 - agno = 16 - agno = 6 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... SB summary counter sanity check failed Metadata corruption detected at 0x49d6d5, xfs_sb block 0x0/0x200 libxfs_bwrite: write verifier failed on xfs_sb bno 0x0/0x1 SB summary counter sanity check failed Metadata corruption detected at 0x49d6d5, xfs_sb block 0x0/0x200 libxfs_bwrite: write verifier failed on xfs_sb bno 0x0/0x1 xfs_repair: Releasing dirty buffer to free list! xfs_repair: Refusing to write a corrupt buffer to the data device! xfs_repair: Lost a write to the data device! fatal error -- File system metadata writeout failed, err=117. Re-run xfs_repair. File system corruption detected.

@trurl https://pastebin.com/LahcVk1g - result of the check. At the bottom of the Check Filesystem Status, there's an option to fix, but I don't know if it'll break it even more so I'll await your input. i also have a flash backup from 12/29/2025 (before LSI HBA issue on Disk 6) if we need to reload the disk.cfg and other settings.

@trurl here's the diagnostics. unraid-diagnostics-20260128-1625.zip

Okay, here goes nothing. I'll post a diagnostic log once steps 3-4 is complete.

Friends - I have the new 18TB drive (for Drive 7) and new LSI HBA card (ran a quick SMART test to ensure no UMA CRC errors occurs on Drive 6). @trurl - To confirm the process before I proceed, I started created a new config and retained all. I replaced Disk 7 and checked both Parity Valid and Maintenance. Should I be concerned that the red text saying parity will be wiped is still enabled?

Thanks @JorgeB. I'm nervous as it is, so I think I'll get another drive to reduce the risk. I have a new drive arriving tomorrow. I'll check in then when all hardwares are in place for one final confirmation with the steps @trurl provided.