Docker Container Backup/Restore Guide

Multiple languages, frameworks, architecture, and disjointed interfaces between the tools for each lifecycle stage of a product creates massive complexity.

Docker has revolutionized the software development industry, and simplifies and accelerates developers’ workflow, while giving them the freedom of their choice of tools, application stacks, and deployment environments for each project.

By using a docker container, developers are able to package all the code for an application and all its dependencies into one package that runs smoothly and reliably, irrespective of the computing environment.
So, because docker containers isolate software from its hardware environment and ensures that it works uniformly, containerized software always run the same, regardless of the infrastructure.

Because of this, the question often arises whether docker containers should be backed up.

At first glance, and because a running container is just temporary, it may seem that they don't. On closer inspection, though, it does make sense to back up docker containers to protect against disaster.

With this post, we'll look at some of the instances when containers should be backed up, what needs to be backed up, and how a backup is done.

We’ll also look at how a backed up image is restored. However, before looking at this, will briefly recap on some docker container basics.

Table of Contents

Docker Container Basics

Containers are a type of virtualization and Docker is the most popular container platform that developers use to run their applications.

It's an open platform for developing, shipping, and running applications that enables developers to separate their applications from their infrastructure so that they can deliver software quickly.

In other words, by using docker's methodologies for shipping, testing, and deploying code quickly, developers can reduce the delay between writing code and running it in production.

Why Docker Needs A Backup?

Historically, backups comprised of an agent placed in a server that needed to be backed up. However, virtualization broke that model, so a new model was created where the agent runs at the hypervisor level and backs up the virtual machines as images.

Unfortunately, containers don't offer any of these options. Despite this, containers, under some circumstances, do need to be backed up, so let's take a look at when developers should look at backing up their containers.

Because high availability is built into every part of the container infrastructure, many container advocates often point out that a backup is not necessary.

In addition, they say, Kubernetes is always run in a cluster and containers are spawned and killed off as necessary. Unfortunately, in thinking this way, many confuse the high availability built into containers with the ability to recover from a disaster, should it occur.

Sure, a typical container does not need to have its running state backed up and most containers are stateless. In other words, there's no data stored in the container and it's just another running instance of a given container image that's already saved somewhere else.

But what happens if an error takes out an entire cluster, container nodes, and associated persistent storage. This would mean that a developer would have to replicate their entire Kubernetes and Docker environment, something that is not likely without a backup.

In simpler terms, depending on how the application and its data is implemented, there might be a need for a backup.

What Needs To Be Backed Up For Docker?

In the event of one of those cases where a backup is necessary, what should be backed up? Let's take a look.

Container Images Backup

A container image is a lightweight, stand alone, executable package of software that includes everything needed to run the application from the code to the runtime, system tools, system libraries, and settings.

Because docker container images become containers when they run on Docker Engine, they do not change.

So, if any libraries or code for a given container changes, a new image would be created for that container. For this reason, images are often protected using a repository and, in turn, that repository should be protected.

Attached storage or databases Backup

When there is a need to make applications in containers more persistent, for instance, when running databases within a container ecosystem, developers basically have two options.
One would be to create a stateless container where the database is copied into the container when it is created. Another would be to store the data on a file system or volume and attach it to the container at startup.
This should be backed up, and when it is, the docker backup volume will restore the data when the volume is restored.

Persistent Volumes Backup

Kubernetes pods are increasingly using persistent storage. This means a backup may be necessary to protect the persistent storage and the data created on it.

Deployments Backup

A Kubernetes Deployment is used to tell Kubernetes how to create or modify instances of the pods that hold a containerized application.
They can also scale the number of replica pods, enable rollout of updated code in a controlled manner, or rollback to an earlier version of the Deployment if necessary. Deployments are described and stored in YAML (or JSON) files and these files need to be backed up.

Kubernetes etcd Backup

The Kubernetes central database is etcd, and it needs to be backed up. It's a small file and Kubernetes provides the tools necessary that dumps its contents into a file that you can back up.

Kubernetes resources Backup

Because developers create resources in Kubernetes, those resources needs to be backed up with the right group and version.

Not everything needs to be backed up, though. For example, a running stateless container is only temporary and was spawned from a container image, so it does not need to be backed up. Keep in mind, though, that any data it creates should probably be backed up.
Likewise, since pods are just groups of running containers, they don't need to be backed up.

In respect of the elements that should be backed up, each offers a native tool that can be used to back it up to local or remote storage. In light of this, let's look at the procedure to back up a Docker container.

How To Back Up Docker Containers

Before we back up a docker container, we need the container ID of that specific container. Here, will use the ps command to get the IDs of all the running containers.

From here, we can copy the container ID of the container we need to back up.

So, to list all the IDs of all the running containers, use the following command:

docker ps -a

In the results, we'll look for the container ID of the docker container that we want to back up, copy it, and then use it with the Docker commit command. The format for this command is:

docker commit −p <CONTAINER_ID> <BACKUP_NAME>

So, for example, if the container ID of our container is 5c7d78fcb634, and the name of our backup is our-docker-backup, the command will be:

docker commit −p 5c7d78fcb634 our-docker-backup

With this command we've first paused a running container with the -p option, and we've made a commit to save the entire snapshot as a docker image with the name our-docker-backup.

We can also save the image as a tar file on our local machine by using the command:

docker save −o ∽/our-docker-backup.tar our-docker-backup

We can check whether the file has been saved by using the command:

ls −l ∽/our-docker-backup.tar

When it saved as a tar file we can move it do any other desired docker host system for a deployment.

We can also redeploy our our-docker-backup image on another docker host system by using the push command to push the image to a private docker repository.

To do this, will use the command:

docker login
docker push our-docker-backup

Now that we've backed up our Docker container, let's look at the procedure to restore Docker containers, either locally or on another machine.

How To Restore A Docker Backup

If we've saved the tar file on our host machine, we can restore it by using the docker load command. To do this, we’ll use the command:

docker load −i ∽/our-docker-backup.tar

To make sure that the image was restored successfully, we can then list all the images using the following command:

docker images

If we've pushed the backup image to a docker repository, we can use the pull command to pull the data from the repository.

Here, we'll use the command:

docker pull our-docker-backup:tag

Once we've restored the backed up image on our local machine, we can use the run command to run a new instance of the restore docker image. to do this we use the command:

docker run −ti our-docker-backup:tag

Final Thoughts

Now we've shown how to backup and restore a docker container. This is helpful when developers want to migrate a docker container which is running on their host machine to another machine and when they want to back up their docker container for the reasons mentioned above.

Hopefully, this guide was helpful in showing when a docker container needs to be backed up, what should be backed up, and how it should be done.