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?
Kolyunya
  • 187
  • 2
  • 9
  • Where does "the docs state that one must not modify volumes under no circumstance" ? I can't find this. – Michael Hampton 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 01:19
  • I second the question. The current Docker documentation (https://docs.docker.com/storage/volumes/#backup-restore-or-migrate-data-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 '21 at 08: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 '21 at 09:08
  • @MarkR. Thank you for the explanation! Does your comment also imply that when mounting the volume into another container and backing it up from the inside you wouldn't have to temporarily stop the container? – TuringTux Jan 21 '21 at 08:29
  • @TuringTux -- 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. – Mark R. Jan 23 '21 at 12:16
  • @MarkR. So it is not as simple as I stated beforehand, I see. Thank you for the explanations. – TuringTux Jan 23 '21 at 13:04
  • @MarkR. Do you want to formulate your comments as an answer so I can award you the bounty? Otherwise, I suppose it will simply be gone for good. – TuringTux Jan 26 '21 at 09:16

1 Answers1

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).

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.

Mark R.
  • 365
  • 1
  • 5