Container volumes and managed persistent storage
A container volume stores data outside one container's writable layer, with a managed identity and lifecycle that require deliberate reuse and backup.
A Docker volume is a managed storage resource that can be mounted into a container. Its contents live outside that container's writable layer.
For Emby application data, that allows a replacement container to reuse persistent state—provided it mounts the intended volume at the application's actual data path.
A volume has an identity and lifecycle
| Object | What happens when its container is removed |
|---|---|
| Container writable layer | Removed with the container |
| Named volume | Can remain and be reused unless a separate applicable removal operation deletes it |
| Anonymous volume | Can remain under its generated identity; reuse requires finding or retaining that association |
| Bind-mounted host tree | Follows the host storage's lifecycle |
Persistence does not mean that every cleanup command preserves all volumes. Volume-removal and pruning operations have their own scopes. A new named volume with a similar label is also not the old volume's content.
An original example is:
Container C1: /config -> volume V1; state generation G1
Container C2: /config -> volume V1; can open G1
Container C3: /config -> new volume V2; does not thereby contain G1
The paths and labels are fictional rather than a universal Emby image configuration.
Initial content can be copied
When an empty volume is mounted over a container directory that contains files, Docker normally copies those existing files into the volume. A nonempty volume mounted there instead covers the image's directory contents. Options such as volume-nocopy affect initialization.
That mechanism explains why changing an image's packaged defaults does not necessarily replace configuration already stored in an existing volume.
Persistence is not consistency or backup
Several containers can mount a volume, but simultaneous access must be supported by the applications using its files. Sharing one database directory between independent servers does not make those servers a coordinated database cluster.
Back up volume content through supported access and the application's consistency method. Docker documents managed volume access rather than treating its private host-storage layout as a directory to edit arbitrarily.
The volume preserves a data lifecycle. Application-data backup supplies another recoverable generation, and restoration verifies that it can be used with the intended software and paths.
See Also
- Container bind mounts and host-path mappings
- Persistent application data across server recreation
- Application-data backups and consistent server state