This document contains best practices to consider when defining your backup and restore procedure.
Please note that this document mainly discusses committing a container as an image. This works on the container that does not use data volume. For containers with data volume, backup of the data volume must be taken separately.
Now a new image jupyter-backup will be created. Kindly note that this will not cover the data volume. You need to take the backup of data-volume (if any) separately.
To know this data-directory (data volume location) of a container, use the command ‘docker inspect container-name‘. You will get a section called “Mounts”. Location mentioned in “Source” is the data volume. You may directly backup this folder(here /var/lib/docker/volumes/my-volume/_data) to get backup of data volume.
Backing up the Containers
First of all, in order to backup the containers in docker, we’ll wanna see the list of containers that we wanna backup. To do so, we’ll need to run docker ps in our linux machine running docker engine with containers already created.
# nvidia-docker ps
After that, we’ll choose the containers we wanna backup and then we’ll go for creating the snapshot of the container. We can use nvidia-docker commit command in order to create the snapshot.
# nvidia-docker commit -p 1568555b36ef jupyter-backup
This will generated a snapshot of the container as the docker image. We can see the docker image by running the command nvidia-docker images as shown below.
# nvidia-docker images
As we can see the snapshot that was taken above has been preserved as a docker image. Now, in order to back up that snapshot, we have two options, one is that we can login into the docker registry hub and push the image and the next is that we can back up the docker image as tarballs for further use as it can be downloaded locally in your laptop or to the object storage like minio,s3.
If we wanna upload or backup the image in the docker registry hub, we can simply run docker login command to login into the docker registry hub and then push the required image.
# nvidia-docker login
Executing above command will pompt for user and passoword for docker hub registry.
# nvidia-docker tag e469e7acb748 hrrahman/jupyter-backup:test
# nvidia-docker push hrrahman/jupyter-backup
If we don’t want backup to the docker registry hub and want to save the image for future use in the machine locally or to the object storage like minio,s3. then we can backup the image as tarballs. To do so, we’ll need to run the following nvidia-docker save command.
# nvidia-docker save -o ~/jupyter-backup.tar jupyter-backup
To verify if the tarball has been generated or not, we can simply run ls inside the directory where we saved the tarball.
Restoring the Containers
Next, after we have successfully backed up our docker containers, we will now go for restoring those contianers which are snapshotted as docker images. If we have pushed those docker images in the registry hub, then we can simply pull that docker image and run it out of the box.
# nvidia-docker pull hrrahman/jupyter-backup:test
But if we have backed up those docker images locally or any other cloud storage like minio or s3 as tarball file, then we can easy sync from the respective source and load that docker image using nvidia-docker load command followed by the backed up tarball.
# docker load -i ~/jupyter-backup.tar
Now, to ensure that those docker images have been loaded successfully, we’ll run nvidia-docker images command.
# nvidia-docker images
After the images have been loaded, we will be going to run the docker container from the loaded image.
# nvidia-docker run –rm -p 8888:8888 -p 4040:4040 jupyter-backup:latest
We have documented how we can backup, restore docker containers using nvidia-docker out of the box. This tutorial is exactly the same for every platform of an operating system where nvidia-docker runs successfully.
The above methods make us comfortable to backup our containers so that we can restore them when needed in future. This can help us recover our containers and images even if our host system crashes or gets wiped out accidentally.
Disasters cannot be predicted or prevented, but you can always quickly bounce back from them if you maintain adequate backup plans for your business.