2

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?
9
  • Where does "the docs state that one must not modify volumes under no circumstance" ? I can't find this. Sep 20 '20 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 :)
    – Kolyunya
    Sep 20 '20 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).
    – larsks
    Sep 21 '20 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.
    – TuringTux
    Jan 20 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.
    – Mark R.
    Jan 20 at 9:08
1
+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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.