Export a Docker Container Filesystem Safely with docker export

You will create a tar archive of a Docker container's filesystem and verify that the archive is readable. The default command writes the archive to standard output, so you can redirect it to a deliberately chosen file or use --output to make the destination explicit. Allow about ten minutes for a small container, plus the time needed to check the resulting archive.

This guide covers Docker Community Edition CLI 29.8.1, installed from docker-ce-cli package version 5:29.8.1-1~ubuntu.24.04~noble on the reference machine. The command syntax is stable, but confirm the local help output before copying examples into automation.

1. Check the command and find the container

You need a Docker daemon, a container that still exists, and permission to talk to the daemon. Listing containers is read-only. Use --all because a stopped container can still be the one you need to export:

$ docker --version
Docker version 29.8.1, build 4a63305
$ docker export --help
Usage:  docker export [OPTIONS] CONTAINER

Export a container's filesystem as a tar archive
$ docker ps --all --format 'table {{.Names}}\t{{.Status}}'
NAMES       STATUS
app-old     Exited (0) 3 days ago
web-current Up 2 hours

Use the exact name or ID from your own output. Do not guess from an image tag: an image and a container are different Docker objects. If Docker reports a daemon connection error, fix the Docker context or daemon access first. Adding sudo can change which Docker configuration and daemon you use, so treat it as a deliberate privilege change rather than a generic repair.

$ CONTAINER='app-old'
$ DEST='/path/to/exports/app-old-2026-09-23.tar'
$ df -h "$(dirname "$DEST")"
$ docker inspect --format '{{.Name}}' "$CONTAINER"
/app-old

The assignment commands only set shell variables. Replace both placeholder values before running the export.

2. Export to a new archive

The shortest form sends tar data to standard output. Redirect it to a new filename rather than overwriting an existing backup:

$ docker export "$CONTAINER" > "$DEST"

There is normally no progress display because the archive is the command's output. A successful command returns to the prompt without printing the archive contents on screen. Shell redirection opens or truncates the destination before Docker finishes, so do not point > at the only copy of a useful archive.

The equivalent Docker option makes the output destination visible in the command itself:

$ docker export --output="$DEST" "$CONTAINER"

The local manual lists the short form -o and long form --output. Pick one style and use it consistently in scripts. Neither form adds compression; the result is a tar archive.

3. Verify the archive before relying on it

Check that the file exists and is non-empty, then ask tar to read its table of contents. These checks do not restore anything and do not change the container:

$ test -s "$DEST" && echo 'archive is non-empty'
archive is non-empty
$ tar -tf "$DEST" | sed -n '1,12p'
bin/
bin/sh
etc/
etc/hostname
etc/hosts
etc/passwd
var/

The names and ordering are container-specific. The useful result is a zero exit status and a list of paths. For a stronger check, let tar read the entire archive without writing extracted files:

$ tar -tf "$DEST" > /dev/null
$ printf 'archive check status: %s\n' "$?"
archive check status: 0

An archive that passes this check is readable as tar data. That does not prove that an application will start from it, or that data stored outside the container filesystem is present.

4. Keep mounted volume data separate

docker export does not export the contents of volumes associated with the container. If a volume is mounted over a directory, the archive contains the underlying directory from the container image or writable layer, not the live contents supplied by that volume. This is the most common reason for a surprisingly small or incomplete archive.

Inspect mounts before calling the archive a backup:

$ docker inspect --format '{{range .Mounts}}{{.Type}} {{.Source}} -> {{.Destination}}{{"\n"}}{{end}}' "$CONTAINER"
volume /var/lib/docker/volumes/app-data/_data -> /var/lib/app/data
bind /srv/app-config -> /etc/app

Your output may be empty, or it may list bind mounts and named volumes with different paths. Back up each required volume using a volume-aware procedure, and check bind-mounted source directories directly. Do not describe this tar file as a complete application backup unless those separate data sources have also been captured.

5. Protect the original and recover from a failed export

An export reads the container and does not remove or stop it. The destructive risk in this workflow is usually the destination file, not Docker itself. Use a temporary name in the same destination directory, verify it, then rename it into place. The rename is atomic on a normal local filesystem:

$ TEMP="${DEST}.part"
$ rm -f -- "$TEMP"
$ docker export --output="$TEMP" "$CONTAINER"
$ tar -tf "$TEMP" > /dev/null
$ mv -- "$TEMP" "$DEST"
$ ls -lh "$DEST"

The rm -f line removes only the explicitly named temporary file. Review TEMP before running it, especially in a script. The final mv replaces an existing destination, so keep the original under a different name if it must remain recoverable. If export or verification fails, do not rename the partial file. Remove the .part file after checking the error and leave the source container untouched.

6. Diagnose the usual failures

No such container means the name or ID is wrong, or the container has already been removed. Run docker ps --all again and check the current Docker context. A permission or daemon error is an access problem, not a reason to recreate the container.

If the archive is unexpectedly small, inspect mounts and remember that volumes are outside this command's export. If a destination file is missing or empty, check its parent directory, free space, and write permission. A non-zero Docker exit status means the export did not complete successfully; retain the container and investigate before retrying with a new temporary filename.