Docker export creates a tar archive of a container’s filesystem. It can help inspect a writable container layer or transfer a filesystem snapshot for a narrowly defined task. It is not equivalent to exporting an image, and it is not a complete backup of a running application’s deployment and data.
The distinction matters when a tar file looks reassuringly large. Size does not prove coverage. Before using export for recovery, define exactly which files it includes, which mounted data it excludes, and which configuration must be preserved elsewhere to recreate the service.
Start with the object being exported
An image is a packaged build artifact with layers and configuration. A container is an instance created from an image, with runtime settings and a writable filesystem layer. Changes made inside that layer can appear in a container export even when they are absent from the original image.
That makes export useful for limited inspection, but it also makes its contents potentially less predictable than a reviewed build artifact. Manual changes, generated files, temporary data, and accidentally written credentials may all be present.
Name the purpose before running the command. A filesystem comparison, a migration experiment, and an application recovery backup require different evidence. Do not let a familiar archive format collapse those distinct workflows into one untested procedure.
Docker export does not include mounted volume contents
The official command documentation explicitly excludes volumes associated with the container. If a volume is mounted over an existing directory, export includes the underlying directory from the container filesystem rather than the contents visible through that mounted volume.
This is a particularly important trap for databases and upload directories. The application can see current data at a mount point while the exported archive contains empty or older underlying files. Inspecting only the path name in the tar listing can create a false impression that the application’s data was captured.
Before exporting, inventory named volumes, bind mounts, and other mounted paths through approved container inspection. Map each data path to its actual storage owner. Back up mounted data through a separate, consistency-aware method and record how the pieces relate.
Use a deliberate output destination
For an authorized container in a controlled environment, the basic command is:
docker container export --output=container-filesystem.tar app-containerThe container name is illustrative. Confirm the actual container identity and Docker context before using it. Exporting the wrong instance can reveal unrelated files or produce an archive that is useless for the intended recovery.
Use an output directory with appropriate permissions and enough free space. A restrictive creation mask can help protect newly created archive files, but also review existing directory permissions and any previous file at the chosen path.
Do not stream the archive into an untrusted destination merely for convenience. Treat transfer credentials, encryption, retention, and storage access as part of the export procedure. An archive containing configuration or operational data deserves the same protection as its source.
Establish application consistency separately
Exporting a running container does not create an application-level transaction boundary. Files can change while work is in progress, and a filesystem copy does not prove that a database or multi-file application state is recoverable.
For databases, prefer the database’s supported backup or snapshot procedure with its required coordination. For ordinary files, define whether writers must be stopped or quiesced. If stopping the container is part of the plan, coordinate downtime and verify a clean shutdown first.
Stopping a container still does not include its external volumes in export. Consistency and coverage are separate questions. A perfectly quiesced writable layer can remain incomplete as an application backup if the important data lives on mounted storage.
Record the source image identity, container identity, export time, and consistency method. Avoid including private runtime values in a broadly shared manifest; preserve sensitive configuration through an approved protected channel.
Know what restoration would require
A tar archive of filesystem contents does not recreate the complete deployment contract. Ports, networks, environment settings, restart policy, mounts, resource limits, and the intended startup command need their own authoritative configuration.
Docker import can create an image from filesystem content, but that does not restore the original image’s layer history and all operational metadata automatically. A successfully imported image may still fail to start correctly or run with the wrong assumptions.
Prefer rebuilding from reviewed source and deployment configuration when that is the actual recovery requirement. If an imported filesystem is necessary for a specialized migration, define its startup configuration explicitly and test it in isolation before granting production access.
Do not assume every runtime-generated file belongs in the restored environment. Machine-specific identifiers, temporary sockets, stale lock files, and credentials can be inappropriate outside the source instance. Review contents according to the intended destination, not only according to whether the archive extracted successfully.
Review archives without crossing a trust boundary
List archive entries before extraction. If the archive came from a compromised or untrusted container, treat it as untrusted content. Extract only into a dedicated workspace with limited privileges and appropriate handling for paths, links, ownership, and special files.
Avoid opening exported scripts or binaries by executing them. A filesystem inspection task does not authorize code execution. Malware analysis or forensic work needs its own isolated environment and procedure.
Checksums can detect transfer corruption when compared with a trusted recorded digest. They do not establish that the exported files were safe or that the source container was approved. Keep integrity, provenance, and application consistency as distinct checks in the manifest.
Prove scope with a controlled test
Create a test container with one file in the writable layer and another in a mounted volume. Export it and verify that the layer file appears while the mounted data does not. If a mount overlays a preexisting directory, inspect which underlying files the archive contains.
Then perform the intended recovery exercise in a disposable environment. Recreate necessary configuration, restore separately backed-up data, and run meaningful application checks. An archive listing is not a restore test.
Document any files deliberately excluded from recovery and where their authoritative replacements come from. Keep the procedure versioned with the application so new mounts or changed data paths do not silently invalidate it.
Frequently asked questions
Should I use export to transfer an image?
Use the image save workflow when you need an image archive with its intended image structure. Container export answers a different question about filesystem contents.
Does stopping the container make export complete?
No. It may help with some writers, but mounted data and deployment configuration still require separate handling and verification.
Can export help investigate manual changes?
Yes, within an authorized inspection workflow. Preserve source identity, handle the archive securely, and compare against a trusted baseline without executing unknown contents.
Practical takeaway
Use export for a deliberately scoped container-filesystem task. Inventory mounts, establish consistency, protect archive contents, and test restoration assumptions. A tar file is evidence of copied files, not evidence of a complete recoverable service.
Documentation and related reading
Consult the official documentation for exact behavior in the version you deploy. Continue with the Docker image save guide for the complementary implementation checks.
Continue with the Docker Guides for a broader practical reading path.
