ADR-0027's PBS trigger has fired, and its sync job was designed for a host smaug is not #485

ADR-0027
deferred Proxmox Backup Server on a single argument: a hypervisor backing up
its own guests to itself is not a backup, there was nowhere off-host to send
it, and PVE already does the snapshots a local-only answer would need — so PBS
would add a service for a capability that already exists.
#268 closed on that decision.

The deferral named its own trigger, and the trigger has fired. The roadmap
states it precisely: "PBS follows the NAS answering on 10.0.40.30, not the
box arriving." smaug has answered on 10.0.40.30 since 2026-09-16.

This issue exists so that a fired trigger with a closed tracker does not become
an accepted ADR nobody acts on — which is the failure mode
#101 was filed against, and the
same shape that left the NAS purchase untracked when #95 closed on its decision.

What has to be re-read, not just executed

ADR-0027 designed its sync job against a Linux host. Two things changed under it:

1. smaug runs TrueNAS
   (ADR-0040),
   not the Ubuntu Server ADR-0016 chose. build-the-nas.md §8 states the
   consequence: "ADR-0027's PBS, whose sync job wants another PBS instance — on
   TrueNAS that is PBS in a VM or a change to an NFS/SMB datastore." Those are
   materially different answers. A PBS VM on a NAS with 8 GB of ECC and one DIMM
   in four slots is a real resource question; an NFS or SMB datastore is not the
   verified, deduplicated, chunk-addressed thing PBS's sync job was chosen for.
2. There is still nowhere to send it. The pool erebor does not exist — the
   two Exos X20 drives have not landed. So the trigger has fired while the
   blocker has not cleared, and saying that plainly is the point: the work is
   unblocked in reasoning and blocked in storage.

ADR-0029 also gives PBS no disk on Saruman's pool, on the grounds that "there
is nothing to give it yet" — which becomes untrue on the day this is built, and
is part of the same re-read.

What it needs

• Re-read ADR-0027 against TrueNAS and decide: PBS in a VM on smaug, an
  NFS/SMB datastore, or a superseding ADR saying PBS is not the answer here
  at all. ADRs are not edited (ADR-0001), so whichever it is gets recorded
  as an amendment note or a new record. → Decided 2026-09-23: ADR-0053 (docs(adr): run PBS on Saruman with its datastore on smaug over NFS (#… #659), PBS on Saruman as golem, datastore on erebor/pbs over NFSv4.
• If a VM: size it against 8 GB of ECC with one of four DIMM slots filled,
  and say what gives way. If a datastore: say what is lost relative to the
  sync job ADR-0027 specified, rather than letting it be assumed equivalent.
• Give PBS a disk on Saruman's pool, which ADR-0029 deliberately withheld.
• A firewall rule, almost certainly — Saruman on VLAN 30 reaching in to
  10.0.40.30. That is the same shape as
  #446's ISO-store rule and
  should be ordered and verified the same way: above Block access to
  CasaBonita, checked from morpheus rather than from the UI.
• Say what is backed up and what is not. The lab has revert and not
  backup until this lands, and ADR-0027 names what changes when it does.

Blocked on the pool. Tracked under
#413.

Found reconciling the tracker against the smaug build. Successor to #268,
which closed on the decision rather than on the work.

Corrected 2026-09-19

Point 2 is false now: "there is still nowhere to send it — the pool erebor does not exist." It exists, ONLINE, 18 TB usable (#522). ADR-0027's blocker and its trigger have both cleared, so this is a decision plus a build, and nothing gates it.

The substantive question stands: PBS in a VM on 8 GB ECC versus an NFS/SMB datastore on smaug, which are not equivalent to ADR-0027's sync job. Moved to the Saruman milestone: it wants a disk on Saruman's pool that ADR-0029 withheld — which #527 is about to create — and a Saruman → smaug rule of the same shape as #446's. roadmap.md's ADR-0027 paragraph carries the pre-pool wording; the docs PR from this pass fixes it.