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
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.
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.Permissions
backups.read sees vaults, policies and restore points; backups.operate 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.
Related
Register a backup vault
Dashboard and CLI walkthrough, with provider-specific endpoint notes.
Stacks
The unit a backup policy protects.