A disaster-recovery plan for Hermes Agent

Build a recovery plan that survives a dead laptop: recovery point targets, key custody, offsite retention, and clean-machine restore drills.

Disaster recovery begins with a question: if this computer disappeared now, how much Hermes history could you afford to lose? The answer determines the backup schedule, retention policy, and restore practice.

Define two targets

Your recovery point objective is the maximum acceptable gap between the latest usable backup and the failure. Daily quick snapshots imply up to roughly one day of lost changes. Your recovery time objective is how long it should take to install Hermes, retrieve ciphertext, provide the recovery key locally, import the archive, and verify the agent.

Small agent installations can often target a recovery time measured in minutes, but only if pairing instructions and the recovery key are available without the failed machine.

Map the failure domains

• Application error: a recent local snapshot may be enough.
• Disk or laptop failure: the backup must exist on another system.
• Account compromise: device tokens must be independently revocable and storage objects must remain encrypted.
• Provider breach: leaked ciphertext should remain unreadable without the local private key.
• Operator error: retention and deletion behavior must be explicit, with no silent server-side rotation.

Use a layered schedule

A useful default is a quick backup every day and a full backup once a week. Quick recovery points limit recent data loss; full archives provide broader checkpoints. Keep multiple generations so that corruption or an unnoticed bad change does not replace the only known-good copy.

Quota behavior should be chosen in advance. A “fail and alert” policy preserves every existing backup and makes the capacity problem visible. An explicit client-side rotation policy can prioritize continuity, but it should delete only after the user opted in.

Separate authentication from decryption

A device token answers “may this machine access this account?” The private recovery key answers “can this ciphertext be decrypted?” They should not be the same credential. Revoking a lost device should stop future API access without changing existing ciphertext or pretending the service can rotate a private key it never possessed.

Write the clean-machine runbook

1. Install Hermes Agent on the replacement machine from the official documentation.
2. Install the HermesBackup skill and begin the pairing flow.
3. Approve the short-lived pairing code from the human dashboard.
4. Select a stored recovery point and download it through a short-lived URL.
5. Provide the private recovery key locally.
6. Verify the ciphertext SHA-256, decrypt, and import.
7. Start Hermes and inspect memories, skills, sessions, profiles, configuration, and scheduled jobs.

Run the drill before the emergency

Do not wait for hardware failure to discover that the recovery key was stored only on that hardware. Run a drill after initial setup, after major Hermes upgrades, and periodically thereafter. Use a temporary user account, VM, spare machine, or isolated directory where a failed import cannot overwrite the working installation.

Record the date, selected backup, digest result, import result, and any manual fixes. A backup system becomes trustworthy through repeated recovery evidence, not through an upload-success badge.

← All HermesBackup guides