Lifecycle, cloning and disaster recovery
A workspace or clean room is treated as a portable, recoverable unit, not a folder that happens to have data in it. One materialiser handles all of it, and every operation here is something an entity with the right grant provisions rather than an out-of-band script an operator runs.
Eight planes move together
Three bulk planes (storage, data, messaging) go through per-service coordinators. Five metadata planes (directory, catalog, system, compute, sessions) go through a metadata copier.
Around the copy sit a clone planner, executor and step runner, a resource-graph walk, row-copy specifications, database metadata I/O, a workspace freeze during the transition, notebook reference repointing so references follow the move, and a mobility activity ledger recording the whole saga.
In this section
| Page | What it covers |
|---|---|
| Lifecycle operations | The operation set over a workspace's life |
| Cloning | Copy-on-write, deep and live-sync clones, and the gate that can refuse a deep one |
| Workspace mobility | The eight planes, the freeze, and repointing references |
| Migrating a workspace | Moving between organizations, with cohort edges repointed rather than dropped |
| Disaster recovery | Policy, readiness, drills, and the failover and failback paths |
The operations
| Operation | Behaviour |
|---|---|
| Clone | Copy-on-write, deep, or live sync. A full deep clone consults the decision gate and can be refused with a 403, because duplicating all eight planes is a high-consequence act |
| Cross-organization clone | A send-side trigger with a cross-org guard, an identity map, a signed manifest, a plane transport and an audit sink |
| Archive and restore | Archived to a retrievable artifact and restored, with a retention sweep |
| Organization move | A cohort move that mints every workspace's new id up front and repoints cross-workspace edges to their cohort siblings rather than dropping them. Fail-closed: a failed move aborts the sweep and itemizes exactly which workspaces crossed, never a silent partial |
| DR policy | Declared per workspace: where it may recover to |
| DR readiness | Assessed on demand rather than assumed |
| DR follow | A standby continuously following the primary |
| DR drill | Scheduled rehearsal. Recovery you have practised, not assumed |
| DR failover and failback | Both directions, with cell transition, run rehoming and completeness digests |
Residency binds all of it: a failover stays within the pinned level, and a recovery that could only land off-jurisdiction is a refusal rather than a degradation.
Clean-room specifics
Room transfer carries its own context, per-room keys are re-sealed on a move, and cross-organization transfer of a clean room is default-prohibited without recorded N-of-M consent from every collaborator organization. One party cannot unilaterally export another party's data and consent context.
Workspace mobility and disaster recovery are multi-cell. A clean room runs on one cell at a time, so moving one is a cutover between runs rather than a live spread. Cross-cell clone, archive and recovery for rooms are driven operations, each vetting the target fail-closed on differential-privacy budget, output-review posture, egress-on-replication consent and compartment clearance. What is absent is a mid-run re-placement: no path carries an in-flight run to another cell. See disaster recovery.
Related
- The boundary model, the unit being moved.
- Capacity and placement, where it lands.
- Data residency, the boundary a failover may not cross.
- Platform replication, the other plane: how the platform replicates its own state.