Homelab / Storage & databases
V0.1 · Architecture & service documentation

WHERE THE STATE LIVES

Containers are replaceable.
Their data needs a plan.

The lab uses local disks, Docker volumes, NAS-backed storage and shared databases. Understanding which state belongs to each service is essential for changing or recovering it.

The storage layers used in the documented architecture
LayerTypical roleRecovery implication
VM disksGuest operating systems and state within the guestProxmox storage, VM backup and the application’s consistency requirements.
Local bind mountsFiles at a configured host pathThe path contents, permissions and configuration must be recovered deliberately.
Docker volumesApplication data managed through a volumeConfirm the actual backing storage; a named volume may use a remote mount.
NAS-backed mountsSelected application files and shared persistent dataAvailability depends on the mount and storage backend, not only the container.
External databasesRelational application stateRecover the matching database, users/permissions and application files.
Embedded databasesLocal state such as SQLite-backed application dataUse a consistent procedure and include the application’s persistent data.
Backup repositoriesRecovery copies or application snapshotsVerify job success, access requirements and functional restore evidence.

Database dependencies are part of the application.

MySQL supports documented consumers such as Semaphore, phpIPAM, Firefly III and Vaultwarden. PostgreSQL supports Zabbix, n8n, Paperless and Speedtest Tracker. Redis exists as a central service and also as a dedicated Paperless broker.

Those are not interchangeable dependencies. For example, Paperless metadata in PostgreSQL has to match the document files, while its broker has a different role. A central Redis instance should not be drawn into the Paperless path merely because it exists elsewhere.

Shared NAS storage is not automatic protection.

The NAS provides persistent storage for selected applications. If the only copy of a file is on that storage, it is still a single dependency. A share being available does not establish a backup policy, an independent copy or a successful restore.

The restore procedure also needs the right mount configuration and permissions. An application can start with an empty local directory when the intended mount is missing, which makes validating the backing layer important.

Active data and backups have different requirements.

Elastic illustrates the distinction: active index state and the NAS snapshot repository serve different purposes. A supported Elasticsearch snapshot is not the same thing as copying an arbitrary live data directory.

Relational databases need a consistency-aware backup method. Files and database records may need a coordinated recovery point, especially for document or attachment-oriented applications.

Classify state before choosing a backup.

  1. Rebuildable configuration: source definitions, Ansible tasks and Compose files.
  2. Unique application state: documents, transactions, subscriptions, history and application metadata.
  3. Secure recovery dependencies: credentials, encryption material and certificates, held privately.
  4. Disposable state: caches or generated artefacts only when explicitly classified as rebuildable.
  5. Unclassified state: do not delete or assume it is protected until its role is understood.

What is preserved in the public documentation.

Service pages describe the storage type and the data that must come back together. They omit export paths, volume identifiers, account names, dataset contents and credentials. The recovery guide follows the dependency order from those facts.