Your tar restore into a Docker named volume leaves the app's data directory empty. Why?

The restore looks like it worked — `tar` printed no errors, the helper container exited 0 — and then the service starts as if the volume were brand new. The email-digest builder comes up in its usual six seconds and reports zero queued digests instead of the 1,900 the backup contained. Every common cause is a path or identity mismatch, and they are quick to separate if you check them in order. ## 1. The archive's internal paths `tar` stores whatever path it was given. Two invocations that look equivalent are not: ``` tar czf /backup/digest.tgz /data # entries are data/queue/0001 tar czf /backup/digest.tgz -C /data . # entries are ./queue/0001 ``` The first form also prints a warning that it is removing the leading `/` from member names, which is easy to miss in a script. Restore that archive with `tar xzf /backup/digest.tgz -C /data` and the files land at `/data/data/queue/...`. The volume is not empty at all — it holds one directory named `data`, and the application, which reads `/data/queue`, sees nothing. Check before restoring, never after: `tar tzf /backup/digest.tgz | head` shows the entry paths in seconds. If you are stuck with a badly made archive, `--strip-components=1` on extraction removes the leading directory. ## 2. You restored into a different volume than the app reads The volume name in your restore command is a string, and `docker run -v <name>:/data` **creates** that volume if it does not exist rather than failing. A typo therefore produces a brand-new empty volume, a perfectly successful restore into it, and an application still reading the original. The same mismatch arrives through less obvious doors: * A Compose project renamed (or run from a different directory) prefixes its volume names differently, so the service binds a fresh volume. * A `VOLUME` instruction in the image creates a new **anonymous** volume every time a container is created without an explicit mount at that path. Restoring into your named volume then has no effect on the container, which is reading an anonymous one. * The service was recreated between the restore and the check, picking up a different mount. Ask the container, not your memory: ``` docker inspect -f '{{range .Mounts}}{{.Type}} {{.Name}} -> {{.Destination}}{{println}}{{end}}' digest ``` That prints exactly which volume is attached and at which path. ## 3. The destination path is one level off A restore can go into the right volume with the right relative paths and still miss, because the volume is mounted at a parent of the directory the process reads. If the container mounts `digest-data` at `/var/lib/digest` and the process opens `/var/lib/digest/queue`, then an archive whose entries start at `queue/` must be extracted with `-C /var/lib/digest`, not `-C /var/lib/digest/queue`. Mount the volume in your helper container at the *same* path the real container uses and the arithmetic stops being a puzzle. ## 4. Order of operations Restoring while the service is running is a coin flip: the process may have the old (empty) state open, may rewrite what you just restored, or may hold a lock file that the restored copy conflicts with. Stop the container, restore into the volume, then start it. This also avoids the reverse failure — starting the service first, letting it initialise the volume with a fresh empty layout, and then wondering why your restored files sit alongside it. ## 5. The near-miss: populated but unusable If the restore did land correctly but the service still behaves as though the data is missing, look at ownership rather than paths. A helper container running as root writes files owned by root; a service running as a non-root user may then fail to open them and, depending on the application, log a permission error or quietly start empty. Extract as the right UID, or use GNU `tar`'s `--numeric-owner` so the archive's original numeric ownership is preserved instead of being remapped by name. ## The habit that prevents all of this Verify the restore in the same command that performs it: after extracting, list the volume's root from the helper container and eyeball it. ``` docker run --rm -v digest-data:/data alpine sh -c \ 'tar xzf /backup/digest.tgz -C /data && ls /data' ``` Two seconds of output tells you whether you have `queue/` at the root or a stray `data/` wrapper, long before the service gets a chance to look confusing.