Concepts

Storage and backups

Block storage in three tiers, with growing, cloning, manual and scheduled backups, cross-zone restores and custom images.

Storages are network block devices on Ankra Storage, the zone's replicated block storage, kept on several storage hosts. Because a server's disks live on the network rather than on its host, a server can move to another host (live or after a failure) without copying data.

Tiers#

Tier	IOPS limit	Bandwidth	Price per GiB-month
`standard`, Ankra Storage (default)	5 000	150 MiB/s	€0.049
`local-nvme`, Local NVMe	50 000	1 000 MiB/s	€0.039
`hdd`, Ankra Storage HDD	600	80 MiB/s	€0.029

standard (Ankra Storage) and hdd (Ankra Storage HDD) are replicated network storage. local-nvme (Local NVMe) is the compute host's own NVMe disks: the fastest tier, kept as a single copy on that host, so a server using it stays on that host.

GET /v1/storage-tiers returns the current list; new storage can use every tier it marks is_offered.

Boot storage and what is included#

Every server has a boot storage, device 0, cloned copy-on-write from its template. The plan includes its storage_gibibytes for the boot storage while it stays attached. Every other GiB (a larger boot storage, extra storages, storages kept after deleting their server) is billed per hour at the tier's price.

Working with storages#

Task	How
Create an empty storage	`POST /v1/storages` with `zone`, `title`, `tier`, `size_gibibytes`
Clone a storage	the same with `source_storage_id` (same zone; the size is at least the source's)
Restore a backup as a new storage	the same with `source_backup_id`, in the backup's zone or another zone
Attach or detach	`POST /v1/storages/{id}/attach` with `server_id`, `POST …/detach`; the server must be stopped
Grow	`POST /v1/storages/{id}/resize` with a larger `size_gibibytes`; an attached storage's server must be stopped, and the guest grows its root file system on the next boot
Delete	`DELETE /v1/storages/{id}` once detached; its backups are kept

Storages only grow; shrinking is not supported. A server's only storage cannot be detached.

Backups#

A backup is an independent, sparse copy of a storage in the zone's backup pool, so it survives deleting the storage. Backups are crash-consistent and can be taken while the server runs.

Manual: POST /v1/storages/{id}/backups (or ankra-cloud storages backup <id>).
Scheduled: set a backup_rule on the storage, for example { "interval": "daily", "time": "0300", "retention_days": 7 }. interval is daily or a weekday (mon … sun), time is HHMM in UTC and retention_days is 1 to 1095. Scheduled backups expire and are deleted automatically; a backup due while its storage is busy is retried five minutes later.

Restore in place with POST /v1/backups/{id}/restore, which replaces the storage's content (its server must be stopped), or restore as a new storage with source_backup_id. Backups cost €0.012 per GiB-month.

Zones that keep a single copy#

Some zones keep one copy of every volume on one host (storage_durability: single_copy in GET /v1/zones/{zone}/capabilities). The console says so before you create anything there: Single copy on one host. Backed up daily off-site.

Default backups. While the zone's capabilities report a default_backup, every new server boot disk and every new storage without a backup_rule of its own is backed up daily to the region's backup vault and kept 7 days. The backups are billed like any other backup. Set your own backup_rule to choose the time and the retention.
Opting out needs an explicit acknowledgement: "acknowledge_single_copy_without_backup": true on POST /v1/servers or POST /v1/storages (--acknowledge-single-copy-without-backup in the CLI). The volume is then a single copy with no backup: if its host is lost, the data is lost. Removing the backup rule of an existing storage in such a zone ("backup_rule": null) needs the same acknowledgement.
What a host loss means is in the capabilities too: recovery is restart (restarted on another host from replicated storage), restore (not restarted; you restore its volumes from the latest off-site backup) or none; offsite_backups says whether backups leave the zone, and gateway_redundancy, uplink_redundancy and object_storage_durability describe the zone's networking and object storage the same way.

Cross-zone restores#

A backup can be restored into another zone. The data streams directly between the two zones' storage hosts over mutually authenticated TLS with a one-time ticket, into a temporary volume that is renamed into place, so a retry never leaves half a volume. The same mechanism copies custom images between zones.

Custom images#

Turn a stopped server's storage into a template with POST /v1/storages/{id}/templatize. Custom images appear in GET /v1/templates with is_custom: true and deploy in their zone; copy one to another zone with POST /v1/custom-images/{id}/copy. Deleting an image does not affect servers deployed from it.

Rebuilding a server#

POST /v1/servers/{id}/rebuild erases the boot storage and clones it again from a template, keeping every other storage. The server gets a new instance identifier, so cloud-init runs again, with new SSH keys and user data if you pass them.

Limits#

A new account may hold 200 GiB of storage, boot storages included; ask support to raise it.