# Hermes Disaster Recovery Plan v2

**Last updated:** July 9, 2026
**Author:** Sho'Nuff + Network Services Team
**Supersedes:** `hermes-standby-deployment` skill's failover logic

---

## Architecture

```
Core (netcup RS 2000 — 152.53.192.33)          app1-bu (Hetzner CPX21 — 5.161.114.8)
┌──────────────────────────────────┐          ┌──────────────────────────────────┐
│  Hermes Agent (active)           │          │  Hermes Gateway (dormant)        │
│  Ollama + llama3.2:3b (fallback) │◄─Tailnet─►│  Ollama + llama3.2:3b (standby)  │
│  state.db (SQLite, ~1.87 GB)     │          │  state.db (synced)               │
│  Telegram gateway (active)       │          │  Telegram gateway (off)          │
│                                  │          │                                  │
│  S3 backup every 15 min ─────────┼─────────►│  S3 sync every 5 min ◄───────────┤
│  Snapshot every 10 min ──────────┼─────────►│                                  │
└──────────────────────────────────┘          └──────────────────────────────────┘
         │                                              │
         ▼                                              ▼
  s3://hermes-vps-backups/live/
  s3://hermes-vps-backups/snapshots/     (standby pulls snapshots on change)
  s3://hermes-vps-backups/ACTIVE_OWNER   (standby writes on takeover only)
```

**Key changes from v1:**
- app1-bu upgraded from CPX11 (2C/2G) to CPX21 (4C/8G, ~$14/mo) to run its own local Ollama
- Both boxes have local Ollama (llama3.2:3b) — health checks never depend on external LLM providers
- Traffic between boxes goes over Tailscale tailnet (not public IPs), avoiding the Hetzner↔netcup routing issue
- No 60-second S3 writes from standby — all cross-box communication uses Tailscale directly
- S3 is backup storage only, not a communication channel

[Full document contents at /root/.hermes/cache/documents/doc_0e07de339e65_hermes-dr-plan-v2.md]