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.
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.
Let Ankra create the bucket
The quickest path: pick one of your organisation’s provider credentials and a region, and Ankra creates the bucket, mints or stores the access keys, verifies the bucket and registers the vault. The vault shows Provisioning until that has finished, then Ready - or Failed with the excerpt of what the provider refused.
Other credential kinds (OVH, AWS, GCP, Azure, Proxmox, Morpheus) cannot provision a bucket yet - register a bucket you own instead, below.
- Dashboard
- CLI
1
Open Backups
Go to your organisation’s Settings and choose Backups, then Add vault and Let Ankra create the bucket.
2
Press the button
The dialog opens ready: a credential Ankra can complete on its own is already selected, the vault is named for you, and the region is that provider’s usual one. It says what it is about to do - “Ankra will create a bucket in europe-1 on UpCloud Object Storage and register it as ‘backups’.” - so pressing Create bucket and vault is the whole flow.
3
Hetzner: paste the Object Storage keys
A Hetzner credential is the one that cannot be a single click, and the picker labels it (needs keys): the form asks for the access key and secret key from the Cloud Console. They are stored in Ankra’s secret store and never shown again.
4
Only if you want to change something
Advanced opens the name, region and bucket for editing. Everything there already has a value; you never have to touch it.
5
Watch it come up
The row shows Provisioning with “Creating the bucket on …”; the page refreshes on its own until it reads Ready. A Failed vault shows what the provider answered - a region your account cannot use, a bucket name someone else holds, a token without the right scope - and can be deleted and re-added once that is fixed.
Ankra records the provider-side handle it created (the UpCloud service, the DigitalOcean key) on the vault, so it can clean them up later if you ask it to - see Deleting a vault.
Bring your own bucket
- Dashboard
- CLI
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 provisioning fails or stalls
A vault Ankra provisions shows Provisioning until the bucket exists and its keys verify. Two things can go wrong, and both are recoverable the same way. It reads Failed with an excerpt. The excerpt is what the provider answered - a region your account cannot use, a bucket name someone else holds, a token without the right scope. There is nothing to re-verify: the run never minted keys, so Verify is not offered and the API refuses it. Delete the vault - tick Also destroy the bucket Ankra created, or pass--destroy-provider-resources, so anything the run got as far as creating goes with it - and provision again with the excerpt’s cause fixed.
It stays on Provisioning. Nothing retries a provisioning run, so a row that has not moved for quarter of an hour is stuck rather than slow, and the dashboard says so. Delete it the same way and try again.
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. verify on a vault that is still provisioning answers that it is still being provisioned rather than recording a failed check.
Deleting a vault
Deleting a vault removes Ankra’s record of it and the access keys it stored. By default the bucket is left exactly as it is - with every restore point in it - along with anything Ankra created for it, so a deletion can never lose data on its own. One exception, and it is deliberate: deleting a vault that is still provisioning always tears down the provider side, whether or not you ask for it. Such a vault has no restore points to lose, but the run may already have created a bucket or a provider resource - and once the record is gone nothing else can find them. For a vault Ankra provisioned, you can ask for the cloud side to be cleaned up in the same step. Ankra then empties and deletes the bucket and removes what it minted for the vault - the UpCloud Managed Object Storage service, the DigitalOcean Spaces key. Scaleway and Hetzner vaults use your own credential’s keys, which are never touched.- Dashboard
- CLI
In the delete dialog, tick Also destroy the bucket Ankra created. The box is unchecked every time the dialog opens, names the bucket and its provider, and the confirm button becomes Delete and destroy bucket. A bring-your-own vault shows no such box.
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?
Backups are in closed beta, switched on per organisation. While the feature is dark:- The Backups settings page renders an explanation instead of the vault list.
ankra backup vaults …exits non-zero withBackups 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
403with 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.
- The right organisation is selected. The CLI acts on the current organisation -
ankra org currentshows which, andankra org switch <name>changes it. - The account is in the organisation that was enabled. Enablement is per organisation, not per user.
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.