For agents and technical readers

Connect a backup and inspect recovery readiness

Use the owner-authorised backup ceremony, inspect freshness and kit state, and hand sensitive recovery material through the protected owner route.

Contents

Authority and sensitive output

The backup lifecycle requires owner recovery capability. backup_status can expose a reduced declined-only result to a non-owner onboarding caller; that does not prove connection state. recovery_kit_download returns live key material and must not be called into an agent conversation, shared log or document. Use the owner’s protected Portal download instead.

Read the full owner state

Call backup_status with {} under owner authority. Inspect connected, declined, last_success_at, stale, remote_kind, recovery_kit_downloaded and recovery_kit_stale when the full shape is available.

Connected is stored configuration. A recent successful push is separate. A downloaded/current kit is separate from secure custody or a successful restoration.

Start the repository ceremony

Have the owner create a private repository they control. After explicit authorisation to connect that target, call backup_connect_start:

{"repository":"<owner>/<private-repository>"}

Replace the placeholder with the verified target. The response supplies the app-install URL, repository-selection instructions, user code, verification URL, expiry and poll interval. The owner performs the GitHub browser steps and selects only the intended repository. Do not place one-use codes or credentials in durable records.

Poll the same attempt

Call backup_connect_poll with {} no faster than the returned interval. Continue only while awaiting authorisation and within the ceremony’s expiry. Treat no_session, a named error, failed or a repository-entry correction as a state to resolve rather than polling forever.

A connection can be stored while the first push failed. Inspect status before restarting. A denied or expired owner authorisation needs its specific remedy; it does not justify broader repository access.

Inspect the result and keep the kit

Read backup_status again and verify a successful push and non-stale result. The owner downloads the current Recovery Kit through Settings → Recovery kit and keeps it separately. Never copy its content into a support report.

An explicit backup_decline {} records the owner’s decision to remain unprotected; do not call it as cleanup or as a way to silence a failed backup. Later successful connection supersedes that choice.

Recovery and export handoff

For recovery, name the repository, backup point, replacement environment and authorised operator. Supply the kit via its secure owner channel. The operator restores tracked history, verifies the signed audit chain against the separately held kit trust key, reconnects services and exercises the intended user’s harmless read.

The owner CLI supports offline brain-gateway --repo <restored-repo> verify --trust-key <kit-verify-key>; placeholders require the actual approved paths/key. That verifies history, not the entire installed system. The kit includes sensitive material beyond the verify key and must remain private.

Exporting current Markdown or cloning Git history does not export connection credentials, cancel billing or recreate the running service. Inspect the requested export and account consequences separately. A restore rehearsal result is required before claiming recovery works.

Related

Back up, recover and export your Mind · Manage your Mensara account and billing · Recover pending, failed or interrupted work

Practical guides for people and agents

Start with one useful job

Join the waitlist

Plain text for AI agents. Same content as the human page.

## For agents

- What Mensara is: it gives a team its own Mind, one shared memory for the team and their AI agents, built by Xanadu Labs LLC.
- Status: signup is not open. A person joins the waitlist at https://app.mensara.ai/#waitlist. Agents cannot create an account or sign up.
- How you can help your person: explain what Mensara does, check whether it fits a job their team repeats, and share the waitlist link.
- Agent references: https://app.mensara.ai/llms.txt lists every page as Markdown and the tool input references for connected agents.

---

# Connect a backup and inspect recovery readiness

Operating procedures · For agents and technical readers · [How it works](https://app.mensara.ai/how-it-works)

Use the owner-authorised backup ceremony, inspect freshness and kit state, and hand sensitive recovery material through the protected owner route.

[Page as Markdown](https://app.mensara.ai/how-it-works/backup-procedure.md)

[Human guide](https://app.mensara.ai/how-it-works/backup-restore-ownership)

## Use the released interface with current authority

Availability: Core0.20.11 / Portal0.3.47 source checked; discover the actual installed client and enabled features.

Who can do this: The connected principal with the permissions named in this procedure

What changes: The procedure explains its actual reads, writes or external effects before action.

Limits: An input accepted by a source schema is not a successful installed-runtime task.; Keep human decisions, client exclusions and pending results explicit.

Verification: Source checked and independently reviewed; scoped runtime receipts are recorded separately.

## Authority and sensitive output

The backup lifecycle requires owner recovery capability. `backup_status` can expose a reduced declined-only result to a non-owner onboarding caller; that does not prove connection state. `recovery_kit_download` returns live key material and must not be called into an agent conversation, shared log or document. Use the owner’s protected Portal download instead.

## Read the full owner state

Call `backup_status` with `{}` under owner authority. Inspect `connected`, `declined`, `last_success_at`, `stale`, `remote_kind`, `recovery_kit_downloaded` and `recovery_kit_stale` when the full shape is available.

Connected is stored configuration. A recent successful push is separate. A downloaded/current kit is separate from secure custody or a successful restoration.

## Start the repository ceremony

Have the owner create a private repository they control. After explicit authorisation to connect that target, call `backup_connect_start`:

```
{"repository":"<owner>/<private-repository>"}
```

Replace the placeholder with the verified target. The response supplies the app-install URL, repository-selection instructions, user code, verification URL, expiry and poll interval. The owner performs the GitHub browser steps and selects only the intended repository. Do not place one-use codes or credentials in durable records.

## Poll the same attempt

Call `backup_connect_poll` with `{}` no faster than the returned `interval`. Continue only while awaiting authorisation and within the ceremony’s expiry. Treat `no_session`, a named error, `failed` or a repository-entry correction as a state to resolve rather than polling forever.

A connection can be stored while the first push failed. Inspect status before restarting. A denied or expired owner authorisation needs its specific remedy; it does not justify broader repository access.

## Inspect the result and keep the kit

Read `backup_status` again and verify a successful push and non-stale result. The owner downloads the current Recovery Kit through **Settings → Recovery kit** and keeps it separately. Never copy its content into a support report.

An explicit `backup_decline {}` records the owner’s decision to remain unprotected; do not call it as cleanup or as a way to silence a failed backup. Later successful connection supersedes that choice.

## Recovery and export handoff

For recovery, name the repository, backup point, replacement environment and authorised operator. Supply the kit via its secure owner channel. The operator restores tracked history, verifies the signed audit chain against the separately held kit trust key, reconnects services and exercises the intended user’s harmless read.

The owner CLI supports offline `brain-gateway --repo <restored-repo> verify --trust-key <kit-verify-key>`; placeholders require the actual approved paths/key. That verifies history, not the entire installed system. The kit includes sensitive material beyond the verify key and must remain private.

Exporting current Markdown or cloning Git history does not export connection credentials, cancel billing or recreate the running service. Inspect the requested export and account consequences separately. A restore rehearsal result is required before claiming recovery works.

## Related

- [Back up, recover and export your Mind](https://app.mensara.ai/how-it-works/backup-restore-ownership)
- [Manage your Mensara account and billing](https://app.mensara.ai/how-it-works/account-and-billing)
- [Recover pending, failed or interrupted work](https://app.mensara.ai/how-it-works/interrupted-work)

[Join the waitlist](https://app.mensara.ai/#waitlist)