Standbys

A standby is a copy of a protected resource's disks, kept in a pool and brought up to date after every new backup, so recovering from it takes about as long as a boot. An operator registers one directly, or through a recovery binding that names a standby pool. A project reads its own standbys and can turn a current one into volumes.

📄️ List standbys

The warm copies kept for the project's resources, with the backup each one holds and whether it is current.

📄️ Register a standby

Keeps a warm copy of a protected resource's disks in a pool at a site, brought up to date after every backup. Recovering it then takes as long as a boot, not as long as copying its data. The pool must hold standbys only, because every update overwrites what is in it. Without `site_id` the copy is kept at this site.

📄️ Remove a standby

Stops updating the copy and forgets it. Its disks are left in the pool.

📄️ Show a standby

Any reader of the project the token is scoped to.

📄️ Turn a standby into volumes

Creates volumes in the standby's project from its `applied_snap`, boot disk first, ready to attach or boot from. They hold `applied_point_id` exactly, whatever state the standby is in: a standby that is updating or whose last update failed still promotes to the backup it last finished. No server is created. Each volume is cloned, registered with the block storage service and handed to the project through a delegation the caller's token grants; every volume is cloned in full in the background. Either every disk becomes a volume or none does. The identity service delegates only roles the caller holds in the standby's project itself: an admin role on the system or on another project does not count, so an operator account that promotes standbys needs a role, such as `member`, in every project whose standbys it promotes.