May 11, 20251 yr Community Expert Looks good! As for docker.img https://docs.unraid.net/unraid-os/manual/docker-management/#re-create-the-docker-image-file https://docs.unraid.net/unraid-os/manual/docker-management/#re-installing-docker-applications https://docs.unraid.net/unraid-os/manual/docker-management/#docker-custom-networks
May 12, 20251 yr Author Thank you I think the last question is about protecting the cache data. For the dockers I think I got it - the best thing is to map external array volume for dockers volume.
May 12, 20251 yr Community Expert 7 hours ago, OlegBudeanu said: the best thing is to map external array volume for dockers volume. I don't know what you mean by that but it doesn't sound like the best thing. If you are concerned about docker.img, it doesn't need to be backed up. In fact, we often recommend deleting and recreating. See my links above. If you are concerned about appdata, there is a plugin for that.
May 12, 20251 yr Author Thank you, yeah I was concerned about that also. I think I will need to check all the dockers to have proper "array" volumes. I think some of them are following bad practice having volume "inside" docker.
May 12, 20251 yr Community Expert 8 minutes ago, OlegBudeanu said: think I will need to check all the dockers to have proper "array" volumes. I think some of them are following bad practice having volume "inside" docker. There are 2 things that can cause problems. Any application writing to a path that isn't mapped to the host is writing to a path that is inside docker.img. This is a common reason for filling docker.img. It shouldn't grow except a small amount when adding a new container. Any container that has a host volume that isn't actual storage is accessing rootfs, which is the RAM set aside for the OS to run in. If you fill rootfs, the OS can't work. Actual storage are user shares, disks, pools, mounted unassigned devices or remotes.
May 12, 20251 yr Author Thanks for explaining As I understand, the best practice is to map any paths to array, rather than /mnt/user/appdata - that's how the data will be protected, but in case docker image gets corrupted - I will be able to restore containers with last configuration in minutes? I will be able to use appdataplugin for everything else, what is lightweight left in appdata on cache. Edited May 12, 20251 yr by OlegBudeanu
May 12, 20251 yr Community Expert 11 minutes ago, OlegBudeanu said: the best practice is to map any paths to array, rather than /mnt/user/appdata I would never consider mapping anything except application data to appdata. Often these mappings will have a container volume /config mapped to /mnt/user/appdata, for example. appdata is the "working storage" of each application. That is where the application stores its settings and maybe its databases. It isn't where the application is supposed to write downloads, access media files, etc. I map everything else to user shares rather than directly to specific array disks. Maybe that is what you meant. When we say array, we mean those disks that can be protected by 1 or 2 parity disks. User shares include array disks and pools, but each user share has settings that control whether and how it uses pools and array disks.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.