# Purpose-Specific S3 Bucket Architecture

## Motivation

The original `hermes-live-sync.sh` was a monolithic script pushing everything — Hermes state, Docker volumes, Caddyfile, systemd configs — into a single `s3://hermes-vps-backups/live/` prefix. This made it hard to:

- Grant granular IAM access (Docker volumes accessible to scripts that only needed Hermes configs)
- Replicate specific data categories to different regions
- Audit which scripts own which files
- Reason about data isolation during DR

## Normalization (2026-07-08)

Split into 5 buckets plus 1 legacy bucket:

| Bucket | Primary Script | Data |
|---|---|---|
| `hermes-vps-backups/live/` | `hermes-live-sync.sh` | Hermes state: config.yaml, .env, state.db, sessions/, skills/, profiles/, cron/, memory_store.db |
| `hermes-vps-backups/hermes-full-backup/` | `hermes-backup.sh` | Daily full archive tarballs (~350MB compressed) |
| `itpropartner-system-configs/` | `hermes-system-config-sync.sh` | System configs: Caddyfile, systemd services, ops scripts, SSH keys, .env + AWS creds |
| `itpropartner-docker-volumes/` | `hermes-docker-sync.sh` | Docker volume data: Docuseal, Vaultwarden, TwentyCRM, SearXNG, Ollama |
| `mikrotik-ccr-backups/` | `run-wisp-backup.sh` + `wisp-backup.py` | Router configs (home gateway, wisp gateway) + logs |
| `itpropartner-backups/` | (legacy — manual) | Old signatures, test files, migrated router config copies |

## Exclusions

The `hermes-vps-backups/live/` sync excludes: audio_cache, image_cache, cache, sandboxes, kanban, node, bin, logs, *.lock, .skills_prompt_snapshot.json, .update_check.

The `itpropartner-system-configs/` scripts/ sync excludes: `.backups/`, `migration-backup/`, `*.pyc`, `__pycache__/`.

The `itpropartner-system-configs/` ssh/ sync excludes: known_hosts, authorized_keys, config.

## Script Locations

All scripts at `/root/.hermes/scripts/`:
- `hermes-live-sync.sh` — Hermes state only
- `hermes-system-config-sync.sh` — System configs
- `hermes-docker-sync.sh` — Docker volumes

## Dashboard

The ops portal (`/var/www/ops/backups.html`) tracks all 6 bucket paths via `ops-data-collector.py` (every 5 min). The dashboard JS maps bucket keys to display names via `DISPLAY_NAMES`:

```js
'hermes-vps-backups': 'Hermes VPS (Live State)',
'hermes-full-backups': 'Hermes VPS (Full Archives)',
'mikrotik-backups': 'MikroTik Router Configs',
'itpropartner-system-configs': 'System Configs (Caddy, systemd, SSH)',
'itpropartner-docker-volumes': 'Docker Volumes (Docuseal, VW, Twenty)',
'itpropartner-backups': 'IT Pro Partner (Legacy)'
```

## Blocker

The IAM user `Hermes-User` lacks `s3:CreateBucket`. The two new buckets (`itpropartner-system-configs`, `itpropartner-docker-volumes`) must be created in the Wasabi Console, then versioning enabled via:

```bash
aws s3api put-bucket-versioning --bucket itpropartner-system-configs --versioning-configuration Status=Enabled --endpoint-url https://s3.us-east-1.wasabisys.com
aws s3api put-bucket-versioning --bucket itpropartner-docker-volumes --versioning-configuration Status=Enabled --endpoint-url https://s3.us-east-1.wasabisys.com
```

Until the buckets exist, the new sync scripts will silently fail with `NoSuchBucket`.