MENSARA.AI · A GOVERNED MIND, IN YOUR ACCOUNT
Sign in
Mensara Create account

Keep control · GUIDE 08

Backup, restore and ownership

Your company knowledge is stored as normal files in an account you control. A second copy protects those files, while recovery keys are kept separately.

SYSTEM MAP · 08 What you need to recover a Mind The file backup and recovery keys are kept separately. Both are needed to rebuild the Mind on a replacement server.
Company files knowledge and change history
Second copy kept away from the main server
Recovery keys stored separately
Replacement server restore and check
Connect services again email, calendar and apps

01

What you own

The files and their change history sit in your account. You can inspect them, copy them or continue using them without Mensara.

For a company Mind, the named Owner controls backups, exports and deletion.

02

Files and recovery keys

A second copy of the files is kept away from the main server. Recovery keys are stored separately, so one stolen copy is not enough to open everything.

Passwords for Gmail, calendars and other connected services are not saved inside the company files.

03

Restore, export or transfer

If the server fails, the files and recovery keys can be used to rebuild the Mind on a new server. Outside services are connected again one by one.

The Owner can also export the files or transfer company ownership to another person.

NEXT GUIDE · 09 Setup and ongoing care Choose one useful job, then improve the Mind as you use it. →
Request a Mind

The founding cohort is small on purpose. Each Mind is brought up with its owner.

MENSARA.AI · BACKUP, RESTORE AND OWNERSHIP · MACHINE SURFACE · TEXT/MARKDOWN

---
title: Backup, restore and ownership
canonical_url: https://app.mensara.ai/how-it-works/backup-restore-ownership
feature: backup-restore-ownership
audience: llm-agent
last_verified: 2026-08-11
availability: available-now
signup_supported: false
interfaces:
  - portal
  - cli
---

# Backup, restore and ownership

Defines owner-controlled Git backup, separate key recovery, fresh-box restore, reconnection boundaries, export, deletion, and team ownership transfer.

## Concept model

- Knowledge backup and secret recovery are separate artifacts.
- Fresh-box restore reconstructs the Mind from owner-controlled material.
- Ownership controls infrastructure, export, transfer, and deletion.

## Capabilities

- Back up plain-file memory and Git history off the primary box.
- Restore onto a clean replacement box with verified recovery material.
- Export knowledge or transfer team ownership explicitly.

## Prerequisites

- Access to the owner-controlled backup remote.
- Separate recovery material and identity verification.
- Authority as Owner for destructive, transfer, or restore operations.

## Authorization

- Only the Owner can approve ownership transfer or final deletion.
- Administrators may operate backup tasks only when delegated.
- A restoring agent must not infer or recreate missing secrets.

## Connection or use flow

1. Verify the backup and select a known commit.
2. Provision a fresh owner-controlled box.
3. Restore files, history, policy, and verified keys.
4. Test read-only access and receipt integrity.
5. Reconnect each external provider explicitly.

## Refusals and recovery

- Missing recovery keys: stop; do not fabricate replacements or claim full recovery.
- Unverified requester: refuse export, restore, transfer, or deletion.
- Corrupt or incomplete backup: preserve evidence and restore from an earlier verified point.

## Ownership and data boundaries

- The owner controls the knowledge repository and backup account.
- Provider credentials and model subscriptions are not part of the Git repository.
- Personal memory is not transferred with company ownership unless explicitly included by its owner.

## Availability and limits

**Available now** Off-box Git backup and fresh-box restore are supported. Keys and external credentials require separate recovery material.
- A repository backup alone cannot restore secrets or provider sessions.
- External systems must be reconnected explicitly after restore.

## Signup and provisioning

`signup_supported: false`

The human Owner approves the infrastructure account and recovery destination during provisioning. An agent may assist but cannot designate itself owner or receive the sole recovery copy.

No autonomous signup or provisioning endpoint is documented because none is offered today. An agent must stop and involve the human owner.

## System diagram

```mermaid
flowchart LR
  R[Knowledge repo] --> B[Owner-controlled off-box backup]
  B --> F[Fresh box]
  K[Separate recovery kit] --> F
  F --> V[Verify files, policy, identities]
  V --> C[Explicitly reconnect providers]
```

## Runnable example

```text
Recovery check:
- verify off-box Git remote and latest commit
- verify recovery kit is accessible to the human Owner
- restore to a clean box
- run read-only health check
- reconnect providers one by one
```

## Related

- [Multiplayer](https://app.mensara.ai/how-it-works/multiplayer)
- [Changes, approvals and receipts](https://app.mensara.ai/how-it-works/changes-approvals-receipts)
- [Setup and ongoing care](https://app.mensara.ai/how-it-works/setup-and-ongoing-care)