- Products
- Solutions
- Support
- Training
- Customers
- Partners
- Company
- Try for free
Menu
Bacula Enterprise is the world’s first enterprise class backup and recovery solution to offer advanced, automated backup of Docker containers. Its Docker backup module takes container ease of use to a new level. This world-leading technology has now been further updated to also include Docker volume backup and recovery.
This module is integrated via the Docker official API and means users can rapidly and easily backup multiple Docker containers without having to install an agent inside each container. This automated external Docker volumes backup is part of Bacula’s capability for full orchestration integration. It is available at most subscription levels of Bacula Enterprise at no additional cost for a limited period of time.
Whether your deployed container environment is used for lift-and-shift of monolithic applications, or refactoring legacy applications, or building new distributed applications - developers and Systems Administrators can use Bacula's advanced technology with an especially high level of flexibility – via either Bacula’s GUI or command line interface. Remember, this high level of flexibility and customization possibilities are fundamental to Bacula’s approach: to empower the user by introducing a wide range of options to her/him you achieve their aims.
The main features of the Bacula Docker Container Backup Module are:
Bacula Enterprise software is designed so that organizations can deploy this solution for their entire physical, virtual, cloud and all hybrid environments, regardless of architecture, all from a single platform.
Effective backup and recovery is especially important because when a container’s life ends, there may be data in it that is needed. However, due to the challenging nature of a containerized environment, other backup solutions cannot, as of today, perform simple and efficient Docker container backup – and in nearly all cases, not at all. Bacula is the only solution to provide fully automated backup of Docker.
Safe & Efficient Use of Docker Containers
Bacula Enterprise makes the usage of Docker more reliable and convenient. It is even possible to backup defined Docker images only, which can be used to create new containers when required. Our automated and scalable solution was made to support the workloads of both IT and DevOps that use Docker, SUSE, Caas or Openshift.
Systems administrators and DevOps managers benefit from the high level of control and management flexibility available via GUI or web interface of Bacula Enterprise.
Beware of Other Vendor’s Claims
Some backup and recovery vendors are claiming to be able to backup and restore Docker. They are extremely limited, however, and simply add a container with their client service to a containerized application, and use that to backup the specific, required data. With these solutions, there is no straightforward, application-independent restore process available. So how to backup Docker in this case? The administrator needs to rely on careful manual configuration, though, as well as understand the relationship of persistent storage entities; which application they belong to, which containers use it, and so on. In short, it is a workaround – not an effective and fast solution.
Only Bacula offers a fully integrated, automated and especially fast Docker backup and restore solution. With Bacula’s advanced Docker backup and recovery module, backup teams do not need knowledge of container internals, applications, or storage assignments. Instead, Docker environments now become more efficient through automation and – most importantly – save valuable data generated from single or multiple containers.
Backup
The backup of a single container consists of the following simple steps:
The backup of a Docker system images does not make a snapshot as every system image is a read-only template used for container creation. Backups can be performed for container in any state (created, running or stopped). The Docker Backup Module will inform you about every container or image backup start and finish:
The backup will create a single (.tar) file for any container or Docker image which is saved. Inside Bacula, those are represented as follows.
Multiple files will be created during a backup if multiple containers or Docker images are selected for backup with one job. The distinct file names as shown above allow to locate the proper container or system image archive for restore.
To list available Docker containers or system images, a listing mode is available, described in chapter 6.1 on page 12.
Restore
The Docker Module provides two targets for restore operations:
Restore to Docker
To use this restore method, the where= or where=/ parameter of a Bacula restore command command is used.
The Docker container archive will be sent to the Docker service and restored as a new image and then created as container if the container_create restore parameter is set (which is the default). If the restore parameter container_create is not set then any container will be restored to image level only and the user has to create or
run the container manually. If the restore parameter container_run is set (default is “no”) then the restored container will be started immediately after successful restore.
The Docker image archive will be loaded into the Docker service as the original Docker image overwriting the one already existing. This is the default behavior and can be changed by setting the ’Replace’ option of the restore command as desired. You can skip Docker image restore of already existent image with Replace option of restore command.
The default container name or container image label can be changed during a restore with the container_defaultnames or container_imageid restore parameters (see section 4.2 on page 8).
Restore To Local Directory
To use this mode, the where=/some/path Bacula restore parameter is set to a full path on the server where the Docker Module is installed. If the path does not exist, it will be created by the Bacula Docker Module.
The Bacula agent and its Docker Backup Module need to be installed on the host for the Docker service. Docker could be installed on different operating systems and distributions, so the Bacula Enterprise File Daemon for this operating system and platform has to be used.
The module is configured using Module Parameters defined in a FileSets Include section of the Bacula Enterprise Director configuration.
Estimation and Backup Module Parameters
These optional Module parameters are relevant only for Backup and Estimation jobs:
Module Restore Parameters
During a restore, the Docker backup module will use the same optional parameters which were set for the backup job and saved in the catalog. Some of them may be changed during the restore process if required.
container_create: <yes|no> specifies if Docker container restore should automatically create a container. The default option is to create containers on restore. If containers are to be restored as images, this parameter should be set to no.
container_run: <yes|no> specifies if Docker container restore should automatically create and run restored containers. The default option is to not run restored containers automatically. If containers are supposed to be run immediately after being restored, this parameter should be set to yes.
If this parameter is set to yes, then the container_create parameter will be ignored.
container_imageid: <yes|no> specifies if the Docker Module should use the image id values to create or run restored containers. The default is to use image repository and tag values for this purpose. This parameter will be ignored when both container_create and container_run are set to no as no container create or run operation will be performed.
container_defaultnames: <yes|no> specifies if the Docker Module should setup container names based on original container name and JobId values, which is the default. If this parameter is set to yes, the Docker service will setup default names for created or run containers.
FileSet Examples
In the example below, all Docker containers and images will be backed up.
In this example, a single Docker container with name-label of “mcache1” will be backed up.
The same example as above, but using container id instead:
In the following example, all Docker containers which contain “ngnix” in their names will be backed up.
In this final example, all Docker containers except those whose names begin with “test” will be backed up.
Restore to a Docker service
To restore a container or image to a Docker service, the administrator should execute the restore command and specify the where parameter as in this example:
and then set any other required restore module parameters for the restore. In the following restore session example, the container_run plugin restore option is set to “Yes”:
The restore job log will indicate which container is restored and which new container id was created:
The new container created during the restore will get a new container id. This can be checked by running a command such as:
Restore to Local Directory
It is possible to restore the container images and Docker template images data to a file without loading them to Docker service. To do so, the where restore option should point to the local directory:
Please check the following example for the message “Docker local restore”:
The restore job log will show that the restore was done to a local directory. The log above was truncated for a clear view.
Further help on Docker container backup:
