Master Docker Image, Container, and Volume Migration: Practical Commands and Tips

Deployed containerized services still require maintenance, and production environments often demand unconventional operations such as migrating images, containers, and volumes.

Image

Image migration is useful for offline environments where no external network or internal registry is available.

Typically an offline environment runs its own Docker Registry (e.g., Docker Hub, Harbor), but when none exists you must transfer images directly.

Save

# use stdout
docker save alpine > /tmp/alpine.tar
# or write to a file directly
docker save alpine -o /tmp/alpine.tar

Using the -o option is recommended because stdout may fail in some scenarios, such as remote SSH execution.

Load

# use stdout
docker load < /tmp/wekan.tar
# or read from a file directly
docker load -i /tmp/wekan.tar

Container

Container migration applies to services already running with complex state that cannot be restarted from scratch; the migration package includes the image.

Export

Prepare a running service and modify its environment.

$ docker run --rm -d --name test alpine tail -f /dev/null
9232f0c1dafe0f29918f281ca37bb41914677e818cb6f252abf3dab3be04fbb2
$ docker exec test touch proof
$ docker exec test ls -hl proof
-rw-r--r-- 1 root root 0 Nov 20 14:33 proof
# export the container
docker export test -o test.tar

Import

Stop the running service before importing.

$ docker kill test
test
# import the container
docker import test.tar test-img
sha256:e03727eeba7e16dd3acfcc7536f1244762508f9b6b9856e49cc837c1b7ffa444

Import creates a new image (similar to docker commit), which is generally not the preferred approach.

Verify the imported file:

$ docker run --rm -d --name test test-img tail -f /dev/null
ee29cb63bb2d3ed8ac890789ba80c4fe4078b9d5343a8952b6217d64b4dcbe23
$ docker exec test ls -hl proof
-rw-r--r-- 1 root root 0 Nov 20 14:33 proof

Volume

Volume migration is more complex because Docker does not provide a simple official solution.

The recommended approach is to use a helper container to package the volume data and transfer it via a mounted host directory.

Backup

First, create a volume.

$ docker run --rm -d --name test -v test-vol:/data test-img tail -f /dev/null
f4ff81f4c31025ff476fbebc2c779a915b43ba5940b5bcc42e3ef9b1379eaeab
$ docker exec test touch /data/proof
$ docker exec test ls -hl proof
-rw-r--r-- 1 root root 0 Nov 20 14:40 proof
# backup the volume
docker run --rm -v test-vol:/volume -v $PWD:/backup alpine tar cvf /backup/backup.tar volume
volume/
volume/proof

Alternatively, you can docker cp the archive from a running container, though this may affect the container.

Restore

First, clean up the previous container and volume.

$ docker kill testtest
$ docker volume rm test-voltest-vol

Restore the volume:

docker run --rm -v test-vol:/volume -v $PWD:/backup alpine tar xf /backup/backup.tar

Verify the restored data:

$ docker run --rm -v test-vol:/data alpine ls -ahl /data
total 8
drwxr-xr-x 2 root root 4.0K Nov 20 14:48 .
drwxr-xr-x 1 root root 4.0K Nov 20 14:50 ..
-rw-r--r-- 1 root root 0 Nov 20 14:40 proof

Conclusion

The three techniques described are unconventional. Image transfer should ideally rely on an internal Docker Registry rather than tar files, except for special cases like P2P distribution of large images.

Containers should be stateless; long‑running containers can be restarted or recreated without losing functionality, and any persistent state should be externalized.

Manual volume migration is possible with the methods above, but a robust plugin solution is recommended for production use.