Skip to main content
Closed beta. Backups are in closed beta and enabled per organisation on request. Contact support to have the feature turned on for your organisation.
A backup vault is an organisation-level record of an S3-compatible bucket you own, plus the credentials to reach it. Everything Ankra backs up is written there; nothing passes through the platform.

​
The three objects

​
Where the data flows

The source cluster’s agent writes backups straight to the bucket. A target cluster - another Ankra cluster, a UAT environment, or a laptop running k3d - reads them back over HTTPS. The platform orchestrates and records; it never holds a byte of your data, which is why a vault must be reachable from the clusters themselves and not just from Ankra.

​
Why backup-first

Copying a database live between two clusters needs a network path between them, a consistent snapshot, and a way to replay changes - and it produces nothing durable. Restoring from a backup needs only the bucket, produces a disaster-recovery copy as a side effect, and is how every database operator already models its own recovery. Ankra therefore recommends a backup policy on every stateful stack, and treats “clone with data” as take a fresh restore point, then restore it on the target.

​
Engines

The engine that captures an asset decides how consistent its restore point is: A volume owned by a database operator is backed up by that operator’s engine, never twice.

​
Two ways a vault comes to exist

An Ankra-provisioned vault (ankra_provisioned) is created from one of the organisation’s provider credentials: the platform creates the bucket on that provider, mints the access keys where the provider’s API allows it (UpCloud, DigitalOcean), reuses the credential’s own keys where they already are S3 keys (Scaleway), or stores the pair the user supplied where the provider issues keys only in its console (Hetzner). A bring-your-own vault (customer_s3) registers a bucket that already exists, on any S3-compatible service, with its keys. Both end up identical from the backup tooling’s point of view: an endpoint, a bucket, a key pair and a repository password in the secret store. Provisioning runs as a platform job: the vault is recorded in provisioning the moment the request is accepted, and moves to ready or error when the job finishes. Every step of the job is written to be repeatable, so running it again reuses what an earlier attempt created rather than creating it twice - but nothing re-runs it on its own today, so a failed run is recovered by deleting the vault and provisioning again.

​
Credentials

Vault credentials live in Ankra’s secret store from the moment you submit them. They are never returned by the API, the dashboard or the CLI, never written into a cluster’s stack definitions, and never included in exports. Inside a cluster, the backup tooling reads them from a Secret the platform manages. Deleting a vault removes Ankra’s record and credentials; the bucket and its objects are untouched unless you explicitly ask for the provider resources to be destroyed with it, which Ankra only offers for a vault it provisioned itself.

​
Permissions

backups.read sees vaults, policies and restore points; backups.operate verifies a vault, takes restore points and runs restores and clones; backups.manage creates and deletes vaults and sets policies. Organisation admins hold all three, and cross-organisation data clones are refused regardless of permissions.

Register a backup vault

Dashboard and CLI walkthrough, with provider-specific endpoint notes.

Stacks

The unit a backup policy protects.