Disclaimer: I'm not sure if this is the right channel to post this to, and if so, please point me to the right place.

I am very sorry for the large amount of text, but I'm in desperate need of assistance and having worked in IT for ~17 years I figured the more information the better, as that's how I'd prefer it. (And yes, those 17 years have sadly never dealt with how Unraid - and Linux systems when it comes more 'complex' storage setups more than mounting new storage - all raid/storage pool stuff I've only done in MS environs)
I'm very annoyed that I was using btrfs on my pool and wasn't made aware of btrfs device remove /dev/sdX /mnt/<poolname> until I started this endeavour, as far as I understand, it would've let me remove a device from my pool without needing to back everything up as it moves the data from the disk to be removed into the other disks in the mounted pool.

I am also veeeeeeeery new to Unraid, and I would understand if you call me a dumbass for these mistakes

So.. I messed up a bunch.

I only use SSDs in a pool, no array. I wanted to remove my NMVE disk from the pool because the I/O kept going bonkers and keeping my CPU at 100% at most times when doing stuff like qbittorrent/sonarr/bazaarr operations.

I tracked it down to being an issue of a combo of 5 x SSDs in a DAS + 1 NVME disk as one pool. The speed differences between the devices appeared to cause big I/O queues when doing operations like Tdarr conversion and writing it to the disks.

On top of that - since every single drive was in one pool, any I/O intense operation would slow down any docker service I used. Single example was that the Plex server was essentially inaccessible at times due to this.

I also failed to set up a decent redundancy - which was intended from the start (as in, no redundancy. Figured it was only media files so I could just as easily download them again thanks to Sonarr+Radarr) because I only intended to use it for Plex, but now having set up 15 different docker containers with services I want to use, I'd prefer not losing them.

I also read some info on pointing for example docker containers/appdata directly to a storage path would improve performance, i.e using /mnt/cache instead of /mnt/user/cache - Is this still relevant or is there a better approach?

I started trying to back up everything so I could perform this swap. I set up the 3 extra disks with enough capacity to hold all my data, and created a new pool from them, but one of the drives in the new pool failed in itself during this, and the original "mv "operation from "/mnt/storage" (my original pool) to /mnt/backup (new pool) failed.

I started using MV, but I'm pretty sure I mixed using mv from both /mnt/user/X and /mnt/poolname/X. At some point one of the MV operations failed (lets say to /mnt/backupX), I'm not sure why but that's not relevant anyhow. Other one to the second disk managed, but I was stupid enough to attempt to move more than what the disk had room for (my thought process was that it would stop when disk is full, it would simply stop - I didn't realise it would also write empty data that it couldn't move properly).

So I ended up with tons of 0 size files.

I was unable to continue using MV because of "folder not empty" errors. I then opted to do rsync to at least make sure the data was copied and not moved, but here was the big mess up: I didn't read up on how RSync deals with trailing slashes in source - from my understanding, trailing slashes would copy files under the source folder to the destination, no trailing would copy the folder itself. This ended up with me fucking up so many things (sometimes due to cancelling Rsyncs in progress, and a bunch of other reasons).

Now I have both duplicate files on one of the backup disks, and files with the same name with 0 bytes. In the original pool, I also have files that will still fit on the current pool, but possibly duplicate copies on one of the backup drives.

I'm just not sure how to properly deal with this. I've been made aware moving/copying from /mnt/user/* into /mnt/<storage/pool/array>/* might corrupt files, which is not unlikely that has already happened.

Due to my rsync mistake, I know have for example stuff in /mnt/backupx/torrents/torrents/X and /mnt/backupx/misc/torrents/ etc etc that all might be the same files, or just empty files with the same file name.

I currently have enough space on my main pool to remove several disks.
What I hope to accomplish in the end is this (not in actual order of operations):

• Remove NVME disk from my primary pool. This has already been done via btrfs remove device /dev/sdX /mnt/storage

• Remove 3 additional of my disks (I have free room in the pool for this already) from the pool using the same as above

• One of the 3 disks removed to be replaced with a new disk with larger capacity

• Create new pool with the 3 disks, set it as ZFS Z1 to have some sort of redundancy.

• Move data from main pool to new ZFS Z1 pool.

• Only move files to their correct locations and ignoring 0 byte files.

• Fix the mess I made - currently all of my shares have a "Some or all files are unprotected" issue.

• If main pool data doesn't fit into the new pool, then slowly but surely: Move data from "main pool" to "new pool" - when "main pool" has enough data free to remove another device, do another btrfs device remove until I'm left with only one disk

• move remaining data into new pool

• fix remaining issues that I've probably caused

Last inquiry: If I'm removing a device from a pool with btrfs - how do I progress from there? Do I need to stop array, unassign the removed device and start it up? Will it work since my pool was set to 6 devices due to the removal, or do I need to do a new config and keep current assignments? What do?!

Anyone who can assist?
What would be the best practice option for this?

Thank you for all your help:
Kind Regards

Lovemonkey

34 minutes ago, Lovemonkey said:

mixed using mv from both /mnt/user/X and /mnt/poolname/X

35 minutes ago, Lovemonkey said:

ended up with tons of 0 size files

This is the result of mixing drives/pools and user share when moving/copying files. Linux doesn't know these are different views of the same files, and will let you try to overwrite what you are trying to read.

You probably didn't need to work at the command line for what you were trying to accomplish. Unraid webUI will let you manage disks, pools, files and folders with less chance of making mistakes. Built-in file manager, for example, won't let you mix pools and user shares when moving/copying. Also, Unraid is not a general-purpose Linux OS, and trying to figure out Linux commands to use safely can get you in trouble if you have no experience with Unraid or Linux.

Attach Diagnostics ZIP to your NEXT post in this thread.

44 minutes ago, Lovemonkey said:

I also read some info on pointing for example docker containers/appdata directly to a storage path would improve performance, i.e using /mnt/cache instead of /mnt/user/cache - Is this still relevant or is there a better approach?

/mnt/cache/appdata, for example, might be useful. A better approach is to configure appdata user share as exclusive to cache or some pool, then just refer to /mnt/user/appdata.

Also, /mnt/user/cache is actually the path to a user share named cache, not a path to the cache pool.

41 minutes ago, trurl said:

/mnt/cache/appdata, for example, might be useful. A better approach is to configure appdata user share as exclusive to cache or some pool, then just refer to /mnt/user/appdata.

Also, /mnt/user/cache is actually the path to a user share named cache, not a path to the cache pool.

Ah yes I was uware of /mnt/user/cache, just wrote it all incorrectly - I meant pointing it to "/mnt/poolname/cache".

Can I accomplish the use of a "cache" device without assignment?

Could you also elaborate on "A better approach is to configure appdata user share as exclusive to cache or some pool, then just refer to /mnt/user/appdata."

Possible to get a step by step guide on this part?

plexerino-diagnostics-20251225-2126.zip

As requested

Edited December 25, 2025Dec 25 by Lovemonkey
fix text

36 minutes ago, Lovemonkey said:

"/mnt/poolname/cache".

That would result in a User Share called ‘cache’ and according to your diagnostics you do not have a User Share with that name. In addition the Unraid GUI should stop you from creating a user share with that name.

The Unraid ‘cache’ functionality is something you set at individual User Share level and can be directed to use any pool (and can be different pools for different User Shares). The pool name is irrelevant in this case. It just a legacy issue that the default name of the first pool is ‘cache’.

Just to summarize some of what your diagnostics tell us.

You have a single drive btrfs pool named backupx, a single drive btrfs pool named backupz, and a 6-disk btrfs pool named storage. No array.

All of these are connected USB except for the 3rd drive (nvme) in the storage pool. That nvme drive is not listed in btrfs-usage.

Your backupz pool is completely full.

You changed the default paths when you configured Docker. This is the relevant part:

DOCKER_IMAGE_FILE="/mnt/storage/docker/docker.img"
DOCKER_IMAGE_SIZE="50"
DOCKER_APP_CONFIG_PATH="/mnt/user/docker/"

So, docker.img is in the storage pool in a folder (user share) named docker. The default appdata path is also in the docker user share, but not necessarily restricted to the storage pool.

Looks like you may also have a user share named appdata. Possibly this was created by some templates that had that hard-coded, or possibly you specified that path yourself (instead of the docker user share you had configured) when you created some of your containers.

None of your user shares are configured to be moved, but most exist on multiple pools. Maybe you sometimes specified a pool path and sometimes specified a user share path when referencing them when you created your containers. Probably some of that is the result of trying to move things around.