DCWolfie

I did NOT got the time to take a backup. So no. I've stated that multiple times 😄.

Yeah. Correct, that was my next step, get the backup up and running 🥲. But doesn't help me now as I never got to that stage.

As mentioned, it only have 500MB out of ~120GB, so ye... good as empty. No I did not, only Docker. Yeah, that I know. That's not the issue as I guess you also understand. I'm guessing you don't have any suggestions for what I can do? Can't seem to find much online either.

Okey. Any suggestion what I might do, or am I dead in the water?

@trurl could force log zeroing be an option? -L flag

It had my complete appdata and system folder (about 120GB). Well, almost complete. I remember it was around 500MB left on Disk22 (which had the shares)

Same results

xfs_repair -v /dev/nvme0n1

Yeah. Correct. I want them both out. DISK 21 has seen better days and have disk speeds all over the place so that's going in the trash. Both. Doing it the GUI didn't give me the results so what I added in this post is from the cli.

I'd like to add that I can't seem to run SMART self tests either. However I can get my last run which I believe wasn't that long ago. I don't know much about this, but I can't see that there was anything wrong with the drive at that time. INTEL_SSDPEKKW128G7_BTPY63920H1J128A-20220717-1911.txt

So I recently realized I had my disks set up the wrong way (added SSD's to my array). I wanted to move everything off the cache drive back onto the array so I could reorganize everything. I switched from Cache: Preferred to Cache: Yes and invoked the mover. Then nothing happened... I then noticed i couldn't access the cache drive. I restarted the array back into maintenance and tried to fix the XFS filesystem with. This gave me "couldn't verify primary superblock - not enough secondary superblocks with matching geometry" and the results after was "Sorry, could not find valid secondary superblock". How can I try to fix this so I can get my cache data of the drive? I found this in the logs when starting up the array. Not sure if it helps: Jul 17 13:00:04 UnraidHub emhttpd: shcmd (55): mkdir -p /mnt/cache Jul 17 13:00:04 UnraidHub emhttpd: shcmd (56): mount -t xfs -o noatime,nouuid /dev/nvme0n1p1 /mnt/cache Jul 17 13:00:04 UnraidHub kernel: XFS (nvme0n1p1): Mounting V5 Filesystem Jul 17 13:00:04 UnraidHub kernel: XFS (nvme0n1p1): Starting recovery (logdev: internal) Jul 17 13:00:04 UnraidHub kernel: XFS (nvme0n1p1): Metadata CRC error detected at xfs_agfl_read_verify+0x27/0x56 [xfs], xfs_agfl block 0x3 Jul 17 13:00:04 UnraidHub kernel: XFS (nvme0n1p1): Unmount and run xfs_repair Jul 17 13:00:04 UnraidHub kernel: XFS (nvme0n1p1): First 128 bytes of corrupted metadata buffer: Jul 17 13:00:04 UnraidHub kernel: 00000000: 86 27 b9 af e8 f1 6b 8e fc ce db 83 12 58 bc 6d .'....k......X.m Jul 17 13:00:04 UnraidHub kernel: 00000010: 37 b8 9c f3 08 df 82 cd 09 02 c2 58 03 d4 d1 46 7..........X...F Jul 17 13:00:04 UnraidHub kernel: 00000020: 56 e0 07 f5 e8 84 79 da 99 b6 3e 21 51 2c 14 bd V.....y...>!Q,.. Jul 17 13:00:04 UnraidHub kernel: 00000030: 59 97 b8 37 5f c3 ea b2 41 5b 2a 00 7f fa 40 37 Y..7_...A[*...@7 Jul 17 13:00:04 UnraidHub kernel: 00000040: 82 f8 e6 30 4e 99 35 b0 03 78 ef f1 6b f8 dd 21 ...0N.5..x..k..! Jul 17 13:00:04 UnraidHub kernel: 00000050: 70 08 f2 9a 27 e9 95 a8 08 b6 a1 b8 5a 6f ba be p...'.......Zo.. Jul 17 13:00:04 UnraidHub kernel: 00000060: 4b ba 3e 97 83 e6 84 a6 ea e4 1b 04 2e ad d5 52 K.>............R Jul 17 13:00:04 UnraidHub kernel: 00000070: e5 42 f5 85 63 4d 65 f6 f0 66 bb f2 b5 46 43 31 .B..cMe..f...FC1 Jul 17 13:00:04 UnraidHub kernel: XFS (nvme0n1p1): metadata I/O error in "xfs_alloc_read_agfl+0x82/0xc0 [xfs]" at daddr 0x3 len 1 error 74 Jul 17 13:00:04 UnraidHub kernel: 00000000: f6 91 53 00 00 00 00 00 01 00 00 00 00 00 00 00 ..S............. Jul 17 13:00:04 UnraidHub kernel: XFS (nvme0n1p1): Internal error xfs_efi_item_recover at line 633 of file fs/xfs/xfs_extfree_item.c. Caller xlog_recover_process_intents+0xa6/0x268 [xfs] Attached diagnostics when the array is running. diag-mounted.zip

😬 so in order to be safe against those aspects the solution is backup backup backup? Yeah, 100%. Though, what I have on there is replaceable. Just a hassle to replace.

Ah, you're actually one of those who follows the rules of backup 😄. Yeah, I know. But right now, one step at the time. First I got to get this all up and running how I like then I'll look into remote/local backups. Thanks for the tip on Luckybackup thp, haven't heard about it before. Yeah, I kind of know the limitations. It's basically drive failures I'm worried about most, though those are defiantly important aspects I will need to look into in the future.

Ah! Gotcha, that makes sense. Yeah, I'm going to add it. Just forgotten it 😬. Aha. I feel that makes sense. Thanks a lot. I also would like to add that I've been thinking wrong about the appdata backup issue. I failed to remember that Unraid handles at which disk holds my data. I don't need to specify diskX. I could just backup /mnt/user/appdata and I would be fine. So yeah, I'll just keep continue using cache ☺️. Again, thanks a lot, to both of you.

Hm... I don't feel like I see that being the case here. As of writing I have just a small M.2 assigned to cache. It has ~5GB available space, while the array disk its caching has 500MB of data. Meaning my appdata lives on both disks (I do not have a minimum space set on the cache). So given it's either cache or array (if it has available space) shouldn't this have been moved over? Ah okey. That's good to know. I see, but how do those people handle backups like the one we're talking about? If it overflows the data would no longer only be on the cache disk and plugins like CA Appdata Backup don't allow to backup from array disks. Maybe they just don't do it? Absolutely. I got to get a bigger drive if I'm gonna use the cache. But wouldn't you just get the speed of the disk itself? Or is it some magic trickery Unraid does when it's within a cache pool?