Shipping Docker Container Data

How to recover or migrate docker named volumes data

Photo: TheJournal.ie

Docker volumes are helpful in ensuring data persistence when working with docker containers. You’ll find volumes useful when you are implementing a disaster recovery or when you need to migrate data from one container to another.

I recently needed to migrate the underlying server for my docker environment and I didn’t want to start building my docker containers all over again. It would be easier for me to just pick up tasks I’m working on and go to the moon. That simple adventure inspired this write-up. I’ve limited the scope of this technical piece to just shipping container data only. It excludes backing up container images.

Docker data recovery btw 2 containers

Let’s create a container A

• step 1: create a named volume called site-content
• step 2: run the container using that volume
• step 3: create random website data inside the container

docker volume create site-content
docker run -it --rm -d -p 8080:80 --name web -v site-content:/usr/share/nginx/html nginx
docker exec -ti web bash
# edi

docker container A

Back up the container data

Proceed to backup the container volume data with the command below. The command creates another temporary container with an ubuntu docker image.

docker run --rm --volumes-from web -v $(pwd):/backup ubuntu tar cvf /backup/data.tar /usr/share/nginx/html

docker data backup

Let’s create Container B

Create container B and restore the website content in Container A to container B.

• step 1: create a named volume called site-content2
• step 2: run the container using that volume
• step 3: Restore the data by running a temporary container

docker volume create site-content2
docker run -it --rm -d -p 8081:80 --name web2 -v site-content2:/usr/share/nginx/html nginx

new docker container B — before data restore

Restore the container data

# Restore
docker run --rm --volumes-from web2 -v $(pwd):/backup ubuntu bash -c "cd /usr/share/nginx/html && tar xvf /backup/data.tar --strip 4"

new docker container B — after data restore

NAMES     MOUNTS          PORTS
web2      site-content2   0.0.0.0:8081->80/tcp, :::8081->80/tcp
web       site-content    0.0.0.0:8080->80/tcp, :::8080->80/tcp

One thing to note is that this data recovery concept doesn’t backup and restore the entire activity performed within containers. As shown below, the sizes of the two containers are different and this is due to the fact that the container I had to perform different options on the containers. To maintain identical containers during the migration, you should take extra efforts in committing changes to your container image using docker commit.

NAMES     MOUNTS          SIZE
web2      site-content2   1.26kB (virtual 133MB)
web       site-content    51.5MB (virtual 185MB)

Finally, before shooting for container data migration, you need to verify if your containers are using named volumes or if the data is mounted directly to the local machine running your containers. The example below shows that web3 data is mounted directly. You can easily take a backup of that path by creating a tar file of that location if you are migrating to another host.

┌[wale@NTNB020] - [/mnt/c/Users/Support/Dropbox/waleworks/docker-disaster-recovery]
└[$] <> docker ps -a --format "table{{.Names}}\t{{.Mounts}}"           
NAMES                MOUNTS
web3                 /run/desktop/m…
web2                 site-content2  
web                  site-content

The End!!!