{"id":5547,"date":"2018-11-08T14:40:03","date_gmt":"2018-11-08T14:40:03","guid":{"rendered":"https:\/\/blog.ssdnodes.com\/blog\/?p=2919"},"modified":"2025-07-16T14:50:08","modified_gmt":"2025-07-16T14:50:08","slug":"docker-backup-volumes","status":"publish","type":"post","link":"https:\/\/www.ssdnodes.com\/blog\/docker-backup-volumes\/","title":{"rendered":"Docker Backup: Saving and Restoring Your Volumes"},"content":{"rendered":"
\n
\n

You don\u2019t have a backup unless you\u2019ve restored your data from it.<\/p><\/blockquote>\n

The above quote is accurate even in the age of Docker. You need<\/em> to have a backup of your applications<\/a>, and, more importantly, your Docker volumes. Volumes are the persistent storage provider for Docker containers, and you can learn more about them here<\/a>.<\/p>\n

We\u2019ll pick up where that piece left off and work with the volume we created for our blog based on the Ghost CMS<\/a>.<\/p>\n

Docker volumes are supposed to be managed by the Docker daemon, and we don\u2019t want to fiddle with that. The strategy here is to get a copy of a volume as a compressed file in one of our regular directories, like \/home\/$USER\/backups<\/code>. This compressed copy of the volume then acts as our backup.<\/p>\n

<\/div>\n

<\/a>Running a Docker volume backup<\/h2>\n

First, we spin up a temporary container, and we mount the backup folder and the target Docker volume to this container. When an ordinary directory like ~\/backups<\/code> is mounted inside a Docker container we call it a bind mount. Bind mounts, unlike Docker volumes, are not exclusively managed by Docker daemons, and hence we can use them as our backup folder.<\/p>\n

The official Docker documentation<\/a> recommends this behavior, so you know it\u2019s safe to try on your containers and volumes. But before you do take a backup, ask yourself this question:<\/p>\n

Is the data in this volume changing right now?<\/strong><\/p>\n

If you are running a small blog where you add the content, not your customers, then the answer is most certainly no. On the other hand, an e-commerce site can receive an order at any given moment, even when you are running the backup! If that\u2019s the case, then you need to stop the main container before running a backup.<\/p>\n

In our example, the main container is ghost-site<\/code> which uses Docker volume my-volume<\/code>, mounted at \/var\/lib\/ghost\/content<\/code>, to store all of its data. We first stop the container.<\/p>\n

$ docker stop ghost-site\n<\/code><\/pre>\n
Next, we spin up a temporary container with the volume and the backup folder mounted into it.<\/p>\n
$ mkdir ~\/backup\n$ docker run --rm --volumes-from ghost-site -v ~\/backup:\/backup ubuntu bash -c \u201ccd \/var\/lib\/ghost\/content && tar cvf \/backup\/ghost-site.tar .\u201d\n<\/code><\/pre>\n
Let\u2019s dissect the second command. docker run<\/code> creates a new container, that much is obvious. After that:<\/p>\n
--rm<\/code> flag tells Docker to remove the container once it stops.
\n--volumes-from ghost-site<\/code> : Mounts all the volumes from container ghost-site<\/code> also to this temporary container. The mount points are the same as the original container.
\n-v ~\/backup:\/backup<\/code>: Bind mount of the ~\/backup\/<\/code> directory from your host to the \/backup<\/code> directory inside the temporary container.
\nubuntu<\/code>: Specifies that the container should run an Ubuntu image.
\nbash -c \u201c...\u201d :<\/code> Backs up the contents of your website as a tarball inside \/backup\/<\/code> inside the container. This is the same ~\/backup\/<\/code> directory on your host system where a new ghost-site.tar<\/code> file would appear.<\/p>\n
<\/a>Restoring from your Docker volume backup<\/h2>\n
You don\u2019t have a backup until you have at least once tried to recover your original data from the backup. Let\u2019s not wait for a disaster to strike, and then figure out how to restore. Let\u2019s do a trial run when things are running fine.<\/p>\n
To begin with, I have the following dummy content on my website:<\/p>\n
Logging into the VPS, let\u2019s delete the container and volume, mimicking a disaster.<\/p>\n
$ docker rm -f ghost-site\n$ docker volume rm my-volume\n<\/code><\/pre>\n
Now, the steps for recovery would involve:<\/p>\n
Creating a new volume
\nSpinning up a temporary container to recover from the tarball into this volume
\nMounting this volume to the new container<\/p>\n
$ docker volume create my-volume-2\n$ docker run --rm -v my-volume-2:\/recover -v ~\/backup:\/backup ubuntu bash -c \u201ccd \/recover && tar xvf \/backup\/ghost-site.tar\u201d\n$ docker run -d -v my-volume-2:\/var\/lib\/ghost\/content -p 80:2368 ghost:latest\n<\/code><\/pre>\n
If everything checks out, then you will be able to see the same dummy content, log in with the same email and password. In other words, your actions preserve the state<\/strong> of the application.<\/p>\n
Tarballs are not backups!<\/h2>\n
We showed you how to create a tarball out of the contents of your volume, but that tarball still lives on the host. If you make a critical error on configuring your host, lock yourself out via iptables<\/a>, or otherwise force yourself to reinstall your operating system via the dashboard<\/a>, your backup is useless!<\/p>\n
Setting up a remote backup solution is the best way to ensure that, in the face of disaster, your data is with you. For small websites, a simple scp<\/code> command would transfer all the content securely to your local system. Larger websites with a lot of content would require a bit more sophistication. The options vary from rsync<\/code> to dedicated NFS servers running periodic backups. Pick one that serves your needs the best.<\/p>\n
But, for the meantime, enjoy the slight sense of readiness and preparedness that comes with knowing how to backup your Docker volumes in a pinch!<\/p>\n<\/div>\n<\/div>\n
 <\/p>\n","protected":false},"excerpt":{"rendered":"
You don\u2019t have a backup unless you\u2019ve restored your data from it. Let’s walk through how to create Docker backups of important volumes in 30 seconds.<\/p>\n","protected":false},"author":20,"featured_media":5566,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[18],"tags":[182],"class_list":["post-5547","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops","tag-docker"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.ssdnodes.com\/wp-json\/wp\/v2\/posts\/5547","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.ssdnodes.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.ssdnodes.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.ssdnodes.com\/wp-json\/wp\/v2\/users\/20"}],"replies":[{"embeddable":true,"href":"https:\/\/www.ssdnodes.com\/wp-json\/wp\/v2\/comments?post=5547"}],"version-history":[{"count":5,"href":"https:\/\/www.ssdnodes.com\/wp-json\/wp\/v2\/posts\/5547\/revisions"}],"predecessor-version":[{"id":13498,"href":"https:\/\/www.ssdnodes.com\/wp-json\/wp\/v2\/posts\/5547\/revisions\/13498"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.ssdnodes.com\/wp-json\/wp\/v2\/media\/5566"}],"wp:attachment":[{"href":"https:\/\/www.ssdnodes.com\/wp-json\/wp\/v2\/media?parent=5547"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ssdnodes.com\/wp-json\/wp\/v2\/categories?post=5547"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ssdnodes.com\/wp-json\/wp\/v2\/tags?post=5547"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}