jon00001

Just a quick update: after your comments on what the parity disk was most likely built against I added the semi-failing 0.5TB back to the array, with the completely failed 1TB disk still emulated. Started with "parity is valid" and voila, most (possibly all) of the data I was expecting was restored. The only downside is that there were so many errors along the way that the repair process lost a lot of directory paths so all of the recovered data ended up in lost+found and there's going to be a lot of work to put things back in the right places. Still, very nice not to have completely lost stuff like old photos etc. Yes those should be backed up not just on a single resilient array. That's next! Thanks for your help - little bit of beer money sent.

Current situation is 1TB drive exhibiting "click of death" so that's probably gone now. 0.5TB disk might be recoverable to some extent but it's not looking great for my data resilience :-/ If I had my time again I'd buy the additional 4TB disk before juggling everything into the new array and write to that instead of the ancient decaying disks I had. Oh well!

I think the errors were coming from the SMART errors on the two old disks, but unraid did eventually say it'd successfully built parity.

Ah that's a shame - would be nice to have that written to the parity disk as it's only valid when paired with those now-unknown disks :-) Do you think there's only one parity check here? I'm not clear about the "disk-check" items - they're in the "Parity Operation History" so maybe they're a flavour of parity check too? If not it looks like I only actually managed to build it once, so that would have been with all three of the original three data disks and I'll need at least two in place to rebuild from.

Ok thanks. I was just hoping there's some sort of a block on the parity disk with the identifiers of data disks it was built from or something like that, to take the guesswork out of this.

Yes sadly it looks that way, I wonder when it got wrecked. Do you think there's anything I can do at this point? E.g. maybe the parity is still valid for the 2TB + 1TB + 0.5TB data array? I don't even know how to see how much data is on that parity disk to give a clue about whether it's holding anything useful.

Oh, if I hover over the red cross I see this, so it is being emulated. Sorry, that wasn't clear to me. However, most of the shares are still missing so I suppose parity just isn't really valid any more.

It started ok but I don't see the emulated Disk2 - am I looking in the right place?

Well, it's done a lot of something! Phase 1 - find and verify superblock... bad primary superblock - inconsistent filesystem geometry information !!! attempting to find secondary superblock... ......found candidate secondary superblock... verified secondary superblock... writing modified primary superblock sb realtime bitmap inode value 18446744073709551615 (NULLFSINO) inconsistent with calculated value 129 resetting superblock realtime bitmap inode pointer to 129 sb realtime summary inode value 18446744073709551615 (NULLFSINO) inconsistent with calculated value 130 resetting superblock realtime summary inode pointer to 130 Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... Metadata corruption detected at 0x451560, xfs_agf block 0x1/0x200 Metadata corruption detected at 0x4820b8, xfs_agi block 0x2/0x200 bad length 217859487 for agf 0, should be 244188659 bad uuid 94a6d5ee-7aec-4060-9802-e7ca6eaeac77 for agf 0 bad length # 217859487 for agi 0, should be 244188659 bad uuid 94a6d5ee-7aec-4060-9802-e7ca6eaeac77 for agi 0 reset bad agf for ag 0 reset bad agi for ag 0 Metadata corruption detected at 0x44dcc0, xfs_agfl block 0x3/0x200 Metadata CRC error detected at 0x452dbd, xfs_bnobt block 0xa06d1a8/0x1000 btree block 0/21027381 is suspect, error -74 bad magic # 0xa302c6f0 in btbno block 0/21027381 Metadata CRC error detected at 0x452dbd, xfs_cntbt block 0x9af9890/0x1000 btree block 0/20312850 is suspect, error -74 bad magic # 0xbfa05f9e in btcnt block 0/20312850 Metadata CRC error detected at 0x4954ad, xfs_rmapbt block 0x7285958/0x1000 btree block 0/15010603 is suspect, error -74 bad magic # 0x139f6cf1 in btrmap block 0/15010603 bad rmapbt block count 0, saw 401 Metadata corruption detected at 0x46c430, xfs_refcountbt block 0x30/0x1000 btree block 0/6 is suspect, error -117 agf_freeblks 245497315, counted 0 in ag 0 agf_longest 246060876, counted 0 in ag 0 agf_btreeblks 410, counted 0 in ag 0 Metadata CRC error detected at 0x48b3cd, xfs_inobt block 0x1194060/0x1000 btree block 0/2304012 is suspect, error -74 bad magic # 0x30c8da19 in inobt block 0/2304012 Metadata corruption detected at 0x46c430, xfs_finobt block 0x20/0x1000 btree block 0/4 is suspect, error -117 bad inobt block count 5, saw 1 agi_count 52480, counted 0 in ag 0 agi_freecount 53, counted 0 in ag 0 agi_freecount 53, counted 0 in ag 0 finobt sb_icount 0, counted 64 sb_ifree 0, counted 63 sb_fdblocks 976277675, counted 732089029 root inode chunk not found Metadata corruption detected at 0x488b3f, inode 0x81 dinode Metadata corruption detected at 0x488b3f, inode 0x82 dinode Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 UUID mismatch on inode 128 UUID mismatch on inode 129 UUID mismatch on inode 130 UUID mismatch on inode 131 UUID mismatch on inode 132 UUID mismatch on inode 133 UUID mismatch on inode 134 UUID mismatch on inode 135 UUID mismatch on inode 136 UUID mismatch on inode 137 UUID mismatch on inode 138 UUID mismatch on inode 139 UUID mismatch on inode 140 UUID mismatch on inode 141 UUID mismatch on inode 142 UUID mismatch on inode 143 UUID mismatch on inode 144 UUID mismatch on inode 145 UUID mismatch on inode 146 UUID mismatch on inode 147 UUID mismatch on inode 148 UUID mismatch on inode 149 UUID mismatch on inode 150 UUID mismatch on inode 151 UUID mismatch on inode 152 UUID mismatch on inode 153 UUID mismatch on inode 154 UUID mismatch on inode 155 UUID mismatch on inode 156 UUID mismatch on inode 157 UUID mismatch on inode 158 UUID mismatch on inode 159 UUID mismatch on inode 160 UUID mismatch on inode 161 UUID mismatch on inode 162 UUID mismatch on inode 163 UUID mismatch on inode 164 UUID mismatch on inode 165 UUID mismatch on inode 166 UUID mismatch on inode 167 UUID mismatch on inode 168 UUID mismatch on inode 169 UUID mismatch on inode 170 UUID mismatch on inode 171 UUID mismatch on inode 172 UUID mismatch on inode 173 UUID mismatch on inode 174 UUID mismatch on inode 175 UUID mismatch on inode 176 UUID mismatch on inode 177 UUID mismatch on inode 178 UUID mismatch on inode 179 UUID mismatch on inode 180 UUID mismatch on inode 181 UUID mismatch on inode 182 UUID mismatch on inode 183 UUID mismatch on inode 184 UUID mismatch on inode 185 UUID mismatch on inode 186 UUID mismatch on inode 187 UUID mismatch on inode 188 UUID mismatch on inode 189 UUID mismatch on inode 190 UUID mismatch on inode 191 UUID mismatch on inode 128 cleared root inode 128 UUID mismatch on inode 129 cleared realtime bitmap inode 129 UUID mismatch on inode 130 cleared realtime summary inode 130 UUID mismatch on inode 131 cleared inode 131 UUID mismatch on inode 132 cleared inode 132 UUID mismatch on inode 133 cleared inode 133 UUID mismatch on inode 134 cleared inode 134 UUID mismatch on inode 135 cleared inode 135 UUID mismatch on inode 136 cleared inode 136 UUID mismatch on inode 137 cleared inode 137 UUID mismatch on inode 138 cleared inode 138 UUID mismatch on inode 139 cleared inode 139 UUID mismatch on inode 140 cleared inode 140 UUID mismatch on inode 141 cleared inode 141 UUID mismatch on inode 142 cleared inode 142 UUID mismatch on inode 143 cleared inode 143 UUID mismatch on inode 144 cleared inode 144 UUID mismatch on inode 145 cleared inode 145 UUID mismatch on inode 146 cleared inode 146 UUID mismatch on inode 147 cleared inode 147 UUID mismatch on inode 148 cleared inode 148 UUID mismatch on inode 149 cleared inode 149 UUID mismatch on inode 150 cleared inode 150 UUID mismatch on inode 151 cleared inode 151 UUID mismatch on inode 152 cleared inode 152 UUID mismatch on inode 153 cleared inode 153 UUID mismatch on inode 154 cleared inode 154 UUID mismatch on inode 155 cleared inode 155 UUID mismatch on inode 156 cleared inode 156 UUID mismatch on inode 157 cleared inode 157 UUID mismatch on inode 158 cleared inode 158 UUID mismatch on inode 159 cleared inode 159 imap claims inode 160 is present, but inode cluster is sparse, correcting imap imap claims inode 161 is present, but inode cluster is sparse, correcting imap imap claims inode 162 is present, but inode cluster is sparse, correcting imap imap claims inode 163 is present, but inode cluster is sparse, correcting imap imap claims inode 164 is present, but inode cluster is sparse, correcting imap imap claims inode 165 is present, but inode cluster is sparse, correcting imap imap claims inode 166 is present, but inode cluster is sparse, correcting imap imap claims inode 167 is present, but inode cluster is sparse, correcting imap imap claims inode 168 is present, but inode cluster is sparse, correcting imap imap claims inode 169 is present, but inode cluster is sparse, correcting imap imap claims inode 170 is present, but inode cluster is sparse, correcting imap imap claims inode 171 is present, but inode cluster is sparse, correcting imap imap claims inode 172 is present, but inode cluster is sparse, correcting imap imap claims inode 173 is present, but inode cluster is sparse, correcting imap imap claims inode 174 is present, but inode cluster is sparse, correcting imap imap claims inode 175 is present, but inode cluster is sparse, correcting imap imap claims inode 176 is present, but inode cluster is sparse, correcting imap imap claims inode 177 is present, but inode cluster is sparse, correcting imap imap claims inode 178 is present, but inode cluster is sparse, correcting imap imap claims inode 179 is present, but inode cluster is sparse, correcting imap imap claims inode 180 is present, but inode cluster is sparse, correcting imap imap claims inode 181 is present, but inode cluster is sparse, correcting imap imap claims inode 182 is present, but inode cluster is sparse, correcting imap imap claims inode 183 is present, but inode cluster is sparse, correcting imap imap claims inode 184 is present, but inode cluster is sparse, correcting imap imap claims inode 185 is present, but inode cluster is sparse, correcting imap imap claims inode 186 is present, but inode cluster is sparse, correcting imap imap claims inode 187 is present, but inode cluster is sparse, correcting imap imap claims inode 188 is present, but inode cluster is sparse, correcting imap imap claims inode 189 is present, but inode cluster is sparse, correcting imap imap claims inode 190 is present, but inode cluster is sparse, correcting imap imap claims inode 191 is present, but inode cluster is sparse, correcting imap - agno = 1 - agno = 2 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... root inode lost - check for inodes claiming duplicate blocks... - agno = 0 - agno = 2 - agno = 1 - agno = 3 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... reinitializing root directory reinitializing realtime bitmap inode reinitializing realtime summary inode - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... disconnected dir inode 2147483776, moving to lost+found Phase 7 - verify and correct link counts... resetting inode 131 nlinks from 2 to 3 Note - stripe unit (0) and width (0) were copied from a backup superblock. Please reset with mount -o sunit=,swidth= if necessary Maximum metadata LSN (1272041629:1621315789) is ahead of log (1:38). Format log to cycle 1272041632. done

Ah yes that's quite right - no "parity valid" option this time. Ok, started in maintenance mode and did a filesystem check on the missing Disk2 and it came back with this. I haven't clicked "FIX" yet - should I?

Ah, thanks - this then? But it's not available at the moment because the array was started normally, not in maintenance mode. So should I stop the array and restart in maintenance mode? And with "parity valid" as well?

Sorry, I'm not sure what you mean - Disk2 is "Not installed" now, and the "Check" button in Array Operation looks like it'll check all of the attached disks (including parity?). But it looks like that would check all disks except Disk2 because it's not attached. What am I missing?

Ok, done! sarah-diagnostics-20250922-1554.zip

Ok just checking because I've been down a lot of dead ends before now... Started the array with "parity valid" and "maintenance mode" checked. Message was "all disks must have their original content" rather than "parity will be overwritten". Stopped the array and unassigned the 4TB (new) disk that I'm hoping to rebuild onto Array Operation section is now this - presumably I want to tick "Yes I want to do this" and then start the array with "Maintenance mode" not checked?

Thanks Jorge. Am I waiting for something to sync after starting with "parity valid" and "maintenance mode", or just start & then stop straight away?

Ah, that's my fault for trusting AI. I did try a few things before the new config, reassured by the suggestion that the "superblock" on each disk would retain its actual status. I wanted to rebuild the 4TB data disk from parity plus the 2TB data disk, which are the two original correct ones from before the failure of the 1TB disk. So in an ideal world, the 4TB disk would end up with whatever was on the 1TB disk.

Thanks for looking - here's Main

Hi, new unraid user here and I might have got myself into a bit of a situation... Previous NAS was a Windows Home Server which had been running for ages but suddenly died (motherboard failure I think) so I decided to take the leap and get a Terramaster F4-425. Wasn't delighted with the standard TOS because it didn't offer standard filesystem with resilience and after the WHS failure I was pleased that all of my files were easily readable when the drives were mounted in another machine. Wouldn't have fancied trying to recover from a dead RAID array or whatever. So unraid with xfs, JBOD + parity seemed like a good solution. I didn't have a lot of disks to play with but managed to get enough free space in the existing WHS disks that I was able to juggle the files across to the unraid array. WHS disks were 4TB, 2TB, 1TB, 0.5TB but at first the 2TB was mounted externally with the last of the files to copy across, so unraid had 4TB parity plus 1TB + 0.5TB data. The data disks were both showing some SMART errors (and had 15 years uptime) but the array built successfully. After copying everything across I added the 2TB drive to the data array and waited for parity to rebuild. Following that I removed the 0.5TB disk which was showing a lot of errors by now. At this point I get less certain about what happened but I think parity was rebuilt after I removed the 0.5TB disk, but the disk continued to be shown as "missing". I foolishly trusted Copilot to guide me through removing the disk properly and tried a few new config / retain settings, new config / abandon settings and so on. I think this eventually ended up with just the 4TB parity, 2TB and 1TB data disks, and parity again rebuilt. At this point, the 1TB disk also failed I think but I have a parity disk I thought, it's all going to be ok! So where I am now is a 4TB parity disk, 2TB data disk and a new 4TB data disk and trying to rebuild from parity onto that new 4TB disk. So far I've failed at that - the array will come back up but the 4TB data disk is empty and most of my shares are gone (presumably the ones that were on the other data disks). Problems: If I tick "parity is already valid" the message is "Parity valid requires ALL disks to have their original content" (difficult because one of them's dead) whereas if I tick "maintenance mode" without "parity is already valid", the message is "Parity disk(s) content will be overwritten" which doesn't sound good. Sorry for the lengthy post but it's been a bit of a winding path getting here. Is there any hope at this point? sarah-diagnostics-20250921-1716.zip