GP - Fotolia
The original goal of containerization, as exemplified by Docker, was to provide an environment for short-lived, temporary instantiations of applications. The benefit was the ability to develop, deploy and implement applications without the overhead and maintenance of physical servers or virtual machines. While Docker container backup can rapidly deploy code and be more responsive to a business, emerging adoption has shown that persistent data and persistent containers are still requirements when backing up with Docker.
Docker containers have both an operating system and a data component. The OS comes from Docker images that can be stored centrally and backed up from there.
There is no need to back up a container image from the host in a Docker container backup; it can simply be restarted. However, containers are also configurable with local networking and application settings. These parameters can either be pushed to the container using a management framework, such as Puppet, Chef and Ansible, or backed up and restored for the container.
External data for containers is presented via volumes. The most recent way to do this in the latest releases of Docker is by associating a mount point within the container with a share or directory on the host. The container itself has no real understanding of where the data comes from, but simply reads and writes data into one or more mount points that are presented to it. All of the data management tasks occur at the host, which is where Docker container backup could be improved.
With any backup, one of the main issues of restoring data is in identifying the backup itself. This process becomes even more complex with a container, where the container name may be generic and the container GUID is simply a random 64-byte character string.
A Docker container backup needs to ensure that any data backed up (either the container configuration or volume) is associated with an application that can be easily identified by the business. This guarantees that however the container is started, the application data is independently backed up and stored in a consistent fashion. One way to accomplish this is by creating backup ID files on the host as part of the configuration process.
The complete guide to Docker containers
Common issues with running Docker on VMs
A closer look at the Docker framework
Dig Deeper on Backup and recovery software
Related Q&A from Chris Evans
Agentless data backups offer some major advantages over agent-based backups. The technology should be used wherever possible, and it can be ... Continue Reading
Using Oracle Recovery Manager for database backup and restore? Explore the Oracle backup script and command process, with options for specific ... Continue Reading
While ransomware remains a top threat, it is not the only cybersecurity problem data backup admins need to keep on their radar. Here are three more ... Continue Reading