[docs] TrueNAS decommission cleanup — remove references from active docs

TrueNAS VM 9000 was operationally decommissioned 2026-04-13; NFS has been
served by Proxmox host (192.168.1.127) since. This commit scrubs remaining
references from active docs. VM 9000 itself remains on PVE in stopped state
pending user decision on deletion.

In-session cleanup already landed: reverse-proxy ingress + Cloudflare record
removed; Technitium DNS records deleted; Vault truenas_{api_key,ssh_private_key}
purged; homepage_credentials.reverse_proxy.truenas_token removed;
truenas_homepage_token variable + module deleted; Loki + Dashy cleaned;
config.tfvars deprecated DNS lines removed; historical-name comment added to
the nfs-truenas StorageClass (48 bound PVs, immutable name — kept).

Historical records (docs/plans/, docs/post-mortems/, .planning/) intentionally
untouched — they describe state at a point in time.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

docs/runbooks/r730-ram-upgrade-272gb.md

@@ -146,8 +146,8 @@ qm shutdown 220; sleep 10
 for VMID in 102 300 103; do qm shutdown $VMID; done
 sleep 20
 
-# TrueNAS (wait for ZFS flush)
-qm shutdown 9000; sleep 60
+# TrueNAS (decommissioned 2026-04-13 — VM 9000 should already be stopped; skip if absent)
+qm shutdown 9000 2>/dev/null || true
 
 # pfSense (last — network gateway)
 qm shutdown 101; sleep 15

docs/runbooks/restore-etcd.md

@@ -7,7 +7,7 @@
 
 ## Backup Location
 - NFS: `/mnt/main/etcd-backup/etcd-snapshot-YYYYMMDD-HHMMSS.db`
-- Replicated to Synology NAS (192.168.1.13) via TrueNAS ZFS replication
+- Replicated to Synology NAS (192.168.1.13) via Proxmox host offsite-sync-backup (inotify-driven rsync)
 - Retention: 30 days
 - Schedule: Daily at 00:00
 

docs/runbooks/restore-full-cluster.md

@@ -8,8 +8,8 @@ Last updated: 2026-04-06
 - Proxmox host failure requiring fresh VM provisioning
 
 ## Prerequisites
-- Proxmox host (192.168.1.127) accessible
-- TrueNAS NFS server (10.0.10.15) accessible — or Synology NAS (192.168.1.13) for backups
+- Proxmox host (192.168.1.127) accessible, with NFS exports on `/srv/nfs` and `/srv/nfs-ssd`
+- Synology NAS (192.168.1.13) accessible for offsite backup restore if the PVE host backup disk is also lost
 - sda backup disk mounted at `/mnt/backup` on PVE host (or restore from Synology first)
 - Git repo with infra code
 - SOPS age keys for state decryption (`~/.config/sops/age/keys.txt`)

docs/runbooks/restore-mysql.md

@@ -130,7 +130,7 @@ kubectl rollout restart deployment -n <namespace>
 
 ## Alternative: Restore from sda Backup
 
-If TrueNAS NFS is unavailable but the PVE host is accessible:
+If the Proxmox host NFS mount is unavailable but the PVE host itself is accessible:
 
 ```bash
 # 1. SSH to PVE host
@@ -148,17 +148,17 @@ kubectl run mysql-restore --rm -it --image=mysql \
 
 ## Alternative: Restore from Synology (if PVE host is down)
 
-If both TrueNAS and PVE host are unavailable:
+If the PVE host itself is unavailable:
 
 ```bash
 # 1. SSH to Synology NAS
 ssh Administrator@192.168.1.13
 
 # 2. Navigate to backup directory
-cd /volume1/Backup/Viki/pve-backup/nfs-mirror/mysql-backup/
+cd /volume1/Backup/Viki/nfs/mysql-backup/
 
 # 3. Copy dump to a temporary location accessible from cluster
-# (e.g., via rsync to a surviving node, or restore TrueNAS first)
+# (e.g., via rsync to a surviving node, or restore PVE host first)
 ```
 
 ## Estimated Time

docs/runbooks/restore-postgresql.md

@@ -123,7 +123,7 @@ kubectl rollout restart deployment -n <namespace>
 
 ## Alternative: Restore from sda Backup
 
-If TrueNAS NFS is unavailable but the PVE host is accessible:
+If the Proxmox host NFS mount is unavailable but the PVE host itself is accessible:
 
 ```bash
 # 1. SSH to PVE host
@@ -142,17 +142,17 @@ kubectl run pg-restore --rm -it --image=postgres:16.4-bullseye \
 
 ## Alternative: Restore from Synology (if PVE host is down)
 
-If both TrueNAS and PVE host are unavailable:
+If the PVE host itself is unavailable:
 
 ```bash
 # 1. SSH to Synology NAS
 ssh Administrator@192.168.1.13
 
 # 2. Navigate to backup directory
-cd /volume1/Backup/Viki/pve-backup/nfs-mirror/postgresql-backup/
+cd /volume1/Backup/Viki/nfs/postgresql-backup/
 
 # 3. Copy dump to a temporary location accessible from cluster
-# (e.g., via rsync to a surviving node, or restore TrueNAS first)
+# (e.g., via rsync to a surviving node, or restore PVE host first)
 ```
 
 ## Estimated Time

docs/runbooks/restore-vault.md

@@ -93,7 +93,7 @@ kubectl get externalsecrets -A | grep -v "SecretSynced"
 
 ## Alternative: Restore from sda Backup
 
-If TrueNAS NFS is unavailable but the PVE host is accessible:
+If the Proxmox host NFS mount is unavailable but the PVE host itself is accessible:
 
 ```bash
 # 1. SSH to PVE host
@@ -115,17 +115,17 @@ vault operator raft snapshot restore -force ./vault-raft-YYYYMMDD-HHMMSS.db
 
 ## Alternative: Restore from Synology (if PVE host is down)
 
-If both TrueNAS and PVE host are unavailable:
+If the PVE host itself is unavailable:
 
 ```bash
 # 1. SSH to Synology NAS
 ssh Administrator@192.168.1.13
 
 # 2. Navigate to backup directory
-cd /volume1/Backup/Viki/pve-backup/nfs-mirror/vault-backup/
+cd /volume1/Backup/Viki/nfs/vault-backup/
 
 # 3. Copy snapshot to local workstation
-scp Administrator@192.168.1.13:/volume1/Backup/Viki/pve-backup/nfs-mirror/vault-backup/vault-raft-YYYYMMDD-HHMMSS.db ./
+scp Administrator@192.168.1.13:/volume1/Backup/Viki/nfs/vault-backup/vault-raft-YYYYMMDD-HHMMSS.db ./
 
 # 4. Restore via port-forward (same as above)
 ```

docs/runbooks/restore-vaultwarden.md

@@ -104,9 +104,9 @@ lvchange -an pve/$LV_NAME
 kubectl scale deployment vaultwarden -n vaultwarden --replicas=1
 ```
 
-## Alternative: Restore from sda NFS Mirror
+## Alternative: Restore from sda Backup Mirror
 
-If TrueNAS NFS is unavailable but PVE host is accessible:
+If the Proxmox host NFS mount is unavailable but the PVE host itself is accessible:
 
 ```bash
 # 1. SSH to PVE host