Backup and recovery for always-on agents

An always-on agent needs a backup of its changing state, a way to rebuild its runtime, and a tested procedure for reconnecting services. Keeping the process alive does not provide those things. Neither does saving a reusable agent template. Recovery succeeds when the restored agent has the right data and can resume work without repeating actions.

The cloudrun implementation reviewed on September 5, 2026 contains profile templates and runtime installation images. That review did not identify a scheduled customer backup service or a managed full-runtime restore workflow. Those findings do not establish a backup retention policy or a recovery-time guarantee for a running deployment.

What needs to survive a lost agent machine?

Start with an inventory of what the agent changes. Its instructions may live in one file while its conversation history lives in a database, its work products sit in a workspace, and its credentials belong to external services. Copying one directory can miss part of that state.

Use this inventory for each production agent:

Keep the inventory outside the agent machine. Record locations and responsible owners, without putting raw keys into an ordinary operating document. For several client deployments, include it in the inventory described in our agency fleet playbook.

What does cloudrun's profile snapshot preserve?

The reviewed cloudrun profile snapshot endpoint produces a reusable template. It includes instructions, custom skill content, automation names and schedules, and the names of connected integrations and channels. It does not contain the full machine, conversation history, runtime memory, or the credentials needed to reconnect those services.

This makes the template useful for rebuilding an agent's setup. It is insufficient for recovering the complete state of an agent that has been working for several weeks. A channel name can tell you what to reconnect, but it cannot sign in on your behalf.

cloudrun's documented baked image serves another purpose: it prepares the runtime and dependencies before a customer creates an engine. That image predates the customer's later work. Restoring it can recreate the software environment, but it cannot recover documents or memories created afterward. cloudrun engine documentation.

These limitations concern the inspected cloudrun implementation. They do not establish what backups an infrastructure operator may maintain outside the application. Ask for the actual backup scope, retention policy, and restore procedure before treating any such copy as part of your plan.

Which upstream backup tools can help?

Current Hermes documentation describes hermes backup as creating a ZIP archive of configuration, skills, sessions, and data. It excludes the Hermes codebase and uses SQLite's backup API for database copying. hermes import restores a Hermes backup. Check the installed runtime's help before using commands from newer documentation. Hermes CLI reference.

For an operator with authorized shell access, begin by checking the installed interface:

hermes --version
hermes backup --help
hermes import --help

These checks help establish whether the documented workflow exists in your runtime. They do not create a backup. When making the archive, choose a private destination, transfer it to storage outside the runtime, and restrict access to the copy. Backup contents may contain credentials.

OpenClaw has its own backup commands. Its documentation describes archive creation and verification; do not assume a Hermes archive and an OpenClaw archive are interchangeable. Use the procedure for the installed runtime and verify what its archive includes. OpenClaw backup documentation.

Does a provider snapshot replace a backup plan?

Upstash snapshots can capture disk state and agent configuration, including API-key settings. Restoring one creates a new box. Upstash also states that active provider schedules do not transfer to the new box. These are infrastructure capabilities, not proof that cloudrun schedules customer snapshots or exposes a restore workflow. Upstash snapshot documentation.

If you use a provider snapshot as part of recovery, include the surrounding application state in the drill. The new machine may need to be registered with the control plane and receive updated routing. Existing clients may still call the old endpoint. Credentials present in the snapshot may need rotation.

Also distinguish provider schedules from automations stored by the runtime. A file restored onto disk and an external scheduler registration have different recovery requirements. Check both rather than assuming either one represents all scheduled work.

How often should you back up?

Choose the interval from the work you can afford to lose. A daily backup can leave almost a day of changes missing after a failure, even when every scheduled backup succeeds. Failed backup jobs can make the gap larger.

As a planning example, an internal research assistant might tolerate losing several hours of notes. An agent tracking customer requests may require much fresher recovery data. These are example requirements, not cloudrun service guarantees.

Write down two targets: the maximum acceptable amount of lost work, often called the recovery point objective, and the time available to restore service, called the recovery time objective. Measure both during a restore exercise. Choosing a short interval is easy; proving that the resulting copies are usable takes the exercise.

How do you test recovery without duplicating work?

Restore into a separate environment with outward actions disabled. A recovered agent may remember an earlier state of a task while the external system has already received the result. Letting it immediately resume email, messaging, or document writes can create duplicates.

1. Select a dated backup and record its source runtime version.
2. Restore into an environment prepared for testing.
3. Inspect instructions, memory, sessions, and a sample of workspace files.
4. Compare pending tasks with the external systems where results were written.
5. Reconnect test credentials and send output to a controlled destination.
6. Measure the time required and record every manual repair.
7. Enable production connections only after an operator reviews the cutover.

A successful archive verification checks something useful about the backup file. It does not prove that the agent can run, authenticate, or continue the right task. Save the restore record next to the backup inventory so the next operator knows what was tested.

What should you do before deleting a deployment?

Create the final backup while the runtime is accessible, move it outside the deployment, and confirm that the intended recovery process can read it. If you are changing hosts, use the migration checklist to plan the cutover and keep the old runtime available until verification is complete. Record which integrations must be disconnected or transferred. Keep the runtime version and rebuild instructions with the archive.

Do not use cancellation, a paused state, or a provider's ordinary storage durability as your only recovery copy. Until a documented cloudrun backup service and retention policy have been verified for your deployment, maintain an independent copy and an operator-owned restore procedure.

Include recovery in the hosting decision

Use this checklist while comparing hosts, including cloudrun. Confirm which state you need, how you will export it, and who will test a restore before the agent becomes part of a client service. Record that owner and the recovery evidence in the client-agent launch checklist.

Review the cloudrun setup guide alongside that recovery plan. Start a deployment only when the supported runtime and the available recovery process fit the workload.