I'm currently running Docker 1.12.6 on Ubuntu 17.04, and I would like to know if all directories under /var/lib/docker should be included in my monthly backup (I backup everything under / with rsnapshot
, and then set some exclude
rules).
With Vagrant, for example, I exclude from the backup downloaded images and their resulting machines (.vagrant.d/boxes/ and .VirtualBox/Machines/), since they can be rebuilt anytime with their respective Vagrantfile.
I don't really understand how the /var/lib/docker
directory structure works, though. It is like the following in my system:
# tree -L 2 -a -F --dirsfirst --noreport /var/lib/docker/
/var/lib/docker/
├── aufs/
│ ├── diff/
│ ├── layers/
│ └── mnt/
├── containers/
├── image/
│ └── aufs/
├── network/
│ └── files/
├── swarm/
├── tmp/
├── trust/
└── volumes/
└── metadata.db
You can clean what is unused but you should never remove data manually from /var/lib/docker/volumes and/or /var/lib/docker/overlay2. Manually deleting files under /var/lib/docker can result in data loss. Read the Docker command line reference before running any of these commands.
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. Volumes are the best way to persist data in Docker. Bind mounts may be stored anywhere on the host system.
While Docker – and all containers – are typically somewhat newer to a production IT environment than most other technologies, there is still a need to backup these containers, their applications and their persistent data. If a production IT system produces persistent data, that data will likely have some value.
Yes, all directories under /var/lib/docker should be included in backup.
A Docker container consists of network settings, volumes, and images. The location of Docker files depends on your operating system.
Here is an overview for the most used operating systems:
(In macOS and Windows, Docker runs Linux containers in a virtual environment.)
Note
When you upgraded the kernel, without installing an updated version of the aufs kernel module; in that case, the daemon will refuse to start with a message that the "previously used storage driver is not supported". If the daemon fails to start, always read the logs before you take action.
To resolve this, make sure you have the aufs kernel module installed, for example, as explained in the installation docs for Ubuntu.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With