# Backup Policy

Backup classes for the Pi control-plane / `pi-config` system.

Goal:
- separate git-reproducible control plane from durable machine data
- know what must survive machine loss
- avoid treating runtime/cache as precious by default

## Classes

### Class A — git source of truth
Reproducible from GitHub clone.
Examples:
- `/home/sebas/pi-config`
- repo docs
- scripts
- extensions
- task-phase tooling source

Backup need:
- git remote is primary protection
- local snapshots optional

### Class B — reproducible with bootstrap
Not committed as durable data, but restorable from repo + install flow.
Examples:
- Bun install
- Node dependencies from `bun install`
- systemd user unit installation
- nginx route installation
- tmux helper setup
- cron/timer installation

Backup need:
- document and script the restore path
- raw backup of these is optional, not primary

### Class C — must back up durable data
Machine loss is painful without backup.
Examples:
- `/home/sebas/agents-database`
- `/home/sebas/work`
- `/home/sebas/outputs`
- selected `/home/sebas/archive`
- important user-created artifacts or task evidence not stored elsewhere

Backup need:
- required
- regular snapshots/copies
- should be restorable independently of git

### Class D — disposable or optional runtime
Can be regenerated or safely lost unless you specifically want audit history.
Examples:
- `/home/sebas/runtime/pi-jobs`
- `/home/sebas/runtime/pi-loop-runs`
- `/home/sebas/runtime/tool-usage/events.jsonl` (optional history)
- temporary logs
- top-level `/tmp` cleanup targets
- service scratch state

Backup need:
- usually none
- archive only when historical audit value matters

## Path classification

### `/home/sebas/pi-config`
- class: A
- reason: canonical control plane in git

### `/home/sebas/agents-database`
- class: C
- reason: canonical durable memory DB and artifacts

### `/home/sebas/work`
- class: C
- reason: active project/task work and durable task artifacts

### `/home/sebas/outputs`
- class: C
- reason: user-visible generated outputs often not reproducible cheaply

### `/home/sebas/archive`
- class: C or D depending on subtree
- reason: some items are important historical material, some are cold copies

### `/home/sebas/runtime`
- class: mostly D
- exceptions:
  - promote subtrees to C only if they hold unique operational data you care about

### `/etc/nginx/sites-available/kiosk`
- class: B
- reason: host integration should be restorable from repo docs/scripts

### `~/.tmux.conf` and shell helper definitions
- class: B
- reason: config should be reproducible, tmux session runtime is disposable

### secrets / env vars
- class: C but handled separately
- examples:
  - Telegram bot token
  - Telegram chat id
  - SSH keys used by helpers
- reason: not for git, but must survive restore securely

## Practical policy

### Must have backup
- `agents-database/`
- `work/`
- `outputs/`
- important secrets/keys

### Nice to have backup
- selected `archive/`
- selected task evidence if not already inside backed-up `work/`
- optional telemetry history if you care about ops history

### Usually do not back up
- generic runtime loops/jobs
- tmp files
- generated status files
- caches
- dependency installs

## Restore order reminder
1. git clone `pi-config`
2. bootstrap runtimes/services
3. restore durable data backups
4. run validation checks

## Rule of thumb
If losing it would mean losing truth, user work, memory, or proof, back it up.
If losing it only means rerunning tooling, bootstrap it instead.