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:

{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