Restic

Restic is a backup CLI, not a daemon. Treat a scheduled job or service manager as the execution layer. Every usable backup design proves four things: the source was captured, the repository is readable, retention is intentional, and a restore works in a separate target.

Operating contract

1. Discover before changing anything: restic version, backend type, repository format, source paths, credentials mechanism, schedule, retention policy, and recovery objective.
2. Keep repository passwords and backend credentials out of command history, logs, templates, and chat. Prefer a root/user-readable password file or a secret manager command over inline values.
3. Before any mutation, confirm target repository, source scope, exclusions, retention groups, schedule, maintenance window, and rollback/recovery path. Read-only discovery may proceed without confirmation.
4. Back up with stable host and tag conventions. Inspect the resulting snapshot, then test a restore into an empty, separate target. A successful backup exit code is not recovery evidence.
5. Treat forget, prune, key remove, rebuild-index, repair, migrate, and backend lifecycle rules as consequential operations. Preview where possible and keep a known-good recovery path.

First read-only discovery