Create and Restore Snapshots

View as Markdown

NemoClaw snapshots preserve manifest-defined sandbox state before destructive or state-changing operations. They are the preferred backup and restore path.

When to Create a Snapshot

  • Before running nemohermes <name> destroy.
  • Before major NemoClaw version upgrades.
  • Periodically, if you have invested time customizing your agent or paired messaging channels.

Understand Snapshot Contents

Snapshots capture all workspace state directories defined in the agent manifest and store them in ~/.nemoclaw/rebuild-backups/<name>/. Agent manifests can also declare durable top-level state files. Treat snapshot directories as private local data.

Hermes snapshots include SOUL.md, the Web Dashboard profile under .hermes/dashboard-home/, and the SQLite database behind .hermes/state.db. NemoClaw uses SQLite’s online backup API and restores the database through SQLite instead of copying a live raw database file.

The dashboard profile includes MEMORY.md and USER.md. The Hermes database can contain session metadata and message history needed for a faithful restore.

Snapshots preserve sandbox registry metadata that affects rebuild behavior, including custom policy presets applied with policy-add --from-file or policy-add --from-dir. When you restore a snapshot, NemoClaw replays those recorded custom presets with their stored YAML content, so you do not need the original preset files on disk.

The target sandbox’s current agent manifest remains authoritative for state-file restore behavior. NemoClaw rejects the restore when the snapshot’s agent, config directory, state-file path, or state-file strategy conflicts with that manifest.

For managed images, NemoClaw applies the current manifest’s managed config merge rules by default and does not fall back to whole-file replacement. For Deep Agents targets, whole-file config replacement is limited to sandboxes created from a custom Dockerfile.

Create and List Snapshots

$nemohermes my-assistant snapshot create
$nemohermes my-assistant snapshot list

snapshot list prints a table of version, name, timestamp, and path. NemoClaw computes versions (v1, v2, through vN) from timestamp order, so vN is always the newest snapshot.

snapshot create requires shields to be down. Snapshot creation and restore share the per-sandbox transition lock with the shields auto-restore timer.

If a timed shields-down window expires during snapshot work, auto-restore can interrupt the operation and restore lockdown instead of allowing state or policy changes to continue past the deadline. Retry the snapshot in a new shields-down window if the deadline interrupts it.

Tag a snapshot with a human-readable label:

$nemohermes my-assistant snapshot create --name before-upgrade

Restore a Snapshot

Restore the latest snapshot:

$nemohermes my-assistant snapshot restore

Pass a version, name, or timestamp prefix to select a specific snapshot:

$nemohermes my-assistant snapshot restore v3
$nemohermes my-assistant snapshot restore before-upgrade
$nemohermes my-assistant snapshot restore 2026-04-14T

To clone a snapshot into a different sandbox name, pass --to <name>. If the destination sandbox already exists, NemoClaw refuses to overwrite it unless you pass --force:

$nemohermes my-assistant snapshot restore before-upgrade --to my-assistant-clone
$nemohermes my-assistant snapshot restore before-upgrade --to my-assistant-clone --force --yes

For dashboard-enabled agents, NemoClaw allocates the destination sandbox its own dashboard port instead of reusing the source port. If no port is available, restore stops before deleting an existing --force destination.

The force-overwrite path restores and verifies lockdown on a destination with an active shields timer, then revokes that timer before it deletes the destination. It clears the remaining local shields state only after deletion succeeds, before a same-name replacement is created.

Restore Agent Configuration Safely

The nemohermes <name> rebuild command uses the same snapshot mechanism automatically. NemoClaw rejects unsafe symlinks and hard links inside sandbox state during backup creation before they can enter a snapshot.

Credential-bearing Hermes files such as auth.json are intentionally excluded from snapshots. NemoClaw-regenerated Hermes config files, including config.yaml and .env, are also excluded. NemoClaw recreates model, provider, and messaging credentials from host-side onboarding and OpenShell provider state during rebuild.

Back Up Every Registered Sandbox

Run nemohermes backup-all before broad maintenance such as nemohermes update, nemohermes upgrade-sandboxes, or an OpenShell gateway migration.

$nemohermes backup-all

backup-all walks the sandboxes registered on the host, creates a snapshot for each eligible running or temporarily started sandbox, and stores the snapshot bundles under ~/.nemoclaw/rebuild-backups/<name>/. If a registered docker-driver sandbox’s container is stopped, backup-all starts the container for the duration of the backup and returns it to its stopped state afterward. If the container cannot be returned to the stopped state, the backup run fails and reports that the container was left running. If a sandbox is not running and its container cannot be started this way, start the sandbox or its container and rerun nemohermes backup-all.

When a backup fails, NemoClaw identifies the affected state item and reports permission denied, tar read error, or absent after extraction when available. Use nemohermes <name> snapshot list and nemohermes <name> snapshot restore to inspect or restore one sandbox’s bundles later.