Data Disappears After Container Recreation

Scenario

An application loses uploaded files after its container is replaced.

Gather Evidence

docker inspect CONTAINER_NAME
docker volume ls
docker volume inspect VOLUME_NAME

Replace the placeholders with actual resource names. Compare the application’s data directory with the mount destinations in inspect output.

Possible Causes

• Data was written into the old container’s writable layer.
• The replacement uses a different named volume.
• A Compose project name changed and a new project-scoped volume was created.
• A mount targets the wrong directory.
• A mount hides files that are still present underneath it.

Recovery Approach

If the original container or volume still exists, preserve it and identify the actual data before changing mounts. Restore from a verified backup when the original data has been removed. A newly created empty volume cannot recover a deleted container layer.

Prevent Recurrence

Use an explicit persistent mount at the application’s documented data path. Test replacement while preserving that volume. Document backup and restore procedures, including application consistency requirements for databases.

Verify

Run the persistent data lab. Confirm the file survives removal of its writer container.

Interview Answer

Container recreation and data persistence are separate concerns. The replacement must mount the same persistent storage at the correct application path.

Docker Roadmap