Backup and restore strategies in Docker - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Backup a Docker volume using a container

What is the output of the following command sequence to backup a Docker volume named mydata into a tar file?

Docker

docker run --rm -v mydata:/data -v $(pwd):/backup alpine tar czf /backup/mydata_backup.tar.gz -C /data .
docker run --rm -v $(pwd):/backup alpine ls /backup

A mydata_backup.tar.gz

B mydata_backup.tar

C backup.tar.gz

D data_backup.tar.gz

💡 Hint

Check the tar file name specified in the command.

The tar file is named mydata_backup.tar.gz as specified in the tar command inside the container.

🧠 Conceptual

intermediate

Choosing backup strategy for Docker containers

Which backup strategy is best to ensure data persistence for a database running inside a Docker container?

A Backing up the database data directory using a Docker volume backup

B Backing up the container filesystem using docker commit

C Backing up the container logs using docker logs command

D Backing up the container image using docker save

💡 Hint

Think about where the database stores its data persistently.

Backing up the database data directory stored in a Docker volume ensures the actual data is saved. Container filesystem or image backups do not guarantee data consistency.

❓ Troubleshoot

advanced

Restore failure from Docker volume backup

You restored a Docker volume backup using the command docker run --rm -v mydata:/data -v $(pwd):/backup alpine tar xzf /backup/mydata_backup.tar.gz -C /data but the application cannot read the data. What is the most likely cause?

A The backup file is corrupted and cannot be extracted

B The volume <code>mydata</code> was not empty before restore causing permission conflicts

C The tar extraction did not preserve file permissions and ownership

D The container image alpine does not support tar extraction

💡 Hint

Consider what happens to file permissions when extracting tar archives inside containers.

Tar extraction inside a container may not preserve original file ownership and permissions, causing the application to fail reading data.

🔀 Workflow

advanced

Automated backup workflow for Docker volumes

Which sequence of commands correctly automates backing up a Docker volume appdata daily to a timestamped file in /backups directory on the host?

A mkdir /backups && docker save appdata > /backups/appdata_$(date +%F).tar.gz

B docker volume create appdata_backup && docker run --rm -v appdata_backup:/backup alpine tar czf /backup/appdata_$(date +%F).tar.gz -C /appdata .

C docker run --rm -v appdata:/data alpine tar czf /data/appdata_$(date +%F).tar.gz -C /data .

D mkdir -p /backups && docker run --rm -v appdata:/data -v /backups:/backup alpine sh -c 'tar czf /backup/appdata_$(date +%F).tar.gz -C /data .'

💡 Hint

Check volume mounting and tar command correctness.

Option D correctly mounts the volume and host backup directory, creates the backup file with date, and ensures the backup directory exists.

✅ Best Practice

expert

Best practice for restoring Docker container state with minimal downtime

What is the best practice to restore a Docker container's data volume and minimize downtime in a production environment?

A Stop the container, restore the volume backup, then start the container immediately

B Create a new volume, restore backup there, then update the container to use the new volume and restart

C Restore the backup directly into the running container's volume using docker exec

D Delete the container and volume, recreate both, then restore the backup

💡 Hint

Consider how to avoid data loss and downtime during restore.

Creating a new volume and restoring backup there allows testing and switching volumes with minimal downtime and risk.