UhClem

It's (Is it?) DejaVu all over again .... Link :) ::) This time, it's your DRU01 drive which SnapRAID has encountered a HARD error on, while verifying the correctness of the Content file it is in the final stage of writing to that drive I suggest that you rename that one snapraid.content.tmp file to "I_Contain_A_Bad_Sector"; all the other snapraid.content.tmp files you can delete. [If you were to delete the "bad-guy" one, then all of its sectors would be returned to the partition's free-space, and...

How can I replace disk4 without lose files on not bad sectors? Link Clarification: The Replacing instructions are intended for the situation where a WORKING disk is being replaced (typically with a larger disk). The Recovering section is for a failed/dysfunctional disk. [your situation]

[ I don't do "Troubleshooting" on Windows, so "Ask me no questions, and I'll ..."] But, I do advise you to use Windows Mount_Points [not Drive_Letters]. See https://learn.microsoft.com/en-us/windows-server/storage/disk-management/assign-a-mount-point-folder-path-to-a-drive An example framework might be: mkdir C:\Snap mkdir C:\Snap\Disk1 ... mkdir C:\Snap\DiskN ... mkdir C:\Snap\ParN

I don't do "Troubleshooting" on Windows, so "Ask me no questions, and ..." But, I do advise you to use Windows Mount_Points. See https://learn.microsoft.com/en-us/windows-server/storage/disk-management/assign-a-mount-point-folder-path-to-a-drive An example framework might be: mkdir C:\Snap mkdir C:\Snap\Disk1 ... mkdir C:\Snap\DiskN ... mkdir C:\Snap\ParN

Deleting the snapraid.content.tmp files on all drives and re-running the sync command lead to the same error message. [ Hereafter, BadGuy refers to "you know who" ...] Do: stat BadGuy (paste 8-line result in a code-block, in reply) Do a fsck on the filesystem where BadGuy lives. Was it clean? Or what got fixed? Verify, by: rm BadGuy stat BadGuy If it's still there, do mv BadGuy BadGuy.BAD Now, try again withscrub or sync

Your assessment, of the "problem", is correct (at a macro- (hand_waving-) level). The "solution" however, is more involved--isn't it always? :) and would be difficult to justify, especially nowadays. (You're a niche, within a niche.) Since you can't just add RAM (RasPi are soldered), the only other workaround is to completely restructure your disk/file layout. Instead of having a single partition/filesystem per HDD; and a single SnapRAID array, have N partitions per. Resulting in N arrays--operations...

Yes. I believe you'll find that xfs is a mature and robust filesystem.

It's not necessary to wipe the 8TB. You can preserve the unprotected data AND then add the new 4TB parity. Parity starts out less fragmented, and is less prone to fragmentation afterwards, when formatted as XFS. (I use mkfs.xfs -f -i maxpct=1 size=2048 [ -L label ] /dev/sdXn [optional label]) RSVP if you want/need any details.