Docker Data Missing After a Project Rename

A Compose project rename can cause services to use differently named resources. Your application may be looking at a new empty volume while the original data still exists. Inspect resource identity before running cleanup commands or initializing replacement data.

Stop making the state harder to understand

Avoid volume pruning, broad removal commands or repeatedly reinstalling the application. If the data matters, take a suitable backup or snapshot before recovery changes.

Record the old and new project names, working directories and Compose files. Docker's project-name documentation explains the sources that determine the Compose project name, including command-line and environment settings.

A folder rename is one possible cause; it is not proof that the old volume remains intact.

Inspect the actual mount

List the relevant volumes and inspect the application's current mounts. Compare the source volume name and container destination with the earlier configuration.

Docker's volume documentation explains that a volume has a lifecycle separate from its container. Recreating a container is not equivalent to deleting a named volume, but deletion commands can remove persistent resources explicitly.

Use a read-only inspection method where appropriate. Do not start two database processes against the same live data directory.

Separate three scenarios

Observation	Meaning to investigate
Old volume exists, new volume mounted	Resource identity changed
Correct volume, wrong destination	Application cannot see expected path
Correct mount, empty application	Database configuration, account or migration
Old volume absent	Backup and deletion history

A database can also appear empty because the application selected a different database or tenant. Check connection settings before declaring file loss.

Recover through the application's supported path

If the original volume is intact and compatible, restore the intended volume mapping with the application stopped as required. Review version compatibility before attaching old database files to a newly upgraded image.

If data is actually gone, use the backup and restore procedure for the application or database. Copying arbitrary live database files is not a universal restore method.

Keep the newly created empty resource until you understand whether it contains any new user data worth preserving.

Verify before removing anything

Check a known record, a recent record and one representative application workflow. Restart the service and confirm it still uses the intended volume.

Document a stable project name or explicitly managed volume identity for future deployments. Keep that choice separate from a backup strategy: stable names reduce confusion but do not protect against disk failure.

For a local AI stack, apply the same reasoning to downloaded models, chat history and document indexes. They may live in different persistent stores.

Related troubleshooting

• Test Whether Your PostgreSQL Backup Restores
• Docker Disk Full: Find the Growing Store

This guide draws on the linked documentation. Examples are illustrative unless explicitly identified as measured results.