How to Backup Docker Containers? Docker Container Backup Methods.

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. It may even be of  critical importance. Therefore, safeguarding that data in case some sort of disaster happens, for example as a result of a data breach or human error, is likely necessary.

This topic covers both Docker’s ability to create backups by itself, as well as the ability of various third-party solutions to create comprehensive Docker backups, such as Bacula Enterprise.

Docker container backup and restore

This usually begins with committing the container in question as an image, using the following command:

This image can be saved as a .tar file with another command:

The .tar file can also be saved on the NFS mount point. An alternative for that is via pushing the image in question (backup01) directly to your local registry. To do that we’ll have to appropriately tag the image first:

In this case localhost is the location name, and 5000 is the port number. Both can be changed if needed. It’s also important to remember that both the tag name and the repository should in the lower case for the tag to be applied correctly. The process is complete with the push command initiation:

Since there’s two backup methods we’ve discussed, there’ll be two restore methods, as well. To restore the backup image from a .tar file you’ll have to initiate the following command:

The command line should show you the subsequent status lines if the command has been input correctly:

Another command called docker run can be used to create a container from this image.

A pushed image can be pulled directly with a relatively simple command:

As with the previous example, both the localhost name and the port number is the subject to change if needed.

Docker volume backup and restore

Another type of Docker backups is via volumes – persistent storage providers for Docker containers. These volumes need to be backed up for data continuity.

When it comes to persistent data management inside of the running Docker containers, Docker volumes are the most recommended way to manage it all. This kind of approach offers several different advantages. For example, data that is stored in the Docker container via volumes gets effectively isolated from the rest of the file system, making it that much harder to be affected by system-wide cyberattacks. However, this kind of isolation also makes it harder to create Docker backup volumes.

Additionally, volumes eliminate the need to worry about GUI and UID between the Docker container system and the OS. Volumes themselves are portable when it comes to different Docker installations, meaning that there is no need to worry about the host’s operating system. At the same time, this portable approach makes it possible to manage Docker volumes with various external tools – such as bucket based storage, nfs, etc.

Since Docker volumes are borderline necessary to realistically create different Docker containers with persistent data, it is only natural to make sure that you also have Docker backup volumes – this kind of data is at least as important as any other data inside of your system, if not more important.

Of course, using docker volumes to store container data might not exactly be convenient and there are some growing pains here and there. For example, you would have to learn several different commands to do something as simple as copying information out of the container. You would also have to know multiple commands to be able to grab a shell on a running Docker to be able to see the current status.

The entirety of Docker volume data may be harder to make visible inside of your centralized file system, since it works in a slightly different manner than the traditional storage locations – and you would have to create Docker backup volumes for the same purpose you usually create backups of your regular data.

Usually, Docker volumes are managed by the Docker daemon, however, we will not be interacting with that at all. The idea of a docker backup volume is to get a volume copy as a compressed file in one of the local directories. This copy is the backup we’re looking for.

In this example our container in question is called dckr-site with the volume called dckr-volume, it’s mounted at /var/lib/dckr/content/ and stores all of the data there.

The first step is to stop the container using the following command:

The next one is focused on both mounting the container and backing up the volume’s contents:

In this scenario:

• docker run command is used to create a new container,
• –rm command tells the system to remove the container once the operation is complete;
• –volumes-from dckr-site is mounting the container’s volumes to our new temporary container;
• bash -c “cd /var/lib/dckr/content && tar cvf /backup/dckr-site.tar” creates a backup from all of the contents of the /backup/ directory

The recovery process for these backups isn’t that complicated. It begins with creating a new volume with the following command:

Then you can use the following command to restore the volume from a temporary container in a .tar file:

Of course, you’ll have to mount this new volume to the new container for it to work properly:

If the procedure is done correctly, the entire state of the application should be restored. It’s important to mention that this method should not be relied on as a single backup source since the backup data is still stored on the host, and therefore  would be lost in case of a data loss or disaster that affects the host as well.

Docker backup and restore with Bacula Enterprise

Bacula Enterprise utilizes its modular capability to allow for native integration of various systems and services, including Docker. Bacula’s Docker module provides a lot of useful additional features alongside the core backup and recovery ones.

Docker backup with Bacula Enterprise consists of three simple steps:

1. Current state of the container is saved to the new image
2. Docker utility is executed and the data is saved
3. The snapshot in question is removed to free up the space

The backup in question can be performed to a container in every state, and Bacula software shows the status of the backup process on each step. Each container image backup means one more .tar file saved. Image backups are kept in the /@docker/image//.tar, and container backups are kept in the /@docker/container//.tar directory.

The restoration process of Docker backups with Bacula Enterprise is slightly more complicated and can be done in two different ways:

• Restore to local directory that utilizes the where=/some/path Bacula parameter to state the full path for the backup to be restored to as an archive file or files;
• And Restore to Docker service, meaning that the backup data would be restored with the where= command as the new container, without archiving it in the first place.

The customization of the restoration process is also available via several different parameters, like container_create, container_run, and more.

At the time of writing, Bacula is one of the very few (or the only) enterprise-grade backup and recovery solutions to be able to perform full and comprehensive backup of a Docker environment. However, the availability of other, specialist Docker backup solutions, combined with Docker’s own inbuilt solution, together with Bacula’s Docker module, mean that there is a range of choices available to IT managers seeking a way to safeguard their production Docker deployment.