yes. If you needed to backup any data from that container then those would be the correct directories for those volumes.
I believe that’s correct.
Also, I saved the link to your original procedure in my “guides” folder for future reference:
https://hastebin.com/sojasolite.sql
You’re welcome! 
What you’ve listed aren’t really volumes. They are directories on the host machine. If you want your data from all the containers, just backup /srv/docker. That will get everything. You never need to backup the actual volumes that docker creates. You only want to backup your data that is bind mounted. Docker images are disposable and you should only be backing up the data that you want
Doesn’t exist on my system.
I do have a /var/lib/docker which is shown in Portainer as Docker Root Directory… is that the only one I should backup?
I do also have a /home/docker/config with some config for various applications like sabnzbd for example so I would assume I should back those up as well?
Of course it doesn’t unless YOU created it. I was simply using your example that you quoted.
THIS:
No, that is just the generic docker locations. Has nothing to do with where you store your data
This is ALL you need to backup if you just want to restore your docker configs.
For a better explanation, a bind mount -v /some/dir/on/host:/dir/inside/docker is simply mapping the directory INSIDE the docker container to where you specify on the host. The ONLY data you need to worry about is the data in that /some/dir/on/host or in your situation /home/docker/config. If you DO NOT do bind mounts, your data will live in some random name volume in your system, and you WILL lose it. Use bind mounts to retain data that should persist between versions of images. You don’t need to backup or retain the volumes that docker creates when it pulls an image. It is wasted space. The way Docker is designed, you should NEVER have data you want to remain persistent INSIDE the docker container. That’s why we have bind mounts.
Would you mind elaborating on this? What is it you’re missing compared to docker run or Portainer?
network_mode=host takes precedence over ports, any ports exposed in the dockerfile used to build the image will be exposed in your container, regardless of your ports settings. There are a few other settings that change too, most notably the possibility to pick up multicast traffic inside the container.
Interesting i didnt know network mode=host took precedent, learn something new each day.
I may just leave in there if they are not used, more as a what ports to connect to (getting old, so remembering the ports is harder)
Thank you for the information. So in theory if you select both in the compose, the ports section would be "inactive " and host mode would be followed.
However, I’ve set up containers in the past where i’ve inadvertently left both options and the container wont work. It’ll start but you cant access it.
For example let’s say that I have a docker-compose file that contains all of the configuration for all of my containers, which from what I’ve seen is fairly standard. If I do a docker-compose down then all of my containers are stopped at the same time. It’s the same for any docker-compose command. it operates on all of the containers in the file at the same time (unless I’m completely missing some understanding of how it works and why…). I don’t see the benefit of that in my use case or in the way most of us as home automation enthusiasts would use Docker. Maybe if you’re an IT guy using it to manage production type environments it might be useful.
Most of the time I only want to interact with one container at a time so using Portainer (or lacking that, the CLI) is my preference.
When I want to update my home automation stack, I use docker-compose down && docker-compose pull && docker-compose up -d
Your docker-compose does not HAVE to comprise of EVERY single Docker container you run in your home network. The way I see it, the rest of my network does not rely on my home automation stack, and therefore I can down it, update all the things, and restart it. A few months ago, I took portainer out of my docker-compose file so that I can leave it running while I update everything else. If you run other services on your network, you don’t have to have them in your compose. I prefer to update my entire stack at once, with one command, assuming I have already read about any breaking changes on any of my apps.
I know that.
I’m just saying that it seems to me from what I’ve noticed is that when people start using docker-compose the tendency is to put everything in there.
For me as a casual user that only has 7 containers and really only having HA that needs updating regularly then using docker-compose seems to be overkill and too much of a shot-gun style approach for my preferences.
Especially since Portainer can do those things fairly easily with 2 clicks.
Just my thoughts and just giving another perspective…
Yes, that is the disadvantage of using host networking.
Correct.
Do you have any examples?
You can do docker-compose stop <container-name>, just like you would do docker stop <container-name>. The Portainer GUI certainly makes it easy (easier) but the functionality is still there in docker compose.
My main reason to use compose is the overview of all parameters, it’s not a volatile CLI command that can be lost if I inadvertantly close a terminal window at the wrong time. I have some 20+ containers running and I probably have 20 different compose files, just like you I don’t see a point in linking them all together if they don’t need it but there is no way I could keep track of all the parameters needed for each container. The internal networking of the Docker stack works so well for me I don’t even have to run HASS and InfluxDB in the same file (the only disadvantage is that I have to manually stop HASS before I update InfluxDB, I would not have to do that if they were declared in the same file).
sure, but you can have different docker-compose stacks. Say, one for media apps, one for home automation, etc.
Not on my private MQTT. I run user/pass/cert on my public MQTT server and bridge my private to public to subscribe to specific topics
To set a password in Eclipse-MQTT you need to create a password file in your config directory and reference that file in your volume mounts in your docker command. Here is how I have mine set up:
-v /home/finity/docker/mqtt/config/passwd:/mosquitto/config/passwd
Then console into the docker container and add a password file there:
/ # mosquitto_passwd -c /mosquitto/config/passwd/pwfile <username>
It will then jump to the next line and go blank with a flashing cursor but in actuality it’s waiting for the password to be entered. Type in the password & hit enter then do it once more to confirm. Then type ‘exit’ to get out of the console.
The password file should be saved at the above location. I had to fiddle with it a bit to figure out exactly where the file was storing itself.
Then you need to update your mosquitto.conf file to look at the location of the password file for user and password. Here is mine:
pid_file /var/run/mosquitto.pid
persistence true
persistence_location /mosquitto/data/
# Port to use for the default listener.
port 1883
log_dest file /mosquitto/log/mosquitto.log
log_dest stdout
allow_anonymous false
password_file /mosquitto/config/passwd
I hope that’s what you were asking for.
So I got everything running.
I am going to use watchtower but not for home assistant/hassio. I did write a docker-compose.yml file but doubt I’ll ever use it as I can use update in hassio for HA and either let watchtower do it’s thing or rebuild the container in Portainer for the other stuff.
I also found a nasty bug in Portainer. On my mobile/ipad I get timed out and then it says incorrect username/password… It seems it doesn’t like auto-entered user/pass. So I eventually worked out if I add a space at the end of user/pass and delete it I can then logon…
I also wrote a cron job to tar/gzip my config volumes and I found a nice addon that will then copy that to dropbox. For Hassio of course I use snapshots.
I think I’m all done for now anyway…
Thanks for finding the bug in Portainer and iOS I have been trying this for ages. Nice one. 
I looked to give them some feedback (mainly from the web interface - not their site) but it seems any kind of support is ‘paid’ - I will look on their site but it shouldn’t be that hard to help them
Edit: I just used their feedback form to report it
Well they got right back to me and said it’s a bug they know about and can’t fix it - it’s the auto-complete of password fields causing it. He says the only solution they have found is to use incognito mode.
Ok, I have read the full thread here now and I am about to move from Rpi to Intel NUC. Installed hassio in docker as a test. Later I will move my HA snapshot. In hassio I am now using some add-ons like node-red, duck dns and git. Is is possible to keep the add-ons in HA or would it be better to use separate docker containers for theese. I just do not understand the diffrence.
I moved all my stuff to NUC last week
https://smile.amazon.com/gp/product/B00XPVRR5M/ref=oh_aui_detailpage_o02_s00?ie=UTF8&psc=1
I got this as a base system with 8GB memory and a SSD ultra drive. The Nuc is for Home Automation stuff only. I should have gone with a faster processor but with all the below on it I still get better performance. ZM uses up a lot of resources, so I am experimenting with motioneye in docker on a test system.
My stack is made of several docker-compose.yaml files so I guess technically several stacks
Portainer
Home-Assistant
MQTT
influxdb
graphana
appdaemon
syncthing
st-bridge - still have a few zigbee devices on ST
influx-grafana-speedtest - track internet speed
phpmyadmin
mariadb
ha-dockermon
node-red - customer build that includes support for alexa tts wrapper (jq needs to be installed for this)
zoneminder - 3 outside ip camera - customer build that has event notification
lamp - Kanboard and few other web apps
homebridge - to stream a few cameras to homekit
watchtower
glances
because I am using lots of volumes for configuration and mysql data , it would be fairly easy to back all this up and move it.