Skip to content

Backups & Disaster Recovery

Strategy

3-2-1-ish: local backups on separate hardware, offsite copy in the cloud, config-as-code in git for anything that can be redeployed from scratch.

Local backups

  • Proxmox Backup Server runs on vault (TrueNAS box), separate physical disks from the VM storage it's backing up
  • All VMs/CTs backed up nightly at 02:00, incremental, 14 daily + 8 weekly retention
  • TrueNAS pool itself: nightly ZFS snapshots, 30-day retention, replicated to a second pool on the same box (protects against bad snapshots/bitrot, not drive failure — that's what RAIDZ2 is for)

Offsite backups

  • Proxmox Backup Server syncs a subset (Nextcloud, Immich, Vaultwarden, Home Assistant configs) to Backblaze B2 nightly, encrypted client-side
  • Restic job backs up TrueNAS config + critical datasets to B2 as a second, independent path in case PBS itself is the thing that breaks

Config as code

  • Proxmox/Ansible playbooks and Docker Compose files live in a private repo
  • Terraform manages Cloudflare DNS + Tunnel config
  • This docs site (public repo) is the human-readable index of all of it

Recovery runbook (summary)

  1. Single VM/CT lost → restore from PBS, ~5-15 min depending on size
  2. vault (TrueNAS) lost → replace hardware, restore pool from B2, re-point PBS/NFS; RTO ~1 day, RPO 24h
  3. Full site loss → rebuild Proxmox nodes from Ansible, restore all VMs from B2-synced PBS backups; RTO ~2-3 days, RPO 24h
  4. UPS/power event → NUT triggers graceful shutdown of all nodes at ~5 min remaining runtime; no action needed unless it doesn't come back cleanly on power restore

Known gaps

  • No offsite copy of Jellyfin media library (deliberate — it's all re-acquirable, not worth the B2 storage cost)
  • Untested: full bare-metal restore of vault itself has never been rehearsed end-to-end