JorgeB

The best way to try and recover some data might be a file recovery tool like UFS explorer or similar, I'm afraid that xfs_repair might just move almost everything to lost and found, I would try that last, or on a cloned disk. If that's needed you could boot with a v6.10 Unraid flash on a different PC if you have one available, trial key will do, until we find what's causing the issues with the gen8 Microserver don't run v6.10 there.

I would recommend anyone running a HP MicroServer Gen8 to not update for now, there have been multiple cases of filesystem corruption after updating, with both XFS and btrfs, looks like the hardware doesn't get along with the new kernel, not clear if it's all models in general or just some specific BIOS/CPU combos, so if anyone updated without issues please post here. Edit to add: The ones I found so far were all using Xeon CPUs with Intel VT-D (IOMMU) enable, I have a suspicion the problem is related to this, it's causing some kind of kernel memory corruption so if you're running one of these with a Pentium or I3 CPU (or a Xeon with VT-D disable) you might be OK. See here for latest update on this: https://forums.unraid.net/topic/123620-unraid-os-version-6100-available/?do=findComment&comment=1129501

You can't restore a config with a trial key, only a paid one.

You should update the LSI firmware, it's using a very old version that had this issue, and likely a driver change also correct this now. To fix the problem you can do a new config: -Tools -> New Config -> Retain current configuration: All -> Apply Check that all assignments are correct, both array and cache, check "parity is already valid" and start the array

Edit config/ident.cfg on the flash drive and change USE_SSL from "yes" to "no", then reboot, then access the server by IP.

You're not the first to have issues with this server, looks like it doesn't work well with the newer kernel, I would suggest going back to v6.9.2 now, unfortunately some data loss might already happened.

When checking in Windows best to do it with dispart, disk management isn't always the best when there are very small partitions, this is the same flash drive:

Problem is not with cache, it's the single btrfs array disk, disk5, that's the one that should be converted to XFS or encrypted btrfs, note that both require formatting the disk, i.e., all data there will be lost.

Assuming the pool is redundant when a device fails/drops offline the other one continues to work, it's important to monitor the pool to act as soon as possible, if the device failed you can replace it to rebuild the mirror, if it dropped offline you can bring it online then run a scrub to put it back in sync, note that btrfs can only repair the data if COW is enable, for any shares with COW disable, and this was the default for the system and domain shares before 6.10.0, it won't be able to sync the dropped device to due NOCOW also disabling data checksums. There are some corner cases, especially when a device drops and comes back online that can cause some issues, but that can usually be solved, and that's also why it's important to monitor the pools, to minimize that risk.

You're welcome, make sure you monitor the pool so you'll be notified if there are more issues with one of the devices dropping.

Changed Status to Closed Changed Priority to Other

Check that it's well seated, if errors persist you likely have a bad CPU.

This is a known issue when there's only one assigned btrfs array drive, it creates an invalid btrfs filesystem on parity that confuses the pool, workaround is to convert that disk to xfs like the other ones, add more btrfs array devices or if you want one but only one btrfs array device use encrypted btrfs.

Yes, also disable spin down for that disk before doing it.

Please post the diagnostics.

It's normal, SAS SMART is very different from ATA SMART, from my experience, which is not much with SAS, you wan to monitor "Elements in grown defect list" and "total uncorrected errors" which should both stay 0.

You can copy locally using for example midnight command or the new Dynamix File Manager, you'd need to start the array so: You can also share the UD disk over SMB and copy to another PC, you can check the first couple of posts in the UD support thread for some help with that. If you rebuild now using the old disks you won't get the data that you see in UD, only the one showing in the emulate disks, if that's what you want I can also post instructions.

Just assign it to the pool.

Once a disk is disabled is must be rebuilt, if the emulated disk is now mounting and contents look correct you can rebuild on top, assuming the disk is healthy. https://wiki.unraid.net/Manual/Storage_Management#Rebuilding_a_drive_onto_itself

More likely to get help if if post in the existing support thread:

Kernel is very different, so there could be changes that affect that, IMHO it would be worth trying, or GPT with a single partition, GPT doesn't require more than one, depends on how it was created.

Maybe because it's GPT? @GrimDdid you try booting UEFI with an MBR partition?

Correct

What I wrote above... Both disks look healthy.

Disk5 read errors are logged as a disk problem, you should run an extended SMART test. Also goo idea to run memtest on the RAM.