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

The sprawl problem — why agents are harder to back up than a standard server
Include the filesystem analysis table
What a real agent backup needs to capture
How Borg/deduplicated snapshots solve it
How Derez.ai does it automatically (one-click restore)
Best practices for users
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

1.8 KiB Raw Blame History