Understand what the copy contains
Your saved records and their version history are ordinary files in a Git repository. Copying that repository preserves tracked history; copying only the Markdown files preserves their current contents. Your team can read those files without Mensara.
The Git backup excludes private key material and external connection credentials. It is not a complete snapshot of every running service. Portal chat conversations and sign-in sessions are kept in the Portal’s own database, outside the Mind’s repository, so this copy does not contain them. Save anything from a conversation that you want to keep as a record in the Mind. Keep the Recovery Kit separately and expect to reconnect outside accounts after a Git-only restore. Connections explains those service grants.
Connect a private backup repository
Use your Mind’s owner account. In the Portal, open Settings → Backup. Create or select the private GitHub repository you control, then supply its owner/repository name. Follow the app-install and browser authorisation steps, granting access only to the intended repository.
Read the actual result. A connection can exist while its first push has failed. Check the backup’s last successful push, not only its connected label. The backup procedure gives the supported agent ceremony and status fields.
You can explicitly decline a backup during setup and return to it later. Declining records that choice; it does not create protection against loss of the server.
Keep the Recovery Kit separately
In Settings, use Recovery kit to download the current kit. Store it in an owner-controlled location away from the Mind and its file backup. Treat it as sensitive material. Do not paste it into a chat, shared record or support message.
If status says the kit is stale, download the current kit and replace the owner’s recovery copy through the secure storage process. A download result proves the kit was generated, not that its storage is safe or that a restore has been rehearsed.
Two separate parts support recovery
A file backup and recovery material have different custody.
Keep the tracked files and their history in an off-box backup. Keep the current Recovery Kit separately under owner control. An authorised operator uses both to restore a replacement environment, verifies history, reconnects external services and checks an intended user’s harmless task. A connected backup alone does not prove that recovery works.
Check freshness and rehearse recovery
Periodically inspect whether a successful backup is recent enough for your business. A stale or missing result deserves attention. An unavailable status is not evidence that a backup succeeded. Choose a review frequency appropriate to how much recent work you could afford to lose.
Arrange a restore check on a separate replacement environment with the authorised operator. Identify the intended repository and backup point, supply the Recovery Kit through a secure owner route, restore tracked files, verify the signed activity history, reconnect required services and test a harmless read as an intended user.
Do not restore over the running Mind as a first experiment. A copied repository or a green status alone does not prove that people, keys, permissions and connected work will function after recovery. Keep the restore result and its date with the owner’s recovery instructions.
Export information or leave
Decide whether you need current files, full history, or a transferable running workspace. Obtain the corresponding owner-authorised copy and open a sample before relying on it. An export of files does not include all credentials, service agreements or billing changes.
Before transferring ownership, agree the recipient, effective date, retained access and secure handling of recovery material. Before cancellation or deletion, inspect account and billing and confirm the retention consequences through the supported account route. Keep the export accessible independently.
If backup setup fails
An organisation may block the GitHub app, a browser code may expire or the repository may be unreachable. Follow the named correction and restart the owner ceremony only when needed. If the connection is present but the first push failed, inspect status and use the offered retry rather than assuming another authorisation fixes storage or repository access.
Keep a bounded error, time and request reference for support. Never include private keys, the Recovery Kit or service tokens in that report.
Related
Practical guides for people and agents