[geoffrey1330]

… decisions)

Consistency-group backup and restore (control plane)

Backs up one generation of a consistency group to S3 as a single all-or-nothing unit and restores it into a new group.

What changes

• GroupBackup record and group manifest. A group backup names the member backups of one generation (group_seq). It commits only when every member backup completed; one terminal member failure fails the whole group. The group manifest in the bucket lists the members, so a bucket can be read without the cluster that wrote it. Member Backup records carry group_backup_id and group_seq, indexed so "members of a group backup" is a point read.
• Create. POST /clusters/{id}/consistency-groups/{cg}/backups and sbctl consistency-group backup-create take a fresh crash-consistent generation, or back up an existing one by sequence, and fan out to the single-volume backup path per member. Members must be homogeneous (one bucket, one encryption disposition).
• Restore. POST /clusters/{id}/group-backups/{id}/restore and sbctl group-backup restore recreate every member from S3 into a new consistency group, all or nothing: chains are validated before any volume exists, members are pinned to one store, and a member failure unwinds what was created. Each member recovers asynchronously as a single-volume restore does.
• Export, import, discover. sbctl group-backup export/import/discover carry a group backup across clusters as a unit, ids preserved, for the DR case.
• Policy. A backup policy attaches to a consistency group (target_type: consistency_group). The group schedule takes one generation per interval, keeps at most one group backup in flight, and prunes whole generations per tier.
• sbctl group-backup list/get/delete, group-backup DTOs, and the OpenAPI surface the operator client is generated from.

Fixes from the live bed

Driven end to end with a three-member group under fsync'd I/O, backup, restore and data checks against real SPDK and S3:

• Restore keeps the source's subsystem sharing. Member backups record max_namespace_per_subsys; the manifest carries it off the record so it survives the volume and an import; restore reapplies it and a group restore creates each member into the new group, so a restored group shares one subsystem like its source instead of one subsystem per member.
• Repeat restores into the same name. A group record outlives its members, so an emptied earlier restore held the name. An empty leftover is reclaimed; a group with live members is still refused. Members whose volume record is gone are dangling, not live, and the restore's fallback join stamps group_id so deletion can detach them.
• Refusals are 409. Group backup-create and group restore answered 422, which FastAPI reserves for its list-shaped validation error; generated clients could not decode the string and hid the message.
• Pruned generations retire their member copies. A copy the next generation chains against is merged into it, the single-volume schedule's own merge, one per chain per cycle; a copy nothing chains against is deleted. The group schedule repeats this every cycle, so leftovers are swept. Before this, every pruned generation's copies stayed in the bucket for good.

[mxsrc]

Could you add a brief description of what the change is trying to achieve and how it is doing so?