Skip to main content

​
Understanding Storage Drivers vs Volume Plugins

Storage drivers handle the low-level management of image and container layers. For persistent data, Docker uses volumes, which rely on volume driver plugins rather than storage drivers.
Volumes are decoupled from image storage drivers. They ensure your data persists across container restarts and removals.

​
Default Local Volume Driver

Docker’s default volume driver is local. It creates volumes on the host under /var/lib/docker/volumes. This driver is ideal for simple, on-host storage needs.

​
Third-Party Volume Driver Plugins

To integrate with external storage platforms, Docker supports many community and commercial volume plugins. Below is a summary of popular options:
PluginStorage Provider(s)Reference
Azure FileAzure File Storageazurefile
ConvoyVarious (via driver extensions)convoy
DigitalOceanBlock Storagedigitalocean
BlockerBlock Storageblocker
GCE PDGoogle Persistent Diskgcepd
ClusterFSClustered filesystemsclusterfs
NetAppNetApp storage arraysnetapp
RexRayAWS EBS/S3, EMC Isilon/ScaleIO, GCE PD, OpenStack Cinderrexray
PortworxPortworx clusterspxd
vSphereVMware vSphere storagevsphere
The image lists different types of storage and volume drivers, including AUFS, ZFS, and Azure File Storage, with a link to Docker documentation.
Ensure each volume driver plugin is installed and configured on your Docker host. Verify compatibility and installation steps in the Docker Storage Plugins guide.

​
Multi-Provider Example: RexRay

RexRay can provision volumes across multiple storage backends. To run a MySQL container with an AWS EBS volume: 
docker run -it \
  --name mysql \
  --mount type=volume,volume-driver=rexray/ebs,source=ebs-vol,target=/var/lib/mysql \
  mysql
When this container stops or is removed, your data remains intact on the attached EBS volume.
This approach extends to Kubernetes. Explore how Kubernetes PersistentVolumes and StorageClasses manage dynamic provisioning with external drivers.

Watch Video