Overview

Recovery Operations

The recovery workflows for restore, browsing, validation, file recovery, item recovery, and DR failover.

ReadyCurrentrecoveryrestoredr

Definition

Recovery operations are the Sendense workflows used to prove, browse, restore, or promote protected workloads after data has been written to EBA or replicated to a recovery target.

They cover everything from recovering a single file to promoting a replicated DR target as production.

Recovery Operation Types

Recovery point selection

Choose the point in time and the location to recover from.

Full VM restore

Recreate a virtual machine from an EBA recovery point.

File-level recovery

Browse a protected disk and recover selected files or folders.

Application item recovery

Search or recover supported application objects without restoring the full VM.

Recovery validation

Collect evidence that recovery points or replication targets are usable.

Test failover

Boot a replicated target for validation without committing it as production.

Live failover

Promote a replicated target as the running production workload.

Rollback

Undo a test failover, or a live failover that has not been committed.

Commit

Finalize a live failover so the promoted DR workload remains production. After commit, rollback is no longer available.

Distinct operations

A restore from EBA, a DR failover, and a rollback are different operations with different safety gates and outcomes.

Component Roles

Protection patterns determine which recovery points exist and how long they remain available. Replication patterns determine which workloads have maintained DR targets and which failover actions are available.

SHA

Owns the recovery workflow, GUI and API experience, job tracking, RBAC, validation evidence, and audit trail.

EBA

Provides the protected recovery point data and metadata used for restore, browse, validation, and retention-aware recovery point selection.

SNA

The site-side recovery and transport appliance, used where a workflow needs local access to a protected or target environment.

Sendense Controllers

The target-side per-VM appliances for controller-backed replication and failover operations.

Planning a Recovery

Before starting a recovery operation, answer six questions:

What needs to come back: a VM, files, application items, or a replicated service?
Which recovery point or replicated target should be used?
Where should the recovered workload or data land?
Which safety choices apply: power on, overwrite, network mapping, MAC address, test network, guest IP handling, commit, or rollback?
What evidence is needed after the operation?
What cleanup, retention, or governance constraints still apply?

Common Safety Gates

Recovery operations can be blocked or shaped by the state of the environment. Common gates include:

The EBA repository is unreachable or unhealthy.
The recovery point's health or dependencies are not ready.
Legal hold, immutability, or retention governance restricts the requested action.
Target credentials or destination inventory are missing.
The SNA or Sendense Controller involved is unreachable.
Another job is active on the same VM, repository, or replication target.
Source metadata needed for boot, firmware, guest OS, network, disk, or placement decisions is incomplete.
The operator lacks permission, or a destructive action still needs confirmation.

Most blocks have a direct fix

Choose a different recovery point, restore repository access, fix credentials, run discovery, wait for the active operation to finish, or select a different target.

Evidence and Audit

Every recovery operation is auditable. Sendense records:

Job progress and step history.
The operator who ran the operation.
The selected source recovery point or replication target.
The selected destination.
Recovery point health and location state.
Validation results and warnings.
Cleanup or rollback outcomes.
Commit status for live failovers.

Important Distinctions

Recovery operations are not backup scheduling — protection patterns control when backups run.
Recovery validation is not application acceptance testing.
File-level recovery is not a full VM restore.
Rollback is not failback. Rollback reverses an uncommitted failover; failback is a later planned move of production back to a primary site.
Commit is final. After commit, the promoted workload is production and the failover rollback path is no longer available.