Git-Crypt Backup

**Judgement:** Solid, practical backup solution for technically comfortable Clawdbot users who want encrypted GitHub-based backups, but it requires careful setup, key management, and understanding of git-crypt. **What it does well** - Backs up both the Clawdbot workspace (`~/clawd`) and config (`~/.clawdbot`) into separate GitHub repos. - Uses `git-crypt` to encrypt clearly specified sensitive files (SOUL/USER/HEARTBEAT/MEMORY, memory/**, credentials, .env, sessions, etc.). - Provides a straightforward restore path on a new machine via `git clone` + `git-crypt unlock`. - Can be automated via cron or run manually via `scripts/backup.sh`. **Key risks / limitations** - **Key loss risk:** If the exported `git-crypt` keys are lost, encrypted backups become unusable; if keys are stored insecurely, secrets can be compromised. - **Misconfiguration risk:** Users must correctly set up `.gitattributes`; any sensitive file not matched by the provided patterns could be committed in plaintext. - **User skill requirement:** Setup involves GitHub repo creation, `git-crypt` installation, git init/remote configuration, attributes and ignores, and cron configuration—non-trivial for less technical users. - **GitHub dependency:** Availability and security rely on GitHub (and on using private repos as strongly recommended). **Recommended scenarios** - You run Clawdbot regularly, are comfortable with the terminal, git, and SSH keys, and want **automated, encrypted offsite backups**. - You plan to **move Clawdbot between machines** or want a clear disaster recovery path with both workspace and config restorable. - You want **versioned history** of your Clawdbot configuration and workspace while keeping secrets encrypted at rest. **Less ideal if** - You are not comfortable managing git, git-crypt keys, or SSH/GitHub configuration. - You handle extremely sensitive or regulated data and need more advanced security controls (e.g., hardware-backed key management, rotation policies, or dedicated backup infrastructure).