# 001 — Why backing up an agent is so hard

**Status:** Idea
**Tags:** Technical, Backups, DevOps

## Research notes

### Real filesystem changes after one week of work on a Linux agent

```
504.6M  ./usr
 43.3M  ./var
448.9M  ./root
 54.0K  ./etc
996.8M  .
```

Most users only back up the home directory (`/root` = 448.9M). But over half the changes live outside it — `/usr` (504.6M) and `/var` (43.3M) contain installed packages, pip/npm global installs, database files, logs, and system configs. A naive home-dir-only backup misses 55% of what changed.

At restore time, you get your config back but the agent won't run — missing dependencies, missing system packages, missing database files.

### What this means for the post

- Agent environments are not just config files — they're full Linux systems with packages, services, and state scattered everywhere
- "Backup your home directory" is dangerously incomplete advice for AI agents
- Derez.ai's full-disk snapshot approach is the right solution
- This is a strong selling point: the agent works after restore, not just the config

### Next data points

Oliver will do two more memory analysis snapshots after running the speed-run setups (Odoo + Cold Email). Those will show how much additional state those integrations add.

### Outline

1. The sprawl problem — why agents are harder to back up than a standard server  
   *Include the filesystem analysis table*
2. What a real agent backup needs to capture
3. How Borg/deduplicated snapshots solve it
4. How Derez.ai does it automatically (one-click restore)
5. Best practices for users
6. Better save than sorry — the selling point

### References

- Borg backup docs
- Hermes Agent directory structure (~/.hermes/)
- Filesystem analysis: `du -sch /usr /var /root /etc` after one week