foo_fighter

I used:

ghcr.io/immich-app/postgres:16-vectorchord0.3.0-pgvectors0.3.0

data-root is docker setting, either a vdisk image (docker.img) or a directory. 

So apparently it's not possible:
 

 
Here's what I did:
Run the user.script to snapshots/syncoid from cache to Array 
 
Stop Array
Rename old cache pool to cache_old and mount with unassigned devices
Create a new single disk cache pool with zfs as the file system
Start Array
Format new Cache to zfs

 

 
 

 
Syncoid all datasets from cache_old to cache to preserve all snapshots:
 >syncoid -r cache_old cache 
rsync other files and non-datasets:
root@NAS:/mnt/cache# rsync -avuXizPh --stats /mnt/disks/cache_old/ /mnt/cache
sending incremental file list
.d..tpog... ./
>f+++++++++ docker.img
>f+++++++++ jwt-secret
>f+++++++++ oplog.sqlite
>f+++++++++ oplog.sqlite.lock
>f+++++++++ rsync.log
 
Double check all files made it safely
 
Stop the array Set the number of slots to 2 for cache 
Assign cache_old to slot 2 of cache
 
 
Note: it doesn't seem like you can select stripe or mirror like you can when you create a pool:

vs

 
but it eventually does show:

 
and
 
root@NAS:~# zpool status
  pool: cache
state: ONLINE
status: One or more devices is currently being resilvered.  The pool will
continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Sat Jan  4 12:48:17 2025
593G / 593G scanned, 314G / 593G issued at 3.65G/s
317G resilvered, 52.98% done, 00:01:16 to go
config:
 
NAME           STATE     READ WRITE CKSUM
cache          ONLINE       0     0     0
  mirror-0     ONLINE       0     0     0
    nvme0n1p1  ONLINE       0     0     0
    nvme1n1p1  ONLINE       0     0     0  (resilvering)
 
 
and finally:

 
 
 
 

Stopping and starting the array seems to have fixed the issue.

You don't really need to do anything. That's the beauty of UnRaid. The config is on the flash drive and is portable. 
However, I would suggest:
On the new system, make sure the devices show up in BIOS.
Run memtest on the new system to verify the ram.
If you're changing from non-UEFI to UEFI, you might need to rename the EFI- directory on the flash to EFI. 
After booting, you can re-run the sensors-detect for dynamix if needed

flash is under /boot. You may need to store files there and copy them to where they need to be on reboot using the /boot/config/go file.
For example:
#Copy bash profile
cp /boot/config/bash_profile /root/.bash_profile
 

The last steps are redundant if you're rebuilding parity anyway.
 
1) Change all my shares inclusion settings to write new data only to disk 5 & 6.
2) unbalance all 4x4TB drives (disk 1-4) 
I would modify step 2 slightly to not move, but copy the data so you have a backup
 
3) Initiate new configuration and unassign Parity 1 & 2 and assigning the new 20TB drive to be parity 1 and remove 4 X 4TB drives.
4) Let parity rebuild occur while I keep my old parity drives and 4 X 4TB drives off to the side.
5) Parity rebuild completes and I Preclear the old 12TB parity drives in unassigned devices and then add them to array when ready.
Triple check all data before pre clearing the old 12TB, since this is the last time you can go back to the previous config.
 
Let us know how it goes. 
 

Do you have it set up as a mirror? So 2 512GB drives would be 512GB total but mirrored on each drive(each drive has a copy of the same information).