First find the state, and there are only three places it can be.
Named volumes. Listed with a volume listing command, and you can inspect each one to see which container uses it. This is where state should be.
Bind mounts. Visible in your compose files as host paths. Easy to find and easy to back up because they are ordinary directories.
Inside the container's writable layer. This is the one you correctly identified as a problem. Anything written to a path that is not a volume or a bind mount lives in the container and disappears the moment it is recreated, which happens on every image update.
To find that third category: run a diff on a running container, which shows what has changed relative to its image. Anything meaningful in there is unprotected state and the fix is to add a volume for that path, not to back it up where it is.
The cleanup worth doing while you are here: make every stateful path a named volume, consistently. Bind mounts are fine and they mix awkwardly with named volumes when you are trying to reason about what exists. One convention means the answer to what holds data is a single command rather than an archaeology exercise.
And note which containers genuinely hold nothing: most reverse proxies and workers do, and knowing that shortens the list a lot.