updates

Author: mitchross

CLAUDE.md

@@ -311,7 +311,7 @@ spec:
 
 **When to use backup labels**:
 - User-generated content (photos, documents, uploads)
-- Database volumes (Postgres, Redis, etc.)
+- Non-CNPG database volumes (Redis, SQLite, etc.)
 - Configuration that's hard to recreate
 - AI model caches (large downloads)
 
@@ -324,7 +324,7 @@ spec:
 
 ### Application with Database (CNPG CloudNativePG)
 
-Databases use **CloudNativePG** with Barman backups to RustFS S3 — a separate backup path from the PVC/VolSync system.
+Databases use **CloudNativePG** with Barman backups to RustFS S3 — a **separate backup path** from the PVC/VolSync system. PVC backups use NFS + Kopia (shared repository with cross-PVC deduplication). Database backups use S3 + Barman (SQL-aware `pg_basebackup` + WAL archiving for point-in-time recovery). Each tool uses its native backup mechanism — see [backup-restore.md](docs/backup-restore.md#why-two-backup-systems-nfs-for-pvcs-s3-for-databases) for the full rationale.
 
 ```yaml
 # infrastructure/database/cloudnative-pg/<app>/cluster.yaml

docs/backup-restore.md

@@ -182,14 +182,42 @@ Kyverno generates a secret per-PVC with:
 /mnt/BigTank/k8s/volsync-kopia-nfs/
 ├── kopia.repository           # Kopia repository config
 ├── kopia.blobcfg              # Blob storage config
-├── p/                         # Pack files (deduplicated data)
+├── p/                         # Pack files (ALL deduplicated data from ALL PVCs)
 ├── q/                         # Index blobs
-├── n/                         # Manifest blobs
+├── n/                         # Manifest blobs (snapshots tagged by namespace/pvc-name)
 └── x/                         # Session blobs
 ```
 
 All PVC backups share the same Kopia repository, with snapshots tagged by namespace/pvc-name.
 
+### Cross-PVC Deduplication
+
+This shared repository design is a deliberate choice. Kopia uses **content-defined chunking** — files are split into variable-size chunks based on content boundaries, and each chunk is stored by its hash. If the same chunk exists anywhere in the repository (from any PVC, any namespace), it's stored only once.
+
+**What this means in practice:**
+- Delete and recreate an app → new PVC backs up → Kopia finds all chunks already exist → near-instant backup, almost zero new storage
+- Multiple apps with similar files (configs, timezone data, shared libraries) → one copy
+- Incremental backups only store changed chunks, not changed files
+- Storage grows by unique data, not by number of PVCs
+
+**Why not S3 + Restic?** VolSync also supports Restic to S3, but each PVC gets its own separate Restic repository — zero cross-PVC deduplication. Delete and recreate an app = full backup from scratch. More storage, more bandwidth, slower.
+
+## Why Two Backup Systems (NFS for PVCs, S3 for Databases)
+
+**PVC backups → NFS + Kopia** because:
+- VolSync's Kopia mover needs filesystem access for content-defined chunking and dedup
+- Direct NFS gives 10Gbps to TrueNAS with no HTTP overhead
+- No per-namespace S3 credentials — Kyverno just injects the NFS mount
+- One shared repository = cross-PVC deduplication (see above)
+
+**Database backups → S3 + Barman** because:
+- CNPG's built-in backup only supports Barman, and Barman speaks S3 (not NFS)
+- Barman does SQL-aware backups (`pg_basebackup` + continuous WAL archiving) for point-in-time recovery
+- Filesystem-level snapshots of running Postgres can be inconsistent without the WAL stream
+- CNPG has no native NFS backup option
+
+Each tool uses its native backup mechanism. Forcing either into the other's model would mean worse backups.
+
 ## Manual Restore
 
 To manually trigger a restore:

omni/cluster-template/cluster-template.yaml

@@ -5,9 +5,9 @@ name: talos-prod-cluster
 labels:
   cluster-id: "1"
 kubernetes:
-  version: v1.34.1
+  version: v1.35.0
 talos:
-  version: v1.11.6
+  version: v1.12.4
 patches:
 - name: disable-default-cni
   inline:
@@ -19,10 +19,10 @@ patches:
         disabled: true
 - name: dns-resolver
   inline:
-    machine:
-      network:
-        nameservers:
-        - 192.168.10.1
+    apiVersion: v1alpha1
+    kind: ResolverConfig
+    nameservers:
+    - address: 192.168.10.1
 - name: node-performance
   inline:
     machine:
@@ -41,6 +41,11 @@ kind: ControlPlane
 machineClass:
   name: proxmox-control-plane
   size: 3
+systemExtensions:
+- siderolabs/iscsi-tools
+- siderolabs/nfs-utils
+- siderolabs/qemu-guest-agent
+- siderolabs/util-linux-tools
 patches:
 - name: control-plane-performance
   inline:
@@ -64,11 +69,6 @@ patches:
       scheduler:
         extraArgs:
           kube-api-qps: "100"
-systemExtensions:
-- siderolabs/iscsi-tools
-- siderolabs/nfsd
-- siderolabs/qemu-guest-agent
-- siderolabs/util-linux-tools
 ---
 kind: Workers
 name: workers
@@ -77,7 +77,7 @@ machineClass:
   size: 3
 systemExtensions:
 - siderolabs/iscsi-tools
-- siderolabs/nfsd
+- siderolabs/nfs-utils
 - siderolabs/qemu-guest-agent
 - siderolabs/util-linux-tools
 patches:
@@ -106,7 +106,7 @@ machineClass:
   size: 1
 systemExtensions:
 - siderolabs/iscsi-tools
-- siderolabs/nfsd
+- siderolabs/nfs-utils
 - siderolabs/qemu-guest-agent
 - siderolabs/util-linux-tools
 - siderolabs/nonfree-kmod-nvidia-production
@@ -118,6 +118,11 @@ patches:
       nodeLabels:
         gpu-worker: "true"
         nvidia.com/gpu: "true"
+- name: gpu-network-dhcp
+  inline:
+    apiVersion: v1alpha1
+    kind: DHCPv4Config
+    name: ens18
 - file: patches/gpu-worker.yaml
 - name: longhorn-storage
   inline:

omni/cluster-template/patches/gpu-worker.yaml

@@ -1,13 +1,10 @@
 # GPU Worker Talos Configuration
 # Network topology:
 #   ens18 (net0/vmbr0) - Main LAN 192.168.10.x (DHCP) - 10G via switch to TrueNAS
+#   DHCP config moved to inline DHCPv4Config in cluster-template.yaml
 #
 # Storage traffic now goes through 10G switch (192.168.10.133)
 machine:
-  network:
-    interfaces:
-    - interface: ens18
-      dhcp: true
   kubelet:
     nodeIP:
       validSubnets: