Persistent application data across server recreation

Persistent application data outlives a replaced process or container only when the application's real data paths connect to storage with the required lifetime.

Persistent application data is the stored state that the server must carry into its next execution: configuration, databases, user records and any other required durable files.

The operating system, service manager or container can replace the process while those files remain. The persistence depends on where the application actually writes them.

A configured mount must cover the real data path

An original arrangement maps a volume to /config. If the application instead writes its database under /var/example/data in the container layer, that database does not acquire the volume's lifecycle merely because /config exists.

Location used by the application Lifetime to establish
Process memory Ends with the process
Container writable layer Can survive a restart but ends when that container is removed
Mounted volume or host directory Follows that storage resource's lifecycle
Temporary memory-backed storage Does not provide ordinary reboot persistence
Remote share Depends on the remote storage and accessible mount

The path names above are illustrative. Emby's supported package or image defines its own paths and settings.

A restart can hide a placement mistake

Suppose a container restarts repeatedly and its user state survives. That observation shows the files outlived those process restarts. It does not prove they will outlive container removal.

Recreating the container with another image exercises a different boundary. Verify that the replacement maps the existing persistent state, rather than a newly created empty volume.

Server state can also refer to media paths, credentials and plugin resources outside its own directory. Persisting the directory does not keep all those external dependencies available.

Some data can be regenerated

Caches and generated indexes may have supported regeneration paths. User histories, manually configured settings and plugin-owned records can have different value and recovery requirements.

Classify data by the application's documented role, rather than declaring every database a disposable index or every file below a directory named “cache” harmless.

Application-data backups preserve another usable generation. Persistence keeps the current storage relationship across an ordinary lifecycle event; backup and restoration address loss or unwanted changes to that relationship.

See Also

References