All volumes, containers and images are missing after docker compose upgrade

General
1

Recently My server (ubuntu 22.04) upgraded docker in a way that I had to change all my docker-compose" commands to “docker compose”.
After changing that on my pipeline and deploying to my server, my data is not visible anymore. Is it deleted and I must restore from backup or is it just somehow invisible?

Example of how my volumes are mapped:

services:
  db:
    image: postgres:12
    environment:
    ...
    volumes:
      - postgres_volume:/var/lib/postgresql/data

volumes:
  postgres_volume:
2

Run docker volume ls to list existing volumes on host.

3

That is not the problem. the volume exists but previous data is gone.

4

In the title

… images are missing after docker compose upgrade

That is impossible. Docker compose is just a client. It has nothing to do with the data handled by Docker CE. Now you mention upgading Docker in the content. Choosing a proper title is essential if you want to get help without leaving people confused. Volume names could indeed change after a compose upgrade if the project folder had some characters that handled differently in the new compose.

If you upgraded Docker from an old version that used a different storage driver, or just lost the /etc/docker/daemon.json file after the upgrade which contained the setting of a different storage driver, the new Docker will store files in a different folder and you need to change the storage driver back assuming it is still supported.

The other reason could be a changed docker data root path. Tht is also set in the daemon.json but by default it is /var/lib/docker

Check the content of the data root

sudo ls $(docker info --format '{{ .DockerRootDir }}')

Assuming you use Docker CE and not Docker Desktop, it should show the folders in the data root

buildkit  containers  engine-id  image	network  overlay2  plugins  runtimes  swarm  tmp  volume

If you see “overlay” instead of “overlay2” or you see any other folder that has lots of data and not in my output, that could mean the storage driver changed.

Even if the storage driver changed, that would not affect named volumes. So it could be the change of the data root and you need to find out what was the old one.

You can search for the engine-id file for example:

sudo find / -name engine-id

My output:

/home/ubuntu/.local/share/docker/engine-id
/var/lib/docker/engine-id

As you can see, the docker data root can be in your home if you have or had a rootless Docker context. Current contexts show in the output of

docker context ls

The context help can show you how to switch, but: docker context use CONTEXTNAME

Then see if your data is back.

Also, @bluepuma77’s suggestion can reveal if you just have a different volume name and the old one is still there just for example with a dash instead of an unuderscore or your project name changed and the missing volume data has nothing to do with a docker upgrade, but the fact that each volume in a swarm stack or compose project is prefixed with the project name. If your old volume still exists, you can restore the data. If not, your data is probably lost and hopefully you had a backup from which you can still restore most of your data.

5

Excellent point by @rimelek, check the existing volume names and try to use their explicit names in compose (doc):

volumes:
  db-data:
    name: "my-app-data"

But also note that compose will create new volumes when starting. So if the volumes are correct and empty, they probably have been removed/deleted before.

6

I don’t have any damon.json.
docker info says I am using overlay2 driver and have no extra folders.
I see the volumes name are changed and it is because I can no longer have the “name” property at the top of my rendered config file. Therefore in my pipeline I am piping the config result to the following:

| sed 's/^name:.*/version: "3.6"/'

Now that I have no “name” at the top, volumes start with another name.

7

again: docker compose started to add the project name to the output of docker compose config a while ago. Docker swarm never supported it, because it uses an explicit stack name instead. While docker swarm stacks require a version element, compose does not require it (it ignores with a warning if it exists, and removes it from the output of docker compose config).

While docker compose prefixes its resources with the project name, docker swarm stacks resources are prefixed with the stack name. Of course, you need to use the same project/stack name to continue using existing networks and volumes from that stack.

1 Like