← Back to Blog

Why Backing Up an AI Agent Is So Hard — And How Full-Disk Snapshots Fix It

June 12, 2026 Architecture hermes

Ask any DevOps engineer how to back up a server, and they'll say "home directory, config files, databases." Standard playbook. Works for web apps, works for databases, works for most cloud workloads.

Ask them how to back up an AI agent, and suddenly nobody has a good answer. Because an agent isn't a config file with a database attached — it's a full Linux system whose state scatters across /usr, /var, /etc, and /root in ways that standard backup tools never expect.

This post walks through real filesystem data from a live Hermes agent that ran speed-runs over two weeks. The numbers may surprise you.

The Sprawl Problem

After one week of basic agent work, we measured the filesystem changes from a clean Debian 12 install:

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

A home-directory-only backup (/root) captures 448.9 MB — 45% of what changed. Already missing over half the agent's state.

Then we ran the agent through several speed-runs: Hermes Agent setup, competitor profiling, cold email configuration, Odoo integration, mobile.de research scraping. After all setups:

  4.3G  ./usr       ← 8.5× growth
487.0M  ./var       ← 11.2× growth
  2.1G  ./root       ← 4.7× growth
  1.9M  ./etc        ← 35× growth
  6.8G  total        ← 6.8× growth

Now a home-dir-only backup captures 2.1 GB (31%) — meaning 69% of the agent's state lives outside its home directory.

The 69% problem: If you back up only /root and restore, your agent comes back with its config files and skills — but with no Hermes runtime, no Python packages, no Node modules, no HuggingFace models, no system dependencies. It won't even start.

Where Does All That State Live?

Here's the breakdown of what drives an agent's storage footprint and where it scatters:

Location Size What It Is Trigger
/usr/local/lib 2.3 GB Hermes runtime, node_modules, Python 3.11 libs Hermes installation
/root/.npm/_cacache 390 MB npm package cache Node.js tooling
/root/.hermes 412 MB 19 skills, 1 plugin, cron jobs, memories, config All speed-runs
/root/.cache/huggingface 142 MB HuggingFace model weights STT / model downloads
/root/.cache/uv 186 MB UV Python package cache Hermes venv management
/var/cache/apt 379 MB Debian package cache System dependencies
/var/lib/apt 80 MB APT package state System dependencies
/usr/local/bin 28 MB hermes CLI, other executables Hermes installation
/root/.config 475 KB App configurations Misc tools
/etc 1.9 MB System config (hostname, apt sources, etc.) OS configuration

Total blog content created during this period: 5 posts (Odoo, Hermes setup guide, competitor profiling, cold email, mobile.de research) — and those 5 posts alone drove the system past 1 GB.

Why It Gets Worse Over Time

The sprawl isn't static — it compounds. Each new skill adds Python or Node dependencies in /usr/local. Each new cron job writes logs and state. Each new model download caches weights in /root/.cache. Each system package lands in /var.

Look at the trend:

A "backup your home directory" strategy doesn't just miss some data — it misses a growing majority of it. Restoring from a home-dir backup would give you your .hermes skills and config back, but Hermes itself, all its runtime dependencies, system packages, and model weights would be gone. Your agent would boot to a broken environment.

How Full-Disk Snapshots Solve It

The only way to guarantee an agent restores to a working state is to back up its entire filesystem — not just the home directory, and not just config files. Here's how it works:

1. Size isn't a problem — efficient snapshot compression

Our 6.8 GB agent compresses down to roughly 1–2 GB for daily snapshots. Only what changed between snapshots is stored — so a daily backup after the initial snapshot is often just 50–200 MB of deltas.

2. Full-disk means full recovery

When you restore, you get back everything: the Hermes runtime, all Python packages, model weights, cron schedules, system config, apt state, and your agent's custom skills. The agent boots and works immediately — no reinstallation, no rebuilding.

3. Compression reduces storage cost

Our snapshot compression brings the 6.8 GB down to about 4.2 GB on disk. With 7 daily snapshots retaining the full machine state, you're looking at ~6–10 GB total — negligible for any modern VPS provider.

What derez.ai Does Differently

Every derez.ai agent instance comes with automatic full-disk snapshots — not home-directory backups, not config exports, but full filesystem snapshots.

Real talk: Most agent hosting services back up your config and call it a day. They don't tell you that restoring won't work because the runtime is missing. We built full-disk snapshots into derez.ai from day one because "it works after restore" is the only standard that matters.

Better Safe Than Sorry

The 69% problem isn't a theoretical edge case — it's what happens to every agent that runs real workloads. Every skill, every integration, every model download pushes more state outside the home directory.

If your agent hosting service backs up only /home or /root, test this: delete a major runtime dependency (say, /usr/local/lib/python3.11), then restore from their backup. If the agent doesn't work, you're paying for a false sense of security, not actual backup.

At derez.ai, your agent's full disk gets backed up every day. No gaps, no missing runtimes, no surprises on restore.

Try it yourself — first month free

Deploy a Hermes agent with automatic full-disk backups. Use code blog950 for your first month free.

Get Your Agent

derez.ai — Work with your AI agent in 10 minutes. Full-disk backups, SSH access, managed dashboard included.