vh
60367b307f
Bundles the inventory expansion since 2026-04-22:
- New host dirs (READMEs + ssh-target where dir name doesn't resolve):
ana-nas, ana-wg, esh-vm-db, nh3-nas, pbs-ana, pbs-nh3.
- New PFI VM snapshots (registered + key-installed 2026-04-23):
ana-filebot, pfi-ana-webhost, pfi-postgres, pfi-pteradactyl,
pfi-tacticalrmm, sf-ana-container, sfsrv-ana (system + proxmox).
- servers/irv-ml1: ONBOARDING.md (the first-time setup notes from when
the host was brought into the fleet) + ssh-target (10.100.79.3 over
the WG tunnel — name doesn't DNS-resolve from this workstation).
- servers/{ana-ml2,pfi-pve,sf-r630}/README.md: updates to capture BMC
IPs, the iDRAC vs OS hostname distinction (sf-r630 hardware =
sfsrv-ana OS), and the ana-ml2 Supermicro BMC (10.250.250.50,
distinct from the Dell R750xs iDRAC).
- configs/homepage/docker.yaml: irv-ml1-docker provider added so
homepage auto-discovers irv-ml1's stacks over the WG tunnel.
- docs/orientation.md: narrative fleet overview written for fresh
Claude sessions — sites, backup architecture, governing principles,
gotchas, where-to-look guide. Pointed at from CLAUDE.md.
ana-nas
Debian NFS/SMB file server at the Anaheim site — CT 109 (LXC) on pfi-pve. Serves the fleet's primary storage layer:
/mnt/backup→ restic target forrest-server-anaon ana-docker- backing storage for PBS-ANA's datastore
/mnt/docker→ compose/config shares/mnt/webdav→ WebDAV data (if still active)- Historically
/mnt/db(retired 2026-04-23 after the DB-off-NFS migration; pfi-postgres now uses local disk)
Network
- LAN IP: 10.250.50.50
- SSH:
ssh ana-nas(config alias →lkraven@10.250.50.50, key auth). lkraven is a standard user — sudo for root operations.
Container context
This is CT 109, not a VM. Bind-mounts into the LXC from pfi-pve's
ospool ZFS datasets:
| Inside CT | Host path on pfi-pve | Purpose |
|---|---|---|
/mnt/ospool-backup |
ZFS dataset | ospool snapshots staging |
/mnt/backup |
ZFS dataset | rest-server-ana + PBS-ANA data |
/mnt/db |
ZFS dataset | retired 2026-04-23 (postgres moved to local disk) |
/mnt/docker |
ZFS dataset | compose files + conf shares |
/mnt/pve-VMStorage |
ZFS dataset | alt VM storage pool |
/mnt/webdav |
ZFS dataset | WebDAV data |
Because these are bind-mounts, CT 109's own vzdump backup (LXC rootfs only) does NOT capture the data payload — the data lives on pfi-pve's ospool and is captured via the host's own backup chain.
Why CT 109 matters (SPOF warning)
As of 2026-04-23, ana-nas still affects these fleet services if it goes offline:
- rest-server-ana (on ana-docker) — its data dir is NFS-mounted from here; an outage kills file-level backups fleet-wide
- PBS-ANA datastore — NFS-mounted from here; an outage kills VM-level backups fleet-wide
- Cross-site restic rsync source (ana-nas → nh3-nas daily)
Not affected anymore (as of 2026-04-23 DB migration):
- pfi-postgres (VM 105) — now on local disk, ana-nas outages don't cascade into vaultwarden/gitea/paperless/zammad
Full recovery procedure: memory/incident_ana_nas_spof.md +
docs/runbooks/disaster-recovery.md.
DSM / rescue access
Under the hood this is vanilla Debian 12 with hand-configured NFS/SMB.
No appliance tooling — share tweaks go through /etc/exports +
systemctl reload nfs-server. Historical confusion about this box
being a TrueNAS appliance persists in naming (the Proxmox label was
PFI-ANA-TRUENAS for a long time) but it is plain Debian.
History note
ID-over-time: this host has been called VM 100, PFI-ANA-TRUENAS,
and now CT 109 / ana-nas. Memory file storage_ana_nas.md records
the VM→CT correction that was clarified 2026-04-23 from the vzdump
log output.
Refresh
scripts/refresh-server-info.sh ana-nas
Snapshot at system-details.txt.