Chapter 3: Storage and Persistence

Centralized storage strategy using your NVMe SSD

3.2 Persistent Storage Architecture

NVMe SSD Storage Node Configuration Primary Storage Location:/mnt/swarm-data/ All persistent data is consolidated on the manager node (p0) with the following directory structure: /mnt/swarm-data/ ├── authentik/ │ ├── media/ # User avatars, logos │ ├── redis/ # Authentication cache │ └── templates/ # Custom email templates ├── bookstack/ │ └── data/ # Wiki configuration ├── homarr/ │ ├── configs/ # Dashboard configuration │ └── icons/ # Custom icons ├── mariadb/ # MariaDB database files ├── nextcloud/ │ └── data/ # File synchronization storage ├── paperless/ │ ├── data/ # Application data │ ├── media/ # Processed documents │ ├── export/ # Export directory │ └── consume/ # Incoming documents ├── portainer/ # Container management data ├── postgres/ │ └── data/ # PostgreSQL database cluster ├── traefik/ │ ├── certificates/ # SSL certificates │ └── dynamic/ # Dynamic configuration ├── uptime-kuma/ # Monitoring database └── vikunja/ └── files/ # Task attachments Cross-Node Data Accessibility Centralized Storage Benefits:

3.3 Database Storage Patterns

PostgreSQL Data Persistence Configuration: postgresql17_postgres: volumes: - postgresql17_master_db_data:/var/lib/postgresql/data Physical Location:/mnt/swarm-data/postgres/data Database Usage: Authentik: User authentication and authorization Paperless: Document metadata and search indices Vikunja: Task management and projects Nextcloud: File metadata and sharing Connection Pattern: environment: POSTGRES_HOST: postgres POSTGRES_USER: admin POSTGRES_PASSWORD: [SECRET] POSTGRES_DB: service_database MariaDB Configuration Configuration: mariadb_mariadb: volumes: - mariadb_bookstack_db:/var/lib/mysql Physical Location:/mnt/swarm-data/mariadb Database Usage: BookStack: Wiki content and user management Connection Pattern: environment: DB_HOST: mariadb DB_USERNAME: bookstack DB_PASSWORD: [SECRET] DB_DATABASE: bookstackapp Port Exposure: 3306/tcp for external access and administration

3.1 Volume Management Strategy

Bind Mount Configuration The cluster primarily uses bind mounts for persistent storage, providing direct filesystem access and simplified backup procedures. Standard Bind Mount Pattern: volumes: service_data: driver: local driver_opts: type: none o: bind device: /mnt/swarm-data/service-name/data Advantages of Bind Mounts: Direct filesystem access for backups Easy migration and maintenance Consistent storage location across services No Docker volume namespace conflicts Named Volume Usage Service-Specific Named Volumes: auth_authentik_media: Authentik media files auth_authentik_custom_templates: Custom templates auth_authentik_redis: Redis persistence postgresql17_master_db_data: PostgreSQL database mariadb_bookstack_db: MariaDB database nextcloud_nextcloud_data: Nextcloud files paperless_paperless_data: Document storage paperless_paperless_media: Media files paperless_paperless_export: Export directory traefik_traefik_certificates: SSL certificates uptime_uptime_kuma_data: Monitoring data portainer_portainer_data: Container management Anonymous Volume Handling Temporary Data Volumes: