Back up and recover#

A local snapshot preserves memory source files so you can recover after a mistake or move them deliberately. It is not a full runtime backup or continuous device sync.

What a snapshot contains#

Restore rebuilds the searchable index from the source by default and restores the active Self pointer. A source-only restore cannot recreate feedback history that was not in the snapshot. Keep recovery keys and configuration separately and securely.

Create and inspect a local snapshot#

Pause agent writes if you need a consistent point for recovery. For a manually quiescent snapshot, quit the desktop app and stop the service before creating it; the CLI can create snapshots directly from local files.

ormah backup create
ormah backup list
ormah backup status

Inspect the reported snapshot name/path and creation time. The default directory is ~/.local/share/ormah/backups/; scheduled local backups default to enabled, every 24 hours, retaining 10 snapshots. No useful scheduled snapshot exists until there are memory nodes and the job has actually succeeded.

Copy the whole snapshot directory, including its manifest, to a separate disk/location for disaster recovery. Keeping it beside the store doesn't protect against loss of that disk. ormah uninstall removes Ormah's data directories, so keep the copy outside them.

Restore a local snapshot#

1. Quit the desktop app and pause agents that could write or restart the service.
2. Stop the service and confirm it is stopped. server status returns a nonzero exit code when stopped; that is expected here.
3. Use the snapshot name from backup list, or its directory path, in the restore command. Read and accept the interactive confirmation only after checking the selected snapshot.

ormah server stop
ormah server status
ormah backup list
ormah backup restore SNAPSHOT_NAME

SNAPSHOT_NAME is a placeholder; replace it with the actual name. Leave index rebuilding enabled. --no-rebuild is an advanced recovery option and is not part of the normal path. --yes skips confirmation for controlled automation; it does not make replacement safer.

Restore requires the server to be stopped. If it fails, retain both the selected snapshot and the reported safety snapshot, keep clients paused, and inspect the error before another attempt. Disk replacement and a subsequent index rebuild are separate stages; a failed rebuild does not mean no files changed.

Check the recovered store#

ormah server start -d
ormah server status

The earlier stop removed autostart; daemon start restores the managed start path. Open the app or local graph, inspect known node IDs/content/scope, and retrieve a known memory. Confirm the active Self identity is the one expected from the snapshot. Do not use a successful command exit alone as proof of useful recovery.

Local snapshot creation, replacement, safety backup and index-rebuild behavior are covered by source contracts and disposable synthetic fixtures in this docs review. No native app or paid cloud recovery was exercised.

Encrypted cloud recovery#

The optional cloud path encrypts snapshots locally and uses account entitlement plus local recovery identities. Upload success and verified restorable status are different checks. The native Protection flow also tracks recovery-kit readiness; browser actions do not have all of the native filesystem capabilities.

Read the pinned Cloud account and backup reference for account, kit, key rotation and cloud restore details that match the reviewed source. This guide does not certify hosted recovery or provide an untested cross-device recipe. Privacy and providers describes encrypted bytes and account metadata at the remote boundary.