核心用法
git-crypt-backup 是一套为 Clawdbot 设计的自动化备份工作流，将工作目录（~/clawd）和配置目录（~/.clawdbot）分别同步至两个独立的 GitHub 私有仓库，并通过 git-crypt 对敏感内容进行透明加密。
典型工作流：
1. 初始化：创建 GitHub 私有仓库 → 本地初始化 git-crypt → 配置 .gitattributes 指定加密规则 → 导出并妥善保管解密密钥
2. 日常备份：执行 scripts/backup.sh 或配置 cron 定时任务
3. 跨设备恢复：克隆仓库 → git-crypt unlock 用密钥解密 → 恢复完整工作环境
加密范围设计合理：
- Workspace：SOUL.md（人格定义）、USER.md（用户画像）、HEARTBEAT.md（状态日志）、MEMORY.md（记忆核心）及
memory/**全目录加密 - Config：clawdbot.json 核心配置、.env 环境变量、credentials/ 凭据、telegram/、identity/、nodes/ 等全量加密
- 保留明文：AGENTS.md、TOOLS.md、settings/** 等非敏感配置便于直接查阅
显著优点
1. 透明加密体验：git-crypt 基于 Git 过滤器机制，加密/解密对日常 Git 操作完全透明，开发者无感知
2. 精准粒度控制：通过 .gitattributes 实现文件级加密策略，敏感与公开内容共存于同一仓库
3. 标准化工具链：git-crypt 为成熟开源方案（AGPL 协议），社区维护超过 10 年，无 vendor lock-in
4. 灾难恢复完备：密钥导出机制明确，支持离线保管（1Password/USB 等），硬件损坏或账户丢失均可恢复
5. 版本化备份：Git 历史完整保留，支持任意时点回滚，优于传统压缩包备份
潜在缺点与局限性
1. 密钥管理风险：导出后的 .key 文件若泄露，所有历史版本敏感内容均暴露；若丢失，数据永久不可恢复（无后门）
2. 元数据泄露：虽然文件内容加密，但文件名、目录结构、提交时间、文件大小仍对 GitHub 可见，可能泄露使用模式
3. GitHub 依赖：依赖私有仓库的访问权限控制，账户被盗或 GitHub 政策变化可能影响数据安全
4. 单点故障：未提及多副本/异地备份策略，GitHub 单方面故障（虽极低概率）会导致服务中断
5. 密钥轮换困难：git-crypt 设计为静态密钥，一旦怀疑密钥泄露，需重新初始化仓库并重新加密全部历史
6. 移动端受限：git-crypt 依赖 GPG/OpenSSL，移动端 Git 客户端几乎不支持，紧急情况下难以手机操作
适合人群
- Clawdbot 重度用户：已积累大量个性化记忆、自定义代理配置，数据重建成本高的用户
- 多设备工作者：需在个人笔记本、工作站、服务器之间同步 Clawdbot 环境的开发者
- 安全意识中等偏上：能理解密钥管理重要性，愿意执行导出-离线保管流程的技术用户
- 非企业级场景：个人项目、小团队使用，不涉及合规审计要求的场景
常规风险
| 风险类型 | 等级 | 说明 |
|---------|------|------|
| 密钥泄露 | **高** | 导出的 `.key` 文件若存储不当（未加密U盘、明文邮件），攻击者可解密全部历史数据 |
| 密钥丢失 | **高** | 无备份密钥则数据永久锁定，建议 2-of-3 Shamir 分割或硬件密钥二次保护 |
| 仓库可见性误配置 | **中** | 若误设为 public，加密文件内容虽不可读，但会吸引针对性攻击分析 |
| git-crypt 漏洞 | **低** | 历史版本曾出现 CBC 模式漏洞（已修复），需关注上游安全通告 |
| 社会工程 | **中** | 攻击者可能伪造 "密钥备份验证" 邮件骗取用户上传密钥 |
缓解建议：密钥使用 GPG 加密后存储于硬件安全模块（YubiKey）或企业密钥管理系统，定期（如每季度）验证恢复流程有效性。