3

The official docker documentation suggests as a good practice to backup the entire docker volume as it is.

When you need to back up, restore, or migrate data from one Docker host to another, volumes are a better choice. You can stop containers using the volume, then back up the volume’s directory (such as /var/lib/docker/volumes/).

At the same time the docs state that one should must not modify volumes under no circumstance. And restoring a volume manually into the /var/lib/docker/volumes/ violates that warning. So these two statements seem to be contradictory to me.

Volumes are stored in a part of the host filesystem which is managed by Docker (/var/lib/docker/volumes/ on Linux). Non-Docker processes should not modify this part of the filesystem.

Questions:

  • Is it really safe to backup and restore volumes in that fashion between different versions of docker runtime?
  • Do volumes have some inner structure that is dependent on the runtime version? Or are they just regular files?
  • Is it safer to mount the volume to some container and backup it's data from the inside of the container?
Improve this question
9
  • Where does "the docs state that one must not modify volumes under no circumstance" ? I can't find this. Commented Sep 20, 2020 at 17:51
  • @MichaelHampton well I jokingly rephrased the Non-Docker processes should not modify this part of the filesystem the way I understood it :) Commented Sep 20, 2020 at 22:07
  • One advantage to doing all of your backup/restore operations via containers, rather than accessing /var/lib/docker directly, is that sometimes you don't have direct access to /var/lib/docker (because you're interacting with a remote api instead of a local one). Commented Sep 21, 2020 at 1:19
  • I second the question. The current Docker documentation (docs.docker.com/storage/volumes/…) advises to mount the volume and back it up from the inside, but it doesn't tell you why. As simply copying the volume directory seems way easier to me than backing it up from the inside, I'd love to hear the rationale behind the recommendation from the docs. Commented Jan 20, 2021 at 8:37
  • 1
    This is a complex question and as these things go, the answer is "it depends". The primary factors that relate to the question are the filesystem driver and the volume of activity within the docker daemon's scope. Assuming a "vanilla" situation with low volume writes, you should be relatively safe backing up /var/lib/docker directly; however, this is equivalent to backing up any running system that manages transient state (risks could be unfinished writes, for example). From an operational perspective, stopping the container would be prudent before backing it up. Commented Jan 20, 2021 at 9:08

1 Answer 1

Reset to default
3
+50

This is a complex question and as these things go, the answer is "it depends". The primary factors that relate to the question are the filesystem driver and the volume of activity within the docker daemon's scope. Assuming a "vanilla" situation with low volume writes, you should be relatively safe backing up /var/lib/docker directly; however, this is equivalent to backing up any running system that manages transient state (risks could be unfinished writes, for example).

Ultimately, processes running in a container context are still regular processes... so, it depends on the contained app, the frequency of disk writes, and the filesystem driver itself.

From an operational perspective, stopping the container or the main writer process within it would be prudent before backing it up.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.