4

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 [1] 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 [2] 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!? )

[1] https://docs.docker.com/storage/volumes/

[2] https://owncloud.org/news/docker-series-pt-3-automatically-easily-backup-restore-dockerized-owncloud/

Cryptkeeper
  • 43
  • 3

1 Answers1

0

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?

I seem to understand that Docker wants you to forget a host even exists; and in fact, sometimes you won't have access to it, so volumes are the most obvious way to persist data.

The bind mount is a path on the host, so you have to "manage" it (allocate space, mount a partition...) in some way outside of Docker. Maybe you have already a system in place for that, for example an Ansible playbook that installs Docker, docker-compose and uploads the docker-compose.yml to the server. But if you don't, or you just point your docker-compose to a remote Docker daemon, well, you'll want to use just that, and nothing else: then you'll want data in volumes.

What about backing up /var/lib/docker/volumes/ directly?

I agree it is not a good idea: that is Docker's own space, I wouldn't touch it just like I would not copy from /var/lib/postgresql on a running instance.

Or am I missing something?

Why don't you run borg instead of tar inside your temporary container?

S19N
  • 1,693
  • 1
  • 17
  • 28