Docker Container Backup. Backup Docker Volume. Docker Backup

The first fully integrated and automated Docker volume backup.

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.

Download Trial Docker Backup Whitepaper

Docker Container Backup Module Features

Backup and recovery of the Docker container configuration, volumes and images
Fully integrated solution, adhering to Docker philosophy and methodology
Complete automation for rapid roll-out of container protection strategies
Fully effective integration, using Docker official API

Aids preparation of new Docker images
Image saving, image rollback and backup of image changes
Fine grained control over what containers and images to backup or not to backup
Controlled backup of defined, specific Docker images

Why Bacula’s Docker Backup Module is Unique?

Bacula Enterprise software is designed so that organizations can deploy this Docker backup solution for their entire physical, virtual, cloud and all hybrid environments, regardless of architecture, all from a single platform.

Effective Docker 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 Docker environments, 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 and its data volumes.

Safe & Efficient Use of Docker Containers

Bacula Enterprise makes the usage of Docker more reliable and convenient. It is even possible to backup Docker defined 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 when performing Docker backups incl. its data volumes.

Download Trial Docker Backup Whitepaper

Beware of Other Vendor’s Claims

Some backup and recovery vendors are claiming to be able to backup Docker incl. its volumes. 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.

Docker Backup and Restore Operations

Docker Backup

The backup of a single Docker container consists of the following simple steps:

Save current container state to new image (container commit – snapshot).
Execute Docker utility and save data.
Remove saved snapshot to free not needed resources.

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:

JobId 127: docker: Start Backup docker Container: myubuntu (4d0a4fadb50d)
JobId 127: dkcommctx: Commit created: myubuntu/4d0a4fadb50d/127:backup
JobId 127: dkcommctx: Commit removed: myubuntu/4d0a4fadb50d/127:backup
JobId 127: docker: Backup of docker Container: myubuntu (4d0a4fadb50d) OK.
…

The Docker backup module will create a single (.tar) file for any container or Docker image which is saved. Inside Bacula, those are represented as follows.

/@docker/container//.tar for container backup
/@docker/image//.tar for image backup

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.

Docker Restore

The Docker backup module provides two targets for restore operations:

Restore to Docker service;
Restore to a local directory as archive files.

Restore to Docker Service

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.

Docker Backup Module Installation

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.

Docker Backup Module Configuration

The module is configured using module parameters defined in a FileSets Include section of the Bacula Enterprise Director configuration.

Estimation and Docker Backup Module Parameters

These optional module parameters are relevant only for Backup and Estimation jobs:

Specify a Docker container to backup.
Multiple container=<. . . > parameters are allowed. If a container with <name-label> can not be found, then a single job error will be generated and the backup will proceed to the next container unless abort_on_error is set which will cause the complete backup job to be aborted. Docker container names (<name-label>) or container ids (<id>) can be used to select containers to backup.
Specify a Docker image to be backed up.
Multiple image=< . . . > parameters are allowed. If an image with <repository:tag> can not be found, a single job error will be generated and the backup will proceed to the next image unless abort_on_error is set which will cause the complete backup job to be aborted. Docker image repository and tag names (<repository:tag>) or image ids (<id>) can be used to select required image to backup. This parameter is optional.
Specify list of Docker container names to backup using regular expression syntax.
All containers with names matching the regular expression provided will be selected for backup. Multiple include_container=<. . . > parameters may be provided. If no containers are matching the name expression provided, the backup will proceed to the next parameter or finish successfully without backing up any containers. The abort_on_error parameter will not abort the job when no containers are found using name matching.

Specify a list of Docker image repository names to back up using regular expression syntax.
All images with repository name matching the regular expression provided will be selected for backup. Multiple include_images=<. . . > parameters may be provided. If no images are matching the repository name expression provided, the backup will proceed to the next parameter or finish successfully without backing up any images. The abort_on_error parameter will not abort the job when no images are found using repository name matching.
Specify a list of a Docker container names which will be excluded from backup using regular expression matching.
All containers with names matching the provided regular expression, and selected for backup using the include_container=<. . .> parameter will be excluded. This parameter does not affect any containers selected to be backed up using container=<. . .> parameter. Multiple exclude_container=<. . .> parameters may be provided.
Specify a list of Docker image repository names which will be excluded from backup using regular expression matching.
All images with repository names matching the provided regular expression, and selected for backup using the include_image=<. . .> parameter will be excluded. This parameter does not affect any images selected to be backed up using image=<. . .> parameter. Multiple exclude_image=<. . .> parameters may be provided.

Docker Backup 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.

Docker Backup FileSet Examples

In the example below, all Docker containers and images will be backed up.

FileSet {
Name = FS_DockerAll
Include {
Plugin = “docker:”
}
}

In this example, a single Docker container with name-label of “mcache1” will be backed up.

FileSet {
Name = FS_Docker_mcache1
Include {
Plugin = “docker: container=mcache1”
}
}

The same example as above, but using container id instead:

FileSet {
Name = FS_Docker_mcache1
Include {
Plugin = “docker: container=cd77eb89e59a”
}
}

In the following example, all Docker containers which contain “ngnix” in their names will be backed up.

FileSet {
Name = FS_Docker_nginixAll
Include {
Plugin = “docker: include_container=ngnix”
}
}

In this final example, all Docker containers except those whose names begin with “test” will be backed up.

FileSet {
Name = FS_Docker_AllbutTest
Include {
Plugin = “docker: include_container=.* exclude_container=^test”
}
}

Docker Restore Scenarios

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:

* restore where=/

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”:

* restore where=/
…
Run Restore job
JobName: RestoreFiles
Bootstrap: /opt/bacula/working/docker-test-dir.restore.1.bsr
Where: /
Replace: Always
FileSet: Full Set
Backup Client: docker-test-fd
Restore Client: docker-test-fd
Storage: File1
When: 2018-09-28 14:09:30
Catalog: MyCatalog
Priority: 10
Plugin Options: *None*
OK to run? (yes/mod/no): mod
Parameters to modify:
1: Level
2: Storage
3: Job
4: FileSet
5: Restore Client
6: When
7: Priority
8: Bootstrap
9: Where
10: File Relocation
11: Replace
12: JobId
13: Plugin Options
Select parameter to modify (1-13): 13
Automatically selected : docker: container=mcache1 abort_on_error
Plugin Restore Options
container_create: *None* (*Yes*)
container_run: *None* (*No*)
container_imageid: *None* (*No*)
container_defaultnames: *None* (*No*)
Use above plugin configuration? (yes/mod/no): mod
You have the following choices:
1: container_create (Create container on restore)
2: container_run (Run container on restore)
3: container_imageid (Use Image Id for container creation/start)
4: container_defaultnames (Use default docker Names on container creation)
Select parameter to modify (1-4): 2
Please enter a value for container_run: yes
Plugin Restore Options
container_create: *None* (*Yes*)
container_run: yes (*No*)
container_imageid: *None* (*No*)
container_defaultnames: *None* (*No*)
Use above plugin configuration? (yes/mod/no): yes

The restore job log will indicate which container is restored and which new container id was created:

JobId 139: Start Restore Job RestoreFiles.2018-09-28_14.13.31_03
JobId 139: Using Device “FileChgr1-Dev1” to read.
JobId 139: Ready to read from volume “vol001” on File device “FileChgr1-Dev1” (/opt/bacula/archive).
JobId 139: Forward spacing Volume “vol001” to addr=225
JobId 139: docker: docker Container restore: mcache1/b97d4dd88063
JobId 139: End of Volume “vol001” at addr=62177197 on device “FileChgr1-Dev1” (/opt/bacula/archive).
JobId 139: dkcommctx: Successfully run container as: ef48c6b5b867

The new container created during the restore will get a new container id. This can be checked by running a command such as:

# docker ps -a
CONTAINER ID IMAGE CREATED STATUS
ef48c6b5b867 mcache1/b97d4dd88063/139:restore 4 minutes ago Up 4 minutes

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:

* restore where=/tmp/bacula/restores

Please check the following example for the message “Docker local restore”:

JobId 141: Start Restore Job RestoreFiles.2018-09-28_14.26.34_03
JobId 141: Using Device “FileChgr1-Dev1” to read.
JobId 141: Ready to read from volume “vol001” on File device “FileChgr1-Dev1” (/opt/bacula/archive).
JobId 141: docker: docker local restore: container/mcache1/b97d4dd8806(…)

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:

Need to see all our backup solutions? Full hypervisor and database support.
Our server backup solutions include tools for Windows, Linux and more.
View Bacula Enterprise data backup and recovery program features.

Does Bacula support your storage type? Take a look at out storage backup solutions.
Read our vision on flexible and scalable backup software systems.
Interested in Sybase backup and recovery? Take a look at our SAP ASE backup solution.

Docker Container Backup and Restore with Volumes