Skip to main content

Protection groups

A protection group names servers that recover together at a disaster recovery site, with a boot order and a health check per server. It names one protection policy, and that policy's recovery section is the group's promise: where it recovers, at which rung, how far behind and how fast. Every member must already be protected by a plan under that policy, because those plans' backups are what a recovery restores. In the region that would recover it, an operator registers a recovery of the group from the document its home writes into their shared repository, which binds every member to a project there. Where the policy's transport is rbd-mirror and the service can read Ceph mirroring, it samples the replication of the members' disks and marks the group degraded when it falls behind the policy's rpo_target. A group also records where its workload runs and which disaster recovery run is acting on it.

📄️ Create a protection group

Groups servers that recover together at a disaster recovery site, under the protection policy whose recovery section is their promise. Each member has a boot order and an optional health check that must pass before the next tier boots, and each must already be protected by a plan under that policy. `network_map` says where members land in a recovery; a test lands every member on the isolated network its test policy builds. Where the group recovers to, at which rung, how far behind and how fast are the policy's, never the group's. A new group runs here: its role is `primary`, its custody `active` and its custody epoch 1. With `recovery_of`, an operator instead registers the recovery here of a group another region created, as GET /v1/repositories/{id}/inventory?view=groups lists it. The recovery takes its members, custody epoch and source project from the group's newest document, starts with custody `standby` and state `unprotected`, and binds every member to `target_project_id`, with a standby target when the group is `warm`. A member already bound to that project is left on its binding; one bound anywhere else refuses the registration. Later versions of the document are followed: a member added at home is bound here, and one removed at home leaves the group and keeps its binding.

📄️ Delete a protection group

Stops protecting the servers as a group. The servers themselves are not touched. Only a group with no disaster recovery run acting on it can be deleted. The group's runs and their journals go with it; the record of what those runs created stays until each item marked for teardown has been removed. Deleting a recovery, which only an operator may do, also deletes the recovery bindings it created; bindings it found already in place stay, and so do the backups already adopted and any standby.

📄️ Change a protection group

Renames a group or changes its policy, members or network maps. A new policy, and every member after the change, are checked as on create: the policy must state a recovery section, and every member must be protected by a plan under it. A group with a disaster recovery run acting on it cannot be changed, with one exception: a request that changes only a recovery's `test_every` is accepted while a run holds it, so a schedule can always be changed or stopped. A recovery is changed only by an operator: its name, policy, network maps, recovery profile, test policy, test cadence and accepted gaps. Its members follow its home's document, and its standby target stays as registered. A group created here also takes the accepted gaps and the recovery profile its failback resolves a rebuilt member through, when the member's original is gone; the profile only from an operator.