unraid newbie 55

Yes - confirmed same order on zpool status as in the main tab of unraid. Problem solved! On reflection, I don't think I get much value from unraid itself. All of the above seems to have been an unraid bug which I have been dealing with through the command line. I mainly use unraid because SpaceInvaderOne has some good tutorials e.g. latest one on sleep states. I wonder if the power issue would have caused the same drama in ProxMoxx. In future, I will try to leave the unraid platform

OK - I think it is all fixed. Could you please look at the logs to confirm? Thanks unsas-diagnostics-20240102-1750.zip

OK - some good news. I took the advice of the first response above and created a 'new config', preserving all assignments. The server can start now and mount the problem pool. I was able to access the data via the SMB share. However, I have to manually import the zpool after reboot and the pool is still degraded (currently resilvering). It looks like one of the drives is listed as unavailable. Perhaps this is the one the removed from the pool after unraid disabled it. The drive still exists - how do I add it back in the pool? Thanks Console: unsas-diagnostics-20240102-1438.zip

I just finished running SMART extended self-tests on all 20 problem drives which contain the lost ZFS data. There were loads of errors on all the drives but the test corrected all the errors, reportedly. However, above issue continues after a reboot and rerunning zpool import etc. SMART reports attached. unsas-smart-20240101-1117.zip unsas-smart-20240101-0915.zip unsas-smart-20240101-0919.zip unsas-smart-20240101-1116.zip unsas-smart-20240101-0916.zip unsas-smart-20240101-0841.zip unsas-smart-20240101-1115.zip unsas-smart-20240101-1046.zip unsas-smart-20240101-0923.zip unsas-smart-20240101-0952.zip unsas-smart-20240101-1112.zip unsas-smart-20240101-1111.zip unsas-smart-20240101-0505.zip

root@UnSAS:~# zdb -l /dev/sdd1 failed to unpack label 0 failed to unpack label 1 failed to unpack label 2 failed to unpack label 3 root@UnSAS:~# zdb -l /dev/sde1 failed to unpack label 0 failed to unpack label 1 failed to unpack label 2 failed to unpack label 3

root@UnSAS:~# fdisk -l /dev/sde Disk /dev/sde: 2.73 TiB, 3000592982016 bytes, 5860533168 sectors Disk model: ST3000NM0063 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: F3DDF53C-A043-40A8-B2F8-0A7E916D7D04 Device Start End Sectors Size Type /dev/sde1 64 5860533134 5860533071 2.7T Linux filesystem

root@UnSAS:~# fdisk -l /dev/sdd Disk /dev/sdd: 2.73 TiB, 3000592982016 bytes, 5860533168 sectors Disk model: ST3000NM0063 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 71A5CF4C-DCBE-4C23-A150-E6D805698D52 Device Start End Sectors Size Type /dev/sdd1 64 5860533134 5860533071 2.7T Linux filesystem

Yes - I must have rebooted at least 10 times over the last 4 months since the pool was created. It mounted every time until I now started the array after unassigning 2 drives. I see there is a 'no refunds' policy from unraid. Quite disappointing because I really don't know how I killed the ZFS pool.

I created the pool using the GUI, 2 groups of 10 devices. Z-2. Should I try the above suggestion re new config?

OK, thanks. I already rebooted a few times and nothing changed. The data was not critical but it still annoying to have lost it. In terms of what caused this, it all started with a hardware issue. I had used SATA power extensions to split PSU SATA cables from 3 to 8 connections. That set up is fixed now - all drives are powered either directly from the PSU SATA cables or via a MOLEX 1 to 4 splitter (4 splitters running from 4 MOLEX male connectors from one PSU MOLEX cable, 16 drives). Please let me know if that should fix the power issues I was having. Due to the power issues, Unraid has disabled one drive. I therefore started the array with one drive unassigned. Another disk was then disabled so I removed that one too. After doing that, Unraid screwed up and would not start the array due to an 'invalid config'. It thought there should be 30 disks not 20. It seems like this is at least partly an Unraid bug. I understand ZFS is new to Unraid and therefore unreliable. However, in future I want to be able to depend on the array not to lose data in this way. Should I ask for a refund for the expensive Unraid license and just use TrueNAS Scale instead? That seems to be a safer option and it is free as well. Perhaps Proxmox would be better, as the plugins did not work for me when I tried TrueNAS (also, it would not spin down the drives when idle). Thanks for your help with this

Nope: root@UnSAS:~# zpool import -D no pools available to import Have I lost the data?

root@UnSAS:~# zpool status no pools available root@UnSAS:~# unsas-diagnostics-20240101-1325.zip

Here it is: Those three pools are unrelated to the SAS pool which has the problem. The 20 disks in that SAS pool do not show in the above import report. The main screen is attached in case that helps. unsas.pdf

OK thanks. Appreciate the honesty!

Yes but I am worried that will lose the data. Is it safe to do that with ZFS?