I some kind of "inherited" a dockerized server environment and now I have to implement a backup concept - especially for the Owncloud container, which stores the user files inside a docker volume. The docer docs  says that "volumes have several advantages over bind mounts" and therefore "are the preffered mechanism". One of the listed advantages is that "volumes are easier to back up" and the docs suggests a command such as the following to create a tar backup of a volume:
$ docker run --rm --volumes-from dbstore -v $(pwd):/backup ubuntu tar cvf /backup/backup.tar /dbdata
However, especially for backups (I use borg backup to sync host files to an offsite repo) I see several disadvantages this way:
- For each backup you have to copy the whole data locally, which needs twice the disk space and the time for copy.
- Each backup creates a new BLOB - unchanged files have to be copied again.
- To restore a single Owncloud file you have to restore the whole tar from the backup (untaring before syncing to backup would tripple the needed disk space). ...
I'm relatively new to docker, so I maybe have not yet the full overview of the docker ecosystem. But to my current knowledge, for this situation I think execptionally a bind mount would be the best solution. Also I have no benefit from the other advantages of volumes, anyway. Or am I missing something? Are there any disadavantages using a bind mount?
What about backing up /var/lib/docker/volumes/ directly?
Through my search, I came up with this blog post from owncloud  which suggests backing up /var/lib/docker/volumes/owncloud_files/_data directly. For me, this does not seem the cleanest way.
However, dealing with the current situation I'm thinking to go this way for the moment. Is it safe? (Of course with respect to the needed precautions for consitstency, e.g. shutdown database container, owncloud maintanance mode, etc. - which I think are needed in any way for the mentioned solutions here!? )