Skip to main content
A backup vault is an object-storage bucket your organisation owns that Ankra writes cluster backups to. Vaults are the foundation of Ankra’s backup-first data model: every stack backup policy and every restore point lands in a vault, and cloning a stack with its data restores from one.
Backup vaults are rolling out gradually, per organisation. Until the backups feature is enabled for yours, the Backups page under organisation settings explains that it is not enabled yet, and every ankra backup vaults command (and the underlying API) answers Backups are not enabled for this organisation. See Not enabled yet? below.

​
Why a vault first

Ankra’s answer to “copy this database to another cluster” is the industry one: take a backup, then restore it on the target. That keeps data off the platform entirely - the source cluster writes to the bucket, the target reads from it over HTTPS - and it means a disaster-recovery copy exists as a side effect of every clone. That only works with somewhere to write to, which is what a vault is. Registering one is a one-time, organisation-level step.

​
What a vault records

The access key ID and secret you provide are written to Ankra’s secret store and never returned by the API, the dashboard, or the CLI. Rotating keys means creating a new vault or re-verifying after updating the bucket policy.

​
Register a vault

1

Open Backups

Go to your organisation’s Settings and choose Backups.
2

Add a vault

Click Add vault and pick the provider first: the dialog fills in the endpoint and region shapes that provider uses, sets Path-style addressing to what it expects (off for Amazon S3, on everywhere else), and says where its access keys are issued. Then enter the endpoint, bucket, region (if needed) and the keys.
3

Watch the verification

Ankra immediately checks the credentials against the bucket. A vault that passes shows Ready; one that does not shows Failed with the excerpt of what the bucket answered and a Verify again action - see When verification fails.

​
Provider notes

​
When verification fails

A Failed vault is still registered - nothing has to be redone from scratch - but the keys you gave it are never read back, so they cannot be edited in place. The recovery depends on what the excerpt says: Verify again re-runs the same check the create ran; the row updates in place with the new status and the time it last verified.

​
Manage vaults

get, verify and delete accept a vault name or id, and list / get support -o json|yaml.
Deleting a vault never touches the bucket. It removes Ankra’s record and credentials only. A vault that a backup policy or an in-flight data clone still references cannot be deleted - retire those first.

​
Permissions

Organisation admins hold all three. A member with only backups.read sees the vault list read-only; the page says so and names the permission an admin has to grant for adding, verifying or deleting a vault.

​
Not enabled yet?

The feature is switched on per organisation. While it is dark:
  • The Backups settings page renders an explanation instead of the vault list.
  • ankra backup vaults … exits non-zero with Backups are not enabled for this organisation. followed by what to do about it. A real permission refusal on the same commands keeps its own wording, so the two are never confused.
  • The API answers 403 with that same text on every vault route, browser and token alike - a personal access token cannot reach the lane in an organisation where it is dark.
Two things to check before asking for it to be enabled:
  1. The right organisation is selected. The CLI acts on the current organisation - ankra org current shows which, and ankra org switch <name> changes it.
  2. The account is in the organisation that was enabled. Enablement is per organisation, not per user.
Then ask Ankra to enable the backups feature for the organisation.

​
Next steps

Backup vault concepts

How vaults, policies and restore points fit together.

Clone stacks between clusters

Clone a stack’s configuration today - data follows via restore points.