Ok lets start from the basics to understand the concept.
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.
I do not want to discuss why we need a backup while it can be for anything like for testing or even securing your data. In our scenario I want to notice that most of the time app and data are in different containers so important part of the backup is not why , it is when !
You should be taking backup for your data everyday.And you may want to get backup of your app if there is a change on the system to save space in your hosting or backup space.
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 Backup DOCKER CONTAINERS ?
OK , I know you feel that I gave huge amount info to mix your mind. But it was really important to understand What,Why,How and some related questions before we go backup. Because you will need a backup strategy to save what you want. The much you know makes your backup strategy more convinent while restoring your data in emergency.
Anyway 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 123xyz456abc, and the name of our backup is our-docker-backup, the command will be:
docker commit −p 123xyz456abc 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.