Podman Volume Backup

Storage / Guide 34 of 47 / Intermediate

• OSUbuntu 26.04 LTS (resolute)
• Podman5.7.0
• Runtimecrun 1.21
• Networknetavark 1.16.1
• TimeAbout 12 min
• Reviewed22 August 2026

Written against the versions above. Podman follows the distribution here rather than a vendor repository, so the version you get is the one Ubuntu shipped. The commands are stable across 5.x.

Before you start

• guide 60 - this backs up the kind of volume created there.

1. 1

   A volume with something in it

   Two lines of text in a named volume, standing in for whatever your application keeps there.

   $podman volume create dbdatadbdata$podman run --rm -v dbdata:/data docker.io/library/alpine sh -c 'echo "row one" > /data/table; echo "row two" >> /data/table; ls -l /data'total 4-rw-r--r--    1 root     root            16 Aug 22 12:11 table$podman run --rm -v dbdata:/data docker.io/library/alpine cat /data/tablerow onerow two

   Expected resultA volume containing a two-line file.

   Success conditionThere is data worth backing up.

2. 2

   Export, and look at what you got

   podman volume export dbdata -o ~/dbdata.tar

   That is the whole backup. Worth appreciating if you have done this with Docker, where there is no equivalent and the documented approach is to run a throwaway container with both the volume and a host directory mounted, and tar inside it.

   tar -tvf shows an ordinary archive with paths relative to the volume root:

   -rw-r--r-- 0/0    16 2026-08-22 12:11 table

   No leading directory, and ownership recorded as 0/0 - the in-namespace view. Because it is a plain tar you can inspect it, extract one file from it, or store it anywhere; nothing about it is Podman-specific.

   Restoring needs an existing volume - podman volume create dbrestore first, then import. It will not create the volume for you, which is a small annoyance and a deliberate guard against typos silently making new volumes.

   $podman volume export dbdata -o ~/dbdata.tar$ls -l ~/dbdata.tar-rw-r--r-- 1 sysadmin sysadmin 2048 Aug 22 12:11 /home/sysadmin/dbdata.tar$tar -tvf ~/dbdata.tar-rw-r--r-- 0/0              16 2026-08-22 12:11 table$podman volume create dbrestoredbrestore$podman volume import dbrestore ~/dbdata.tar$podman run --rm -v dbrestore:/data docker.io/library/alpine cat /data/tablerow onerow two

   Expected resultA 2048-byte tar containing table, and the same two rows read back from the new volume.

   Success conditionThe data is in a second volume you restored from a file.

3. 3

   Prove it is a copy, not a link

   Append a third row to the original, then read both:

   dbdata     row one / row two / row three
   dbrestore  row one / row two

   Independent. Obvious once stated, and worth actually checking, because "restored" and "still pointing at the same data" look identical until something diverges.

   What this is and is not. It is a file-level copy of a volume's contents, taken while nothing coordinates the write. For a database that is not a backup you can trust: exporting a running Postgres volume can capture a half-written page and restore to something that will not start. The engine's own dump - pg_dump, mysqldump - is the backup; volume export is right for uploaded files, caches, configuration and anything not being mutated under a transaction.

   For a database volume, stop the container first. A podman stop before the export costs seconds and turns an unreliable copy into a reliable one.

   $podman run --rm -v dbdata:/data docker.io/library/alpine sh -c 'echo "row three" >> /data/table'$podman run --rm -v dbdata:/data docker.io/library/alpine cat /data/tablerow onerow two$podman run --rm -v dbrestore:/data docker.io/library/alpine cat /data/tablerow onerow two

   Expected resultThree rows in the original and two in the copy.

   Success conditionYou have shown the two volumes diverge.

Troubleshooting

• podman volume import fails with volume does not exist.

  Why: Import does not create the volume.

  Fix:podman volume create <name> first.

• The restored volume has an extra directory level.

  Why: The tar was made by hand from a parent directory rather than by volume export.

  Fix:Archive from inside the volume root - tar -C /path/_data -cf out.tar . - so paths are relative.

• A restored database will not start.

  Why: The export was taken while the database was writing.

  Fix:Stop the container before exporting, or use the database's own dump tool. A file-level copy of live database files is not a backup.

• File ownership is wrong after a restore.

  Why: Tar recorded in-namespace uids, and the restoring user may have a different subuid base.

  Fix:podman unshare chown -R inside the volume. Same mechanics as guide 61.

Official sources

• podman-volume-export(1)
• podman-volume-import(1)