Sendense Documentation

Clean Room

Part of the AsureDense suite: an on-demand, isolated recovery validation environment for booting multi-VM groups from recovery points into sealed networks.

Documents Home

Concept

Clean Room

Part of the AsureDense suite: an on-demand, isolated recovery validation environment for booting multi-VM groups from recovery points into sealed networks.

ReadyCurrentclean-roomasuredensevalidationisolation

Definition

Clean Room is part of the AsureDense suite. It boots one or more workloads from selected recovery points into sealed, appliance-local networks with no connectivity to the production network, so operators can validate recoverability - including multi-VM application groups - without touching production.

Clean Room runs are operator-initiated: you decide when to test, which members to include, and which recovery point each member boots from.

A Clean Room run

Members boot from disposable copies while the underlying recovery points stay read-only. The run network is sealed by construction: it exists only inside the appliance for the duration of the run and is never connected to production.

A Clean Room runSEALED CLEAN ROOM NETWORKFROM EBARecovery PointsRead-only sourcesDISPOSABLE COPYMember VMBoot order 1 - app serverDISPOSABLE COPYMember VMBoot order 2 - databaseBROWSEROperatorConsole, telemetry, checksDisposable copiesConsole + checks
Boot from recovery points (read-only sources)Operator access (console, power, checks)

Sealed by construction

Run networks exist only inside the appliance and are never connected to the production network. Nothing a workload does in a run can reach production or alter backup data.

Lease-bound teardown

Every run has a lease (120 minutes by default, with a configurable maximum). When it expires, member VMs are stopped, workspaces are removed, and the networks are dismantled automatically.

Clean Room Groups

  • Single or multiple network segments, each with a CIDR, gateway, DHCP on or off, and static IP reservations per member.
  • Members with an alias, network segment, boot order, and required-or-optional status - or imported from a protection pattern.
  • Per-member CPU and RAM sizing, and per-member recovery point selection (full or incremental, local or secondary copy).
  • A lease policy: default run length, a maximum, and whether operators can override it.
  • Optional validation checks executed inside the booted guests.

Run Lifecycle

Clean Room run lifecycle

Before launch

Plan And Reserve

Sendense plans the run and reserves capacity. The plan is admissible, blocked, or degraded.

Degraded plans only

Acknowledge

A degraded plan - missing members or unavailable recovery points - proceeds only after explicit operator acknowledgement.

Operator-driven

Run And Validate

Members boot in order into the sealed segments. Operators use consoles, telemetry, and validation checks.

Automatic

Lease Teardown

At lease expiry or operator stop, member VMs stop, workspaces are removed, and networks are dismantled.

Operating A Run

Per-member operations are Power On, Power Off, Restart, and Open Console (a browser console). Telemetry per member covers host CPU utilization, memory, and block read and write throughput - and, when guest tools are present in the booted workload, guest memory, heartbeat, uptime, and guest-reported IP addresses.

Validation Checks

Validation checks are commands executed inside the booted guests through guest tools, with a configurable timeout, expected exit codes, and blocking or non-blocking behavior. Check outcomes roll up into the run's validation summary.

Checks need guest tools

Checks run through guest tools inside the booted workload. They are operator-defined readiness commands plus operator attestation - not automatic proof of application behavior.

Evidence Timeline

Each run records an evidence timeline per member: plan creation, degraded-plan acknowledgement, boot proof, guest heartbeat, per-check results, and member stop events, plus a run-level validation summary such as validated count and failed checks.

What Clean Room Is Not

  • Not a scheduled validation job - automatic post-backup evidence is covered by recovery validation.
  • Not filesystem inspection - mount evidence belongs to post-backup validation evidence.
  • Not a DR failover - Clean Room never promotes workloads or touches replication targets.
  • Not application acceptance testing - checks are operator-defined readiness commands plus attestation.

Related Docs