HydraIssues

hydraguard is absent from knownServices, and the secrets boundary is undocumented
open improvement Priority: medium Project: hydrabackup Reporter: 1 Aug 2026 18:22

Description

## Two findings, from investigating a hydraguard backup claim

The hydraguard runbook stated "hydrabackup also backs up the mesh.yaml to hydramirror automatically." It does not, and cannot. Two separate causes, both worth fixing:

### 1. hydraguard is missing from knownServices

`internal/backup/scanner.go` lists 14 targets. `hydraguard` is not among them, so `/root/.hydraguard/mesh.yaml` is never discovered — on any host. hydrabackup is also not installed on either hub (`brussels-district-v2`, `89.167.57.232`), but installing it today would find zero services and upload nothing.

`mesh.yaml` is a good fit for what hydrabackup does: a YAML store, no secret material, and losing it costs real reconstruction effort (25 public keys and their address assignments). Adding the target looks like a one-line change:

```go
{Name: "hydraguard", DataDir: "/root/.hydraguard", Glob: "*.yaml"},
```

Note `/root/.hydraguard/` also contains `api.yaml` (bearer token, mode 0600) and `requests.yaml`. `skipBasenames` covers `config.yaml` but **not** `api.yaml` — so adding this target naively would upload a credential to the mirror. `api.yaml` needs adding to `skipBasenames` in the same change.

### 2. The secrets boundary is real but invisible

Excluding secrets is a deliberate and correct design choice — `skipBasenames`, `skipPrefixes` for `certs/`, and `Glob: "*.yaml"` all narrow scope. But nothing states it as a contract, which is exactly how a runbook came to claim coverage that was never on offer.

Suggest documenting it plainly in the README: **hydrabackup backs up YAML state, never secret material.** Anything holding a key or token needs a separate mechanism.

That matters right now because hydraguard's `hub.key` — 45 bytes, the identity of a 24-peer mesh, irreplaceable — is exactly the class of file hydrabackup will never protect. Tracked separately on the hydraguard side. Making the boundary explicit is what stops the next person assuming otherwise.

### Optional: report what was skipped

A log line naming skipped files would make the boundary visible in operation, not just in docs. "Backed up 3 files, skipped 1 (secrets)" is much harder to misread as full coverage than silence.

## Related

- Destination is hydramirror → mirror-a, which currently has no peer and is the sole copy of everything since February. Backing hydraguard state up *to* mirror-a inherits that risk.

## Done when

- [ ] `hydraguard` target added to `knownServices`
- [ ] `api.yaml` added to `skipBasenames` (in the same change, or the target must not land)
- [ ] README states the YAML-state-not-secrets contract
- [ ] hydrabackup deployed on the district hub, or a note recorded saying why not