How to Back Up Your Docker Volumes

Graphic showing the Docker logo

Docker volumes are applied to shop persistent info individually from your containers. Data that’s kept in a volume remains obtainable immediately after your containers cease, allowing for you to containerize stateful workloads.

While volumes outlive containers, this is not more than enough security for output applications. You ought to back again up your volumes so you can get well them following a disaster. Making frequent quantity backups makes sure you are equipped to restore your natural environment if your Docker host is compromised or facts is unintentionally deleted.

Running Quantity Backups

Docker doesn’t have a developed-in mechanism for backing up volumes or exporting their contents. You need to have to set up your individual option to accessibility the quantity and copy its details to your backup place.

Making a short term container that mounts the quantity you need to again up is generally the least difficult way to continue. Increase the --volumes-from flag to a docker run command to automatically mount an existing container’s volumes into your backup container. You can then use applications this sort of as tar and gzip to deposit an archive of the volume’s articles into your performing directory.

Here’s a complete case in point of this strategy:

# Build a container that merchants knowledge in the "mysql_knowledge" quantity
docker operate -d 
    --title mysql 
    -v mysql_details:/var/lib/mysql 

# Start off a short term container to back up the "mysql_information" quantity
docker run --rm 
    --volumes-from mysql
    -v $PWD:/backup-dir 
    ubuntu tar cvf /backup-dir/mysql-backup.tar /var/lib/mysql

The --volumes-from flag signifies the short-term backup container receives access to the mysql container’s volumes. The /var/lib/mysql directory inside of the backup container exposes the volume’s articles mainly because this is the route employed by the mysql container. Tarring the route will deliver an archive of your volume that you can use as a backup. It receives deposited into your doing the job listing simply because of the bind mount that’s set up by the -v flag.

The --rm flag will eliminate the backup container as soon as the command completes. This leaves the archive in your operating directory, all set to be moved to lengthy-time period storage. You can automate backup generation by including the docker run command as a cron process.

Restoring Your Backup

You can use a similar strategy to restore your backup. When you are replacing the contents of an existing volume, generate yet another non permanent container with the volume and a bind mount to your backup archive. Extract the contents of the archive into the volume’s mount path.

$ docker run --rm 
    --volumes-from mysql
    -v $PWD:/backup-dir
    bash -c "cd /var/lib/mysql && tar xvf /backup-dir/mysql-backup.tar"

This can be risky if containers are actively employing the quantity. Overwriting data files that are in use could induce glitches and unpredicted conduct. You can use the docker halt command to temporarily halt your containers right before bringing them back again up with docker start.

$ docker cease mysql

# Restore the backup
# ...

$ docker commence mysql

Build the volume just before you start out your container if you are restoring a backup to a new host:

$ docker quantity produce new_quantity

Then mount this quantity to your short-term container:

docker run --rm 
    -v new_quantity:/var/lib/mysql
    -v $PWD:/backup-dir 
    ubuntu tar cvf /backup-dir/mysql-backup.tar /var/lib/mysql

Beginning your software container with the same volume will present entry to the data files you’ve restored:

docker operate -d 
    --identify mysql 
    -v new_volume:/var/lib/mysql 

Tests these methods allows you test your backups will be usable if you at any time face a disaster.

Backing Up Volumes Immediately

The process outlined over is the suggested way to back again up Docker volumes. Having said that some situations could be improved served by immediately copying content material from where by volumes are stored on your host’s filesystem.

You’ll ordinarily come across the content material of your volumes in /var/lib/docker/volumes. Every single quantity receives its individual subdirectory, this sort of as /var/lib/docker/volumes/mysql. Within just this top rated-level path you are going to obtain a _data folder which contains all the data files stored inside the volume.

Archiving the /var/lib/docker/volumes directory can be a hassle-free way to swiftly backup anything on your host. You’ll require to use sudo while due to the fact everything under this route is owned by root.

Backing up volumes in this way is not recommended for regular use since it is not transportable across installations. Docker’s quantity driver program indicates quantity facts will not automatically be saved on your host’s filesystem – it could be on a network share or a further remote area. This technique really should only be attempted when you want a speedy backup ahead of you run routine maintenance on a unique machine.


Docker volumes have to have to be taken care of with treatment simply because they have your application’s persistent details. Generating frequent back ups will guard you from data decline in case your host is compromised or an errant container procedure deletes information by error.

Although you can build backups by archiving Docker’s set up listing, this should be prevented where ever achievable. Temporary backup containers may possibly appear to be cumbersome but they can be easily scripted and provide predictable success across volume drivers.

The moment you’ve established a quantity backup archive, recall to add it to remote storage as shortly as achievable. A backup stored on the machine it originates from will be no help if you lose access or a hardware failure takes place.

Leave a Reply