Harden Backrest CLI endpoint and restore recipes #226

New issue

Open

opened 2026-09-12 23:22:14 +01:00 by nimmo · 0 comments

nimmo commented

2026-09-12 23:22:14 +01:00

Owner

Problem

Phase 4 backup-runbook verification found that the repository's interactive restic recipes do not fully match the declared Backrest service and recovery requirements.

modules/services/backrest.nix uses mass-storage.mesh:8008, while justfiles/maintenance.just hard-codes 192.168.8.238:8008 for every backup-* restic recipe. The daemon and operator commands can therefore have different reachability, especially away from the LAN.
just backup-restore targets / with --overwrite always but invokes restic restore as the ordinary caller. Current plans contain root-owned service state as well as home data, so a disaster restore can partially write user-owned paths and then fail on privileged paths.
backup-restore-path creates its target before running restic and refuses any existing target. A failed restore leaves a directory that must be handled explicitly before retry, but the helper gives no completion marker or cleanup guidance.
The CLI endpoint/user/repository settings are duplicated literals instead of sharing the Nix options/configuration used by Backrest.

Scope

Give Backrest and interactive restic commands one evaluated endpoint/repository configuration.
Make full-host restore privilege and overwrite behavior explicit and safe.
Prevent or clearly detect partial restore completion.
Add regression coverage for target-exists, failed-restore, host filtering, and privileged full-restore behavior.
Update the wiki runbooks if the supported interface changes.

Acceptance criteria

Daemon and CLI recipes use the same mesh-capable repository endpoint.
Full restore cannot silently leave a mixed partial state because it lacked filesystem permissions.
Failed staged restores have a clear retry/cleanup path.
Repository settings have one declarative owner.
Tests cover failure and overwrite boundaries.
Backup and disaster-recovery runbooks can remove the transitional warning.

Discovered while executing wiki issue #222 against source commit 556df88494.

## Problem Phase 4 backup-runbook verification found that the repository's interactive restic recipes do not fully match the declared Backrest service and recovery requirements. 1. `modules/services/backrest.nix` uses `mass-storage.mesh:8008`, while `justfiles/maintenance.just` hard-codes `192.168.8.238:8008` for every `backup-*` restic recipe. The daemon and operator commands can therefore have different reachability, especially away from the LAN. 2. `just backup-restore` targets `/` with `--overwrite always` but invokes `restic restore` as the ordinary caller. Current plans contain root-owned service state as well as home data, so a disaster restore can partially write user-owned paths and then fail on privileged paths. 3. `backup-restore-path` creates its target before running restic and refuses any existing target. A failed restore leaves a directory that must be handled explicitly before retry, but the helper gives no completion marker or cleanup guidance. 4. The CLI endpoint/user/repository settings are duplicated literals instead of sharing the Nix options/configuration used by Backrest. ## Scope - Give Backrest and interactive restic commands one evaluated endpoint/repository configuration. - Make full-host restore privilege and overwrite behavior explicit and safe. - Prevent or clearly detect partial restore completion. - Add regression coverage for target-exists, failed-restore, host filtering, and privileged full-restore behavior. - Update the wiki runbooks if the supported interface changes. ## Acceptance criteria - [ ] Daemon and CLI recipes use the same mesh-capable repository endpoint. - [ ] Full restore cannot silently leave a mixed partial state because it lacked filesystem permissions. - [ ] Failed staged restores have a clear retry/cleanup path. - [ ] Repository settings have one declarative owner. - [ ] Tests cover failure and overwrite boundaries. - [ ] Backup and disaster-recovery runbooks can remove the transitional warning. Discovered while executing wiki issue #222 against source commit 556df88494686003b1c4f20c8e0b99b5afc16a6e.

nimmo added this to the Wiki Knowledge Architecture Rebuild milestone

2026-09-12 23:22:14 +01:00

nimmo added the

host:fleet

project:wiki-rebuild

labels

2026-09-12 23:22:14 +01:00

nimmo referenced this issue

2026-09-12 23:24:46 +01:00

[Wiki 4/5] Rebuild operational runbooks and the engineering handbook #222

nimmo referenced this issue

2026-09-12 23:34:08 +01:00