# 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 for `rest-server-ana` on 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`.