I’m trying to come up with a elegant way of backing up my docker volumes. I don’t really care about my host and the data on the host, because everything I do happens inside my docker containers and the mapped volumes. Some containers use mapped paths, but some others use straight up docker volumes.
I’ve started writing a script that inspects the containers, reads all the mount paths and then spins up another container to tar all the mounted paths.
docker run --rm --volumes-from $container_name-v /data/backup:/backup busybox tar cvf /backup/$container_name.tar $paths
So far so good, this works and I can write all backups to my storage and later sync them to an offsite backup space.
But error handling, (nice)logging and notifications using ntfy in case of success / errors / problems is going to suck in a bash script. Local backup file rollover and log file rollover also just suck if I have to do all this by hand. I’m able to use other languages to write this backup util but I don’t want to start this project if there already is a ready made solution.
So the question, is there a utility that can simply schedule arbitrary bits of script, write nicer logs for these script bits, do file rollovers and run another script on success / error?
All the backup programs that I can find are more focused on backing up directories, permissions and so on.
./ bind mount everything in your compose file because dockers volume storage is bloody annoying to backup. Then you can just back up the one folder with everything in it.
That’s what I’m doing too. Kind of felt wrong to do that, but if you don’t need the extra features of docker volumes this is the way. It always puzzles me when I read “Volumes are easier to back up or migrate than bind mounts.” in the docs. How are these --volumes-from shenanigans easier than rsyncing some directory off the host?
They’re just normal folders located in
/var/lib/docker/volumesso you can back up that directory.Yah, but if you have just one corrupt, then you have to fuck around figuringbout which UID named volume is attached to which container that may or may not be running, so now you have to sort through config files to identify it. Restoring a bind mount is the work of seconds and is very straightforward.