01 - Architecture Global Architecture and Request Flow Purpose The Bytek homelab provides privately hosted identity, collaboration, documentation, monitoring, project-management, and infrastructure services. The environment is hosted on Proxmox VE and follows these design principles: One major service per VM or LXC. Public services enter through a VPS instead of direct home-router port forwarding. WireGuard transports public traffic securely from the VPS to the home network. Traefik terminates HTTPS and routes requests according to the requested hostname. Authentik provides centralized authentication, multi-factor authentication, and application-access policies. Pi-hole provides LAN DNS, split DNS, and DHCP reservations. Data-bearing applications use a dedicated LVM-thin storage pool. Proxmox backups are stored on a separate internal HDD. Management interfaces remain accessible only from the LAN or a trusted VPN whenever practical. Critical services retain an authentication or console path that does not depend on Authentik. Main Components Component Address Primary Role Public VPS 38.29.213.101 Public HTTPS entry point WireGuard gateway 192.168.2.64 VPS-to-home tunnel gateway Pi-hole 192.168.2.65 DNS, split DNS, and DHCP reservations Nextcloud AIO 192.168.2.100 File storage and collaboration Uptime Kuma 192.168.2.115 Service monitoring Vikunja 192.168.2.121 Project and task management Authentik 192.168.2.162 Identity, authorization, and MFA Traefik 192.168.2.182 HTTPS reverse proxy Proxmox VE 192.168.2.254 Hypervisor BookStack Confirm current IP Infrastructure documentation Core Infrastructure Roles Proxmox VE Proxmox VE hosts the Bytek VMs and LXCs. Proxmox provides: Virtual-machine and container isolation. Virtual networking. Proxmox firewalling. LVM-thin storage. Scheduled backups. Short-term snapshots. VM and LXC restoration. Emergency console access. Proxmox management address: Open Proxmox VE Proxmox is intended for LAN or trusted VPN access only. Public VPS The VPS is the public entry point for applications hosted at home. The VPS receives public HTTPS traffic at 38.29.213.101 and forwards permitted traffic through WireGuard. The VPS prevents each home service from requiring its own public router port forwarding rule. WireGuard Gateway The home WireGuard gateway connects the VPS tunnel to the home LAN. The gateway performs: WireGuard tunnel termination. Controlled traffic forwarding. Firewall filtering. Network address translation where required. Delivery of public HTTPS traffic to Traefik. Pi-hole Pi-hole provides: LAN DNS. DNS filtering. Split-DNS records. DHCP reservations. Internal application-name resolution. Pi-hole allows the same application hostname to work both inside and outside the home network. Traefik Traefik is the central HTTPS reverse proxy. Traefik provides: HTTPS termination. Let’s Encrypt certificate management. Hostname-based application routing. Communication with private application backends. Authentik ForwardAuth for selected administrative services. Dashboard visibility into routers, services, and certificates. Authentik Authentik is the central identity provider. Authentik provides: Central user accounts. Multi-factor authentication. OpenID Connect. Proxy Providers. ForwardAuth. Group-based authorization. Email-domain policies. Embedded outpost services. External Application Traffic When an external user opens an application, traffic moves through the following components: The user enters an application hostname such as cloud.bytek.ca. WHC public DNS resolves the hostname to the VPS at 38.29.213.101. The VPS accepts the HTTPS connection on TCP port 443. The VPS forwards the traffic through the WireGuard tunnel. The home WireGuard gateway receives the tunneled traffic. The gateway forwards the request to Traefik at 192.168.2.182. Traefik examines the requested hostname. Traefik forwards the request to the correct internal application. Nextcloud Example A public Nextcloud request follows this path: The browser opens cloud.bytek.ca. WHC DNS returns 38.29.213.101. The VPS receives the connection. The VPS forwards the connection through WireGuard. The home gateway forwards the request to Traefik. Traefik forwards the request to Nextcloud at 192.168.2.100 on TCP port 11000. BookStack Example A public BookStack request follows this path: The browser opens docs.bytek.ca. WHC DNS returns 38.29.213.101. The VPS receives the connection. The VPS forwards the connection through WireGuard. The home gateway forwards the request to Traefik. Traefik forwards the request to the BookStack VM on TCP port 6875. Vikunja Example A public Vikunja request follows this path: The browser opens projects.bytek.ca. WHC DNS returns 38.29.213.101. The VPS receives the connection. The VPS forwards the connection through WireGuard. The home gateway forwards the request to Traefik. Traefik forwards the request to Vikunja at 192.168.2.121 on TCP port 3456. Internal Application Traffic LAN devices do not need to leave the home network and return through the VPS. Pi-hole resolves public application hostnames directly to Traefik. Hostname Internal Address cloud.bytek.ca 192.168.2.182 docs.bytek.ca 192.168.2.182 portal.bytek.ca 192.168.2.182 projects.bytek.ca 192.168.2.182 proxy.bytek.ca 192.168.2.182 status.bytek.ca 192.168.2.182 An internal request follows this path: The LAN client queries Pi-hole. Pi-hole returns 192.168.2.182. The client connects directly to Traefik. Traefik routes the request to the private application backend. This internal route provides: Lower latency. No unnecessary public internet path. No dependence on router hairpin NAT. The same HTTPS hostname inside and outside the home network. Valid Let’s Encrypt certificates for internal and external access. Proxmox Private Access Proxmox does not sit behind Traefik. Pi-hole resolves: pve.bytek.ca to 192.168.2.254. The administrative path is: The administrative workstation queries Pi-hole. Pi-hole returns 192.168.2.254. The workstation connects to Proxmox on TCP port 8006. The Proxmox host itself uses Quad9 at 9.9.9.9 rather than Pi-hole. This prevents the hypervisor from depending on Pi-hole for its own DNS resolution. Native OIDC Authentication The following services use native Authentik OpenID Connect: Nextcloud. Vikunja. BookStack. Proxmox VE. The authentication sequence is: The application redirects the browser to portal.bytek.ca. Authentik requests credentials and MFA. Authentik evaluates application group and policy bindings. Authentik redirects the browser to the application callback. The application validates the returned token. The application creates or matches the local user. The application applies its own internal permissions. OIDC Callback Reference Application Callback Nextcloud https://cloud.bytek.ca/apps/user_oidc/code Vikunja https://projects.bytek.ca/auth/openid/authentik BookStack https://docs.bytek.ca/oidc/callback Proxmox VE https://pve.bytek.ca:8006 Proxy Authentication Some services do not support native OIDC. Authentik Proxy Providers or ForwardAuth are used for: Traefik dashboard. Uptime Kuma dashboard. Traefik Dashboard The dashboard request follows this sequence: The administrator opens proxy.bytek.ca. Traefik invokes the Authentik ForwardAuth middleware. The embedded Authentik outpost validates the user. Authentik requires membership in bytek-admin. The authenticated request returns to the Traefik dashboard. Uptime Kuma The Uptime Kuma request follows this sequence: The administrator opens status.bytek.ca. Traefik forwards the request to the Authentik embedded outpost. Authentik validates the user and policies. The outpost forwards the request to Uptime Kuma. Selected public status-page paths may bypass authentication when intentionally configured. Standard User Access The Authentik group bytek-users grants access to: Nextcloud. Vikunja. BookStack. These applications also apply the Allow bytek.ca users policy. Policy engine mode is set to ALL. A user must therefore: Belong to bytek-users. Pass the Allow bytek.ca users policy. Administrator Access The Authentik group bytek-admin grants access to: Proxmox VE. Traefik dashboard. Uptime Kuma dashboard. Administrative applications also apply the Allow bytek.ca users policy. An administrator may belong to both bytek-admin and bytek-users. Application Access Matrix Service Authentication Intended Group Nextcloud Native Authentik OIDC bytek-users Vikunja Native Authentik OIDC bytek-users BookStack Native Authentik OIDC bytek-users Proxmox VE Native Authentik OIDC bytek-admin Traefik dashboard Authentik ForwardAuth bytek-admin Uptime Kuma dashboard Authentik Proxy Provider bytek-admin Pi-hole Local authentication Administrators on LAN Nextcloud AIO AIO local authentication Administrators on LAN WireGuard gateway SSH key authentication Administrators VPS SSH key authentication Administrators Service URLs Service URL Access Scope Authentik Open Authentik Public through Traefik Nextcloud Open Nextcloud Public through Traefik Vikunja Open Vikunja Public through Traefik BookStack Open BookStack Public through Traefik Uptime Kuma Open Uptime Kuma Authentik-protected Traefik dashboard Open Traefik Administrators only Proxmox VE Open Proxmox LAN or VPN only Nextcloud AIO https://192.168.2.100:8080/ LAN or VPN only Break-Glass Access Central authentication must not be the only recovery path. Proxmox VE Recovery account: root@pam Access methods: Private hostname, private IP, or Proxmox console Authentik Recovery account: Local Authentik administrator Access methods: Public portal or direct private backend during recovery Nextcloud Recovery account: Local Nextcloud administrator Recovery path: /login?direct=1 BookStack Recovery account: Dedicated local BookStack administrator Recovery method: Switch AUTH_METHOD from oidc to standard Uptime Kuma Recovery account: Original Kuma administrator Recovery method: Restore direct private access and re-enable local authentication Traefik Recovery method: SSH into the Traefik VM and restore a known-good dynamic configuration Secondary authentication: Retained Basic Auth while ForwardAuth is being validated Pi-hole Recovery method: Private IP, local credentials, and Proxmox console Critical Dependencies Function Dependency Chain Public applications WHC DNS, VPS, WireGuard, Traefik, application Internal applications Pi-hole, Traefik, application OIDC login Application, Traefik, Authentik, Authentik database Certificate issuance Traefik, DNS, Let’s Encrypt, WHC cPanel API Monitoring Uptime Kuma, Pi-hole, monitored services Backups Proxmox, mounted backup HDD Failure Impact Failed Component Expected Impact Pi-hole Internal hostname resolution may fail VPS External access fails; LAN access should continue WireGuard External VPS ingress fails Traefik HTTPS routing fails Authentik New SSO logins fail Proxmox VM management fails; running guests may continue Backup HDD New backups fail; live services continue Nextcloud File and collaboration services fail Vikunja Project-management service fails BookStack Documentation service fails Uptime Kuma Monitoring and alerts fail Security Boundaries The following services must not be exposed directly to the public internet: Proxmox TCP 8006. Pi-hole administration. Nextcloud AIO TCP 8080. Nextcloud AIO backend TCP 11000. Authentik backend TCP 9000. Uptime Kuma backend TCP 3001. Vikunja backend TCP 3456. BookStack backend TCP 6875. Traefik internal dashboard service. SSH on home service VMs. Docker socket or Docker API. Operational Principles Validate the direct application backend before troubleshooting Traefik. Validate Traefik locally before troubleshooting the VPS. Validate Pi-hole before changing application OIDC settings. Confirm container DNS after a power failure. Preserve local recovery accounts. Do not regenerate OIDC secrets until connectivity is proven. Do not delete Traefik certificate storage during troubleshooting. Do not treat snapshots as backups. Test restored VMs with their network adapter disconnected. Update documentation after each validated infrastructure change. Document Control Owner: Bryan Gagne-Plante Last verified: YYYY-MM-DD Backup coverage: Partial Recovery tested: Partial Offsite backup: Not configured Known limitations: One Proxmox host and one local backup location Network and Address Reference Purpose This page documents the addressing, DNS, routing, and network-access model used by the Bytek homelab. Use this page when: Creating a new VM or LXC. Adding a Pi-hole reservation. Creating a Traefik route. Troubleshooting an unreachable service. Adding a new public hostname. Configuring a firewall rule. Diagnosing split-DNS or browser secure-DNS issues. Home Network Setting Value LAN subnet 192.168.2.0/24 Default gateway 192.168.2.1 LAN DNS server 192.168.2.65 Router Bell Giga Hub 2.0 Public domain bytek.ca Public DNS provider WHC cPanel Public VPS address 38.29.213.101 Internal HTTPS proxy 192.168.2.182 Service Address Inventory Service Private Address Primary Ports Access Scope WireGuard gateway 192.168.2.64 Existing WireGuard port and SSH Infrastructure Pi-hole 192.168.2.65 TCP and UDP 53 LAN Nextcloud AIO 192.168.2.100 TCP 8080 and TCP 11000 LAN management and Traefik backend Uptime Kuma 192.168.2.115 TCP 3001 Authentik proxy and monitoring Vikunja 192.168.2.121 TCP 3456 Traefik backend Authentik 192.168.2.162 TCP 9000 Traefik and internal services Traefik 192.168.2.182 TCP 443 LAN and public ingress Proxmox VE 192.168.2.254 TCP 8006 and TCP 22 LAN or trusted VPN BookStack Confirm current IP TCP 6875 Traefik backend Public Hostname Inventory Service Public Hostname Public DNS Destination Nextcloud cloud.bytek.ca 38.29.213.101 BookStack docs.bytek.ca 38.29.213.101 Authentik portal.bytek.ca 38.29.213.101 Vikunja projects.bytek.ca 38.29.213.101 Traefik dashboard proxy.bytek.ca 38.29.213.101 Uptime Kuma status.bytek.ca 38.29.213.101 The public application records are managed through the WHC cPanel Zone Editor. The public DNS destination is the VPS, not the private application address. Private Hostname Inventory Service Private Hostname Pi-hole Destination Nextcloud cloud.bytek.ca 192.168.2.182 BookStack docs.bytek.ca 192.168.2.182 Authentik portal.bytek.ca 192.168.2.182 Vikunja projects.bytek.ca 192.168.2.182 Traefik dashboard proxy.bytek.ca 192.168.2.182 Uptime Kuma status.bytek.ca 192.168.2.182 Proxmox VE pve.bytek.ca 192.168.2.254 All HTTPS application hostnames point internally to Traefik. Proxmox is the exception because Proxmox does not sit behind Traefik. Public DNS Flow When an external client opens a hosted application: The client requests an application hostname such as docs.bytek.ca. Public DNS at WHC returns 38.29.213.101. The client connects to the VPS. The VPS forwards permitted traffic through WireGuard. The home WireGuard gateway forwards the request to Traefik. Traefik routes the request to the matching internal service. Public DNS must never point directly to a private address such as 192.168.2.121. Private RFC1918 addresses are not reachable from the public internet. Internal Split-DNS Flow When a client on the home LAN opens a hosted application: The client queries Pi-hole at 192.168.2.65. Pi-hole returns Traefik’s address, 192.168.2.182. The client connects directly to Traefik. Traefik routes the request to the matching backend. This allows internal clients to use the same application hostnames and HTTPS certificates as external clients. Benefits include: No unnecessary trip through the VPS. Lower latency. No dependency on hairpin NAT. Consistent HTTPS URLs. Consistent Authentik callback addresses. Simpler application configuration. Public and Private DNS Comparison Hostname Public Result Internal Pi-hole Result cloud.bytek.ca 38.29.213.101 192.168.2.182 docs.bytek.ca 38.29.213.101 192.168.2.182 portal.bytek.ca 38.29.213.101 192.168.2.182 projects.bytek.ca 38.29.213.101 192.168.2.182 proxy.bytek.ca 38.29.213.101 192.168.2.182 status.bytek.ca 38.29.213.101 192.168.2.182 pve.bytek.ca No public record 192.168.2.254 Proxmox DNS Design The Proxmox host intentionally uses Quad9: DNS server: 9.9.9.9 Proxmox does not use Pi-hole as its general resolver. This design prevents the hypervisor from depending on a guest VM or LXC for DNS. As a result, the Proxmox host normally resolves: portal.bytek.ca to 38.29.213.101 The Proxmox OIDC server-to-server path can therefore travel through: Proxmox. Public VPS. WireGuard. Traefik. Authentik. If this public path causes a future OIDC reliability issue, a single entry may be added to the Proxmox /etc/hosts file: portal.bytek.ca to 192.168.2.182 This would route only Authentik directly through local Traefik while keeping general Proxmox DNS on Quad9. Proxmox Private Hostname The hostname pve.bytek.ca is intentionally private. Pi-hole resolves it to: 192.168.2.254 No public WHC record should exist for pve.bytek.ca. The Proxmox interface is accessed at: Open Proxmox VE Access should be limited to: The home LAN. A future trusted VPN. An emergency SSH tunnel through the VPS if intentionally configured. TCP port 8006 must not be exposed directly to the public internet. Application Backend Reference Traefik connects to each application using a private IP and backend port. Hostname Backend Destination cloud.bytek.ca 192.168.2.100:11000 docs.bytek.ca BookStack private IP on TCP 6875 portal.bytek.ca 192.168.2.162:9000 projects.bytek.ca 192.168.2.121:3456 status.bytek.ca Uptime Kuma or Authentik outpost proxy.bytek.ca Traefik internal dashboard service Backend ports should be accessible only from the systems that require them. For example: Vikunja TCP 3456 should be available to Traefik and Uptime Kuma. BookStack TCP 6875 should be available to Traefik and Uptime Kuma. Nextcloud TCP 11000 should be available to Traefik. Authentik TCP 9000 should be available to Traefik and approved internal services. Uptime Kuma TCP 3001 should eventually be limited to the Authentik outpost. DHCP Reservations Infrastructure services should use DHCP reservations based on their virtual NIC MAC addresses. Known reservations include: Service Reserved Address Nextcloud 192.168.2.100 Uptime Kuma 192.168.2.115 Vikunja 192.168.2.121 Additional infrastructure reservations should be confirmed in Pi-hole before being added to this page. To locate a VM MAC address on Proxmox, use: qm config Locate the net0 line and record the MAC address. For an LXC, use: pct config Reservations prevent unexpected address changes from breaking: Traefik routes. Firewall rules. Uptime Kuma monitors. Authentik providers. Pi-hole records. Administrative bookmarks. Documentation. Firewall Source Reference Known infrastructure sources include: Source Address WireGuard gateway 192.168.2.64 Pi-hole 192.168.2.65 Uptime Kuma 192.168.2.115 Authentik 192.168.2.162 Traefik 192.168.2.182 Proxmox 192.168.2.254 Typical firewall requirements include: Traefik to application backend ports. Uptime Kuma to direct health endpoints. Authentik outpost to Uptime Kuma. LAN administrator devices to SSH. Pi-hole DNS from approved LAN clients. WireGuard gateway to Traefik. Proxmox management access from the LAN or VPN. Avoid broad any-source rules when a specific infrastructure source can be used. Browser Secure-DNS Warning Firefox and Zen can use DNS over HTTPS and bypass Pi-hole. This can cause private hostnames such as pve.bytek.ca to fail even when Pi-hole is configured correctly. Recommended browser setting: DNS over HTTPS: Off or Default Protection If an internal hostname fails only in the browser: Confirm the hostname resolves from the operating system. Query Pi-hole directly. Disable forced DNS over HTTPS. Clear the operating-system DNS cache. Clear the browser DNS cache. Close idle browser sockets. Completely restart the browser. Useful Windows commands: Resolve-DnsName pve.bytek.ca nslookup pve.bytek.ca 192.168.2.65 Test-NetConnection pve.bytek.ca -Port 8006 Clear-DnsClientCache ipconfig /flushdns Expected result: pve.bytek.ca resolves to 192.168.2.254. TCP port 8006 succeeds. DNS Validation Verify an Internal Record Use: nslookup portal.bytek.ca 192.168.2.65 Expected result: portal.bytek.ca resolves to 192.168.2.182. Verify a Public Record Through Pi-hole Use: nslookup google.com 192.168.2.65 Expected result: One or more public addresses are returned. Verify Public WHC DNS Query an authoritative WHC server and confirm that application hostnames resolve to: 38.29.213.101 Verify a Backend Port Examples: nc -zv -w 5 192.168.2.121 3456 nc -zv -w 5 192.168.2.162 9000 nc -zv -w 5 192.168.2.254 8006 A successful connection confirms TCP reachability but does not prove the application is healthy. Network Troubleshooting Order When a hostname is unreachable, troubleshoot in this order: Confirm the destination VM or LXC is running. Confirm the destination still owns the documented IP. Confirm the hostname resolves to the expected address. Confirm the required TCP or UDP port is reachable. Test the application directly by private IP. Test the application through Traefik locally. Test the application through the public VPS path. Check browser secure-DNS settings. Review Proxmox and guest firewall rules. Review application and Traefik logs. Do not change DNS, firewalling, and application configuration simultaneously. Address-Change Procedure If a service IP changes: Create or update the Pi-hole DHCP reservation. Renew the guest lease or restart the guest. Confirm the guest owns the new address. Update the Traefik backend. Update Proxmox firewall source or destination rules. Update Uptime Kuma monitors. Update Authentik Proxy Provider internal hosts if applicable. Update documentation. Search service configuration for the old address. Test internal and external access. A stale backend IP previously affected several deployment steps, so the old address should be searched across configuration files after every change. Document Control Owner: Bryan Gagne-Plante Last verified: YYYY-MM-DD Public DNS provider: WHC cPanel Internal DNS provider: Pi-hole LAN subnet: 192.168.2.0/24 Known limitation: Browser DNS over HTTPS can bypass Pi-hole Items to confirm: BookStack private IP and remaining DHCP reservations Storage Architecture Purpose This page documents the physical disks, Proxmox storage pools, logical-volume layout, filesystem mounts, and intended storage roles within the Bytek homelab. The storage architecture separates: Proxmox and application operating-system disks. Large user and application data. Local Proxmox backups. Temporary snapshots and rollback points. The main design goal is to prevent application data, operating-system disks, and backups from competing for the same physical storage role. Storage Overview Storage Tier Approximate Capacity Proxmox Storage Primary Purpose System NVMe 1 TB local-lvm Operating systems and infrastructure services User-data NVMe 4 TB user-data Large application and user-data disks Backup HDD 4 TB pve-backup Proxmox VZDump backups Physical Disk Inventory Linux Device Approximate Usable Size Device Type Current Role /dev/nvme1n1 931.5 GiB NVMe SSD Proxmox operating system and local-lvm /dev/nvme0n1 3.6 TiB NVMe SSD user-data LVM-thin storage /dev/sda 3.6 TiB WDC HDD Dedicated Proxmox backup storage Linux device names such as /dev/sda can change between boots or hardware changes. Permanent references should use: Filesystem UUIDs for mounted filesystems. /dev/disk/by-id/ paths for physical-device operations. Proxmox storage IDs for normal VM and backup management. System NVMe Physical Device Setting Value Linux device /dev/nvme1n1 Approximate capacity 931.5 GiB Partition table GPT Primary volume group pve Partition Layout Partition Approximate Size Purpose /dev/nvme1n1p1 1007 KiB Boot support partition /dev/nvme1n1p2 1 GiB EFI system partition /dev/nvme1n1p3 930.5 GiB Proxmox LVM physical volume Logical Volumes Logical Volume Approximate Size Purpose pve-root 96 GiB Proxmox root filesystem pve-swap 8 GiB Proxmox swap pve-data 794.3 GiB Proxmox LVM-thin pool Proxmox Storage The pve-data thin pool appears in Proxmox as: Storage ID: local-lvm Storage type: LVM-thin Intended Use The system NVMe stores: Proxmox VE. Infrastructure VM and LXC operating-system disks. Application operating-system disks. EFI disks. Small configuration volumes. Temporary Proxmox snapshots. Docker application configuration stored inside service VMs. Current Workloads The system NVMe currently stores operating-system disks for services such as: WireGuard. Pi-hole. Uptime Kuma. Traefik. Authentik. Nextcloud. Vikunja. BookStack. Storage Policy Use local-lvm for: VM and LXC operating-system disks. Infrastructure services. Small persistent application datasets. VM configuration disks. Temporary snapshots. Avoid using local-lvm for: Large Nextcloud user libraries. Large Plex media libraries. Large game-server libraries. Backup archives. Long-term media collections. User-Data NVMe Physical Device Setting Value Linux device /dev/nvme0n1 Approximate capacity 3.6 TiB Device purpose Large application and user data LVM volume group lvm1 Thin pool data LVM-Thin Layout The user-data NVMe contains: lvm1-data_tmeta lvm1-data_tdata lvm1-data These components represent: Thin-pool metadata. Thin-pool data. The visible LVM-thin pool. Proxmox Storage The thin pool appears in Proxmox as: Storage ID: user-data Storage type: LVM-thin Volume group: lvm1 Thin pool: data Configured chunk size: 256 KiB Intended Use The user-data NVMe stores: Nextcloud user files. Large application-data disks. Future game-server data. Future media-storage testing. Other user-generated content. Current Major Workload Nextcloud has a separate virtual data disk on user-data. Setting Value Nominal virtual-disk size 500 GB Guest filesystem ext4 Guest mount point /mnt/nextcloud-data Nextcloud data directory /mnt/nextcloud-data/ncdata The Nextcloud operating system remains on local-lvm, while user files remain on user-data. This separation makes it easier to: Expand the user-data disk. Monitor data growth. Keep the operating-system disk smaller. Apply different backup decisions to application and data disks. Migrate data disks independently in the future. Thin Provisioning The local-lvm and user-data storage pools use LVM-thin provisioning. A thin-provisioned virtual disk does not immediately consume its full nominal capacity. For example, a 500 GB virtual disk initially consumes only the physical blocks that have actually been written. Important Consequence The sum of all nominal virtual-disk sizes may exceed the physical capacity of the thin pool. This is safe only when actual usage is monitored. If the thin pool reaches full physical allocation, affected VMs may experience: Write failures. Filesystem corruption. Application outages. Database failures. Guest crashes. Thin-Pool Monitoring Review Proxmox storage usage using: pvesm status Review LVM-thin usage using: lvs -a -o vg_name,lv_name,segtype,lv_attr,lv_size,data_percent,metadata_percent Monitor both: Data percent Metadata percent Suggested operational thresholds: Utilization Response Below 70 percent Normal monitoring 70 to 84 percent Review growth and available capacity 85 percent or higher Immediate capacity planning Near 100 percent Critical risk of storage failure These thresholds are operational recommendations and should be adjusted based on growth rate and workload importance. Backup HDD Physical Device Setting Value Linux device /dev/sda Partition /dev/sda1 Approximate usable capacity 3.6 TiB Filesystem ext4 Partition table GPT Stable WWN 0x5000cca097c44d7e Permanent Mount Setting Value Mount point /mnt/pve/pve-backup Proxmox storage ID pve-backup Proxmox content type VZDump backup files Mount method Filesystem UUID through /etc/fstab The filesystem UUID is used instead of /dev/sda1 because Linux device letters can change. Mount Options The backup filesystem uses: Read-write mounting. noatime to reduce unnecessary metadata writes. Mount-Point Protection The Proxmox storage uses mount-point validation. This prevents Proxmox from treating the empty directory /mnt/pve/pve-backup as valid storage when the HDD is not mounted. Without this protection, a failed HDD mount could cause backups to be written to the Proxmox root filesystem. That could fill the root filesystem and disrupt the hypervisor. Backup-HDD Intended Use The backup HDD stores: Scheduled VM backups. Scheduled LXC backups. Manual baseline backups. Upgrade rollback backups. Restore-test source archives. The backup HDD must remain dedicated to backups. Prohibited Backup-HDD Uses Do not use the backup HDD for: Active VM disks. Active LXC root filesystems. Nextcloud user files. Plex media. Steam game-server data. Docker application data. Download staging. General file storage. Temporary application caches. Mixing active workloads with backups would: Increase disk contention. Increase wear. Reduce available retention. Expand the failure impact. Make recovery planning less predictable. Storage Placement Rules Workload Preferred Storage Infrastructure OS disk local-lvm Application OS disk local-lvm Nextcloud user data user-data Vikunja database and files Current VM OS disk unless growth requires separation BookStack database and files Current VM OS disk unless growth requires separation Plex configuration and metadata local-lvm or a dedicated application disk Plex media Future dedicated media storage Game-server executable files Dedicated game-server disk or user-data Game world and save data user-data with backup enabled Proxmox backup archives pve-backup Short-term snapshots Same thin pool as the source disk Future Plex Storage The RTX 2060 Plex VM should not use the backup HDD for media. Recommended placement: Plex operating system on local-lvm. Plex configuration and metadata on NVMe-backed storage. Plex transcode directory on temporary fast storage. Movies and television content on future dedicated media storage. Music content on future shared media storage if Navidrome is deployed. A temporary media disk may be created on user-data for initial testing. Long-term media storage should ideally use: A dedicated HDD. A mirrored HDD pair. A dedicated storage pool. A NAS or storage server. Media capacity planning must account for continued Nextcloud growth on user-data. Future Game-Server Storage A dedicated game-server VM should use: Operating-system disk on local-lvm. Game data or world-save disk on user-data. Backup enabled for unique save data. Application-level save backups where supported. Steam-installed server binaries can usually be downloaded again. Unique game-world data, configuration files, allowlists, bans, and mods require backup. Storage Expansion Principles Before adding physical storage, decide whether the new disk is intended for: Operating-system workloads. Application data. Media. Backups. Redundancy. Offsite synchronization. Avoid adding unrelated physical disks into an existing unmirrored LVM volume group merely to increase capacity. Safer future expansion patterns include: Create a new independent Proxmox storage pool. Move selected VM disks to the new pool. Replace a smaller disk with a larger disk. Add mirrored storage for critical data. Add a dedicated media-storage pool. Add a dedicated Proxmox Backup Server. Add an encrypted offsite backup target. Failure-Domain Considerations System NVMe Failure Expected impact: Proxmox root filesystem may be lost. Infrastructure VM and LXC operating-system disks may be lost. The user-data NVMe and backup HDD may remain physically intact. Recovery would require: Proxmox reinstallation or system-disk restoration. Reconnection of existing storage. VM and LXC restoration from pve-backup. User-Data NVMe Failure Expected impact: Nextcloud user-data disk may be lost. Other large application-data disks may be lost. VM operating-system disks on local-lvm may continue working. Backups on the HDD may remain available. Backup HDD Failure Expected impact: Live services continue running. New backup jobs fail. Existing local recovery points are lost. There is no current offsite replacement copy. Complete Host Failure Expected impact: All running services become unavailable. The internal backup HDD may be inaccessible until moved or the host is repaired. A severe electrical or physical event could affect all three storage devices. This is the primary reason a future offsite or separate-host backup is required. Snapshot Policy Proxmox snapshots are used as short-term rollback points. Recommended snapshot use cases: Before a major operating-system upgrade. Before changing Authentik integration. Before changing Traefik routing or middleware. Before changing a Docker stack. Before database migrations. Before a major application upgrade. Before enabling GPU passthrough. Snapshots are not backups because: Snapshots remain on the same storage. A physical disk failure destroys the snapshot with the live disk. Long-lived snapshots consume thin-pool capacity. Snapshot growth can create unexpected storage pressure. Delete unnecessary snapshots after the associated change has been validated. Avoid snapshots with RAM unless restoring the exact running state is required. Storage Validation Confirm Proxmox Storage Use: pvesm status Expected storage IDs include: local local-lvm user-data pve-backup Confirm Backup Mount Use: findmnt /mnt/pve/pve-backup The source should be /dev/sda1. Confirm Backup Capacity Use: df -h /mnt/pve/pve-backup Confirm Physical Devices Use: lsblk -e7 -o NAME,PATH,SIZE,TYPE,FSTYPE,PTTYPE,MOUNTPOINTS,MODEL,SERIAL,WWN Confirm Thin-Pool Utilization Use: lvs -a -o vg_name,lv_name,segtype,lv_attr,lv_size,data_percent,metadata_percent Confirm Storage Configuration Use: cat /etc/pve/storage.cfg Do not store credentials or secrets in the documentation when recording command output. Disk-Health Monitoring The backup HDD should be monitored using SMART. Stable backup-HDD identifier: /dev/disk/by-id/wwn-0x5000cca097c44d7e Useful checks: smartctl -H /dev/disk/by-id/wwn-0x5000cca097c44d7e smartctl -A /dev/disk/by-id/wwn-0x5000cca097c44d7e smartctl -x /dev/disk/by-id/wwn-0x5000cca097c44d7e Important attributes include: Reallocated sector count. Current pending sector count. Offline uncorrectable sector count. UDMA CRC error count. Temperature. Power-on hours. SMART error log. Pending or uncorrectable sectors require immediate review. NVMe health should also be reviewed periodically using the appropriate NVMe SMART tools. Capacity Review Checklist Perform a storage review when: Nextcloud user data grows significantly. Plex media is introduced. A game-server data disk is created. Backup retention consumes unexpected space. Thin-pool utilization exceeds 70 percent. Snapshot count increases. A disk reports SMART warnings. Another physical disk is being considered. Review: Physical free capacity. Thin-pool data utilization. Thin-pool metadata utilization. Snapshot count. Backup-HDD free space. Nextcloud data growth. Media-storage requirements. Restore-capacity requirements. Backup-retention effectiveness. Current Limitations The current storage architecture does not provide disk redundancy. The system NVMe, user-data NVMe, and backup HDD are independent single devices. The architecture protects against some logical failures through backups, but does not provide uninterrupted operation after a physical disk failure. The local backup HDD is in the same: Physical server. Building. Power environment. Administrative security boundary. Future priorities include: Dedicated media storage. A third backup copy. Offsite encrypted backups. Separate Proxmox Backup Server hardware. Storage redundancy for critical user data. Document Control Owner: Bryan Gagne-Plante Last verified: YYYY-MM-DD System storage: 1 TB NVMe on local-lvm Application-data storage: 4 TB NVMe on user-data Backup storage: 4 TB HDD on pve-backup Storage redundancy: None Offsite backup: Not configured Recovery tested: Partial Known limitations: Single-device storage tiers and one physical host