Yes a more recommended approach for production apps is to let .ix-apps contain the base app installation and then use host paths to mount storage paths on separate datasets.
As for recovering from your current situation, it seems likely that if you reverted to a 24.04 boot environment, deleted ix-apps completely so it doesn’t cause conflicts with the migration script, and then upgraded to 24.10 again it should properly migrate your apps–but I haven’t tested anything like that scenario, so no guarantees.
official/community apps have mounts for config/data/etc that each app uses. Should be able to just copy, from shell, those to another pool. Then decide if you want to mount those as hostpath/binds to your apps. That way you always know where they live!
Too bad Truecharts apps didn’t do it that way, would have made migration away much easier!
FWIW, I think hiding the pool “ix-apps” dataset was perhaps not ideal. I understand it’s mounted in a strange place, but the issue is that there is now no visibility on its size in the GUI, or ability to delete it or replicate it.
To conclude this thread, you’re not supposed to use the hidden ix-apps dataset for permanent storage, and so you’re not supposed to back it up.
If you have important app data you want to keep, you’re supposed to configure your apps to use your own datasets, and then you can back them up as normal.
For my situation where I had to wipe and recreate my only data pool, it left me in a bad state where I couldn’t even install apps anymore (installing an app requires the docker service, but no UI to start it). So I ended up just installing the latest OS from scratch and reconfiguring everything from scratch. After starting a newly installed app, configured to use my own dataset(s), I just stopped the app and then moved my old backed up app data to the new dataset(s), and starting the app again brought me back to my expected state.
“you’re not supposed to use the hidden ix-apps dataset for permanent storage, and so you’re not supposed to back it up.”
IF you do select to install Apps under the “IxVolume” (instead of Host Path), the app DATA would be saved under /mnt/.ix-apps/ (which is really under the selected Apps Pool), but the GUI does not give you the choice to snapshot it or replicate it.
Yes, you can snapshot/replicate recursively the Apps Pool root dataset, but the current state will bite people that don’t really know.
(I do believe IX Systems was supposed to add a specific option to snapshot/replicate the apps data).
It isn’t. Read the docs that others have posted above.
ixVolumes are not recommended for permanent storage volumes, they are intended for use as rapid storage for a test deployment of the container. We recommend adding datasets and configuring the container storage volumes with the host path option.
But I think you know this already, because you then go on to agree with me that you can’t back it up easily.
BTW, turns out that if you enter the path manually for the ix-apps dataset, ie <poolname>/ix-apps, you can add it to the list of datasets that get replicated as part of a replication task.
Have you validated this? When I just tried it didn’t error when I added the path, but when I hit save the task creation seemed to get stuck and never completed.
