Hermes Agent backups fail in a boring way first. They hang on files that were never meant to be copied while live.
The usual culprit is the browser profile. Chrome, Chromium, and automation profiles keep lock files, sockets, cache databases, and session stores open while the browser is running. A naive backup job treats those files like normal workspace files. Then it stalls, retries forever, or creates a snapshot that looks complete until the restore drill proves otherwise.
For Keepmyclaw, this matters because the supported target is narrow on purpose: OpenClaw and Hermes workspaces. The product is not a generic browser backup tool. It protects the agent runtime around the browser: workspace files, memory, skills, scheduled jobs, configs, scripts, and credentials after client-side encryption. Browser profile handling is part of that because Hermes often uses browser automation. It should not let a live profile freeze the whole backup.
The operator thesis is simple. Do not chase perfect byte-for-byte browser preservation. Back up the agent state that lets you rebuild the machine and resume work. Treat browser profile files as volatile unless you have a clean export path and a restore drill that proves they matter.
Why live browser profiles break backup jobs
A Hermes workspace is mostly normal files. Memory documents, skills, cron prompts, scripts, config files, and ledgers can be snapshotted cleanly if the backup tool respects write timing.
A live browser profile is different. It can include SQLite databases with active write-ahead logs, lock files, temporary sockets, cache shards, extension state, downloaded blobs, and crash recovery data. Some of it changes every few milliseconds. Some of it is only meaningful while the original browser process owns it.
That creates two failure modes.
The first is a hard hang. The backup process tries to read a file that is locked, changing, too large, or stuck behind filesystem behavior the tool did not expect.
The second is worse. The backup finishes, but the copied profile is internally inconsistent. Cookies are out of sync with session storage. IndexedDB is missing a write-ahead log. A lock file gets restored on a clean machine and makes the new browser think an old process still owns the profile. Lovely little landmine.
What to include in a Hermes backup
Start with the state Hermes actually needs to recover.
A sane backup set includes the Hermes home directory, memory files, skills, cron job definitions, configured scripts, local ledgers, product workspace files, agent config, environment references, and credentials only after client-side encryption. If you keep project-specific state outside the Hermes directory, include those paths too.
For browser automation, include only the parts that are useful after restore. That usually means automation scripts, browser launch config, extension installation notes if extensions matter, and any exported cookies or session material you explicitly chose to protect. Do not assume the whole browser profile belongs in the critical path.
Use concrete parameters instead of vibes:
- RPO: 15 minutes for active paid work, 1 hour for normal agent operation.
- RTO: 30 minutes for a clean-machine restore of Hermes basics.
- Retention: 24 hourly snapshots, 14 daily snapshots, 8 weekly snapshots.
- Snapshot timeout: 120 seconds for cron-safe runs, 10 minutes for manual full backups.
- File size skip threshold: 500 MB unless the path is explicitly allowlisted.
- Live profile exclusion: cache, lock, socket, temp, crash, and GPU cache paths excluded by default.
- Credential rule: encrypt before upload. Never store raw tokens in snapshot metadata.
- Restore drill cadence: weekly for active setups, monthly for low-change personal setups.
- Verification cadence: hash manifest on every snapshot, test restore on a separate machine or container at least monthly.
- Alert threshold: two consecutive failed backups or one restore verification failure.
Those numbers are starting points. Change them if your agent does more expensive work. Just write them down. Future you is not a forensic analyst. Future you is tired and annoyed.
Four failures to design around
The backup hangs on a locked Chrome profile
The job starts during an active browser session. It reaches a profile lock, SQLite journal, or cache file and stops making progress. Cron kills it after the timeout. The saved output may look like an auth error or a generic script failure because the process died before it reached the real logging.
Mitigation: exclude volatile browser profile paths by default. Add a per-path read timeout. Verify progress by logging the current path class, not full sensitive paths. If the browser profile is important, close the browser cleanly before a manual full snapshot or use an explicit export step.
The snapshot restores a broken browser session
The backup completes while the browser is writing session state. On restore, the browser opens with corrupted cookies, stale locks, or missing IndexedDB records. The agent cannot resume the website workflow it was using.
Mitigation: do not make browser session continuity your only recovery plan. Store the automation instructions, target URLs, job state, and agent memory separately. If a session export is needed, create it through a controlled script and test it during restore drills.
The backup spends all its time on cache
Browser caches and generated artifacts can dwarf the useful Hermes state. A backup that should protect a few megabytes of memory and cron config spends minutes copying disposable cache files. Then it misses the cron timeout and never uploads the useful snapshot.
Mitigation: cap file sizes, exclude cache directories, and measure snapshot composition. A backup report should show useful state versus skipped volatile state. If 90 percent of the archive is browser cache, the job is doing cosplay as disaster recovery.
The restore passes locally but fails on a clean machine
The snapshot restores on the same machine because hidden dependencies still exist. The agent works only because the original browser, profile, extension files, environment variables, or credentials are still present. Then the laptop dies and the real restore fails.
Mitigation: run clean-machine restore drills. Use a new user account, VM, container, or spare machine. Verify the Hermes command works, skills load, memory appears, cron definitions exist, scripts compile, and encrypted credentials can be restored through the intended path.
The backup protects secrets in the wrong form
A rushed backup grabs raw credential files, browser cookies, or token caches. It solves restore by creating a new breach problem.
Mitigation: treat credentials as a separate class. Encrypt before upload, avoid printing paths that reveal secrets, and store only the minimum metadata needed to verify that something was backed up. A backup system that leaks tokens is just data loss with better branding.
The clean backup pattern
The clean pattern is an allowlist with explicit exclusions.
Allow Hermes state, project workspaces, memory, skills, cron jobs, scripts, config, and encrypted credential material. Exclude browser cache, crash data, sockets, locks, temp files, GPU cache, downloads unless explicitly required, and huge generated blobs unless they are part of the workspace.
Then add verification.
Every snapshot should produce a manifest with file count, total size, skipped path classes, hash coverage, start time, finish time, duration, and encryption status. It should also record the Hermes version, operating system, and restore profile used for the last drill.
Do not append success to your ledger when upload finishes. Append success when restore verification passes or when the run clearly says it was backup-only and not a restore drill. Mixing those two is how teams convince themselves they have recovery while owning a bucket of untested archives.
How Keepmyclaw should handle it
Keepmyclaw should make this boring. That is the job.
For Hermes and OpenClaw workspaces, the backup path should protect the files that recreate the agent's operating context. It should not freeze because Chrome left a lock file in the wrong mood. It should show what was protected, what was skipped, and why the skipped files were safe to ignore.
The restore path matters more than the archive. A usable Hermes restore should answer five questions quickly:
- Can the agent start?
- Did memory survive?
- Did skills survive?
- Did cron jobs and scripts survive?
- Are credentials restored only after encryption and explicit handling?
Browser session continuity is a bonus. Agent continuity is the product.
If you rely on Hermes for real work, run one clean-machine restore before you need it. Back up while the browser is active, then restore somewhere fresh. If the job hangs on profile files, fix the exclusions. If the restore needs hidden state from the old machine, fix the manifest. If the only proof is that a zip file exists, you do not have disaster recovery yet.