How Recovery Works
Every recovery in Cygna Forest Recovery is planned before anything changes. You describe what to recover and from which restore points, the Manager checks the plan against the estate, a Restore Operator approves it, and only then is it executed, one tracked step at a time. This chapter explains the model, so that you can choose the right recovery and know what it will do before you start one.
Domain and forest recovery is built on Microsoft's Active Directory Forest Recovery Guide: each step of a plan carries out a step of that guide, in its order. For how each step is applied, and where Cygna Forest Recovery differs, see Alignment with Microsoft Guidance.
Plan first
Planning a recovery writes nothing to any machine. It records the plan and evaluates its preflight checks: whether each chosen restore point is usable, whether each target machine can receive it, and whether the plan as a whole is coherent. Each check is either hard, which blocks approval until it is cleared, or advisory, which you read but do not have to clear. Advisory checks tell you what the recovery will cost. A restore can also raise a check that the approver must explicitly accept, for something the Manager could not prove from where it looked.
Approval records that someone has reviewed the plan. In a domain or forest plan, approval first re-checks each candidate machine that a domain controller is restored onto: its firmware and disks, as they are now, against the backup. If one of those checks blocks, approval is refused. Execution starts the plan. Some checks run again at execution, against the live estate: the backup's hash is verified against the vault before any read access is granted, the version is confirmed present where the restore will read it, and the target's boot configuration is rehearsed before it is set for real.
Once a recovery is running, each step reports its progress in the console. Steps that cannot be undone wait for an operator to acknowledge them, and steps only a person can check wait for an operator to attest to them. A domain or forest plan can instead be built to run unattended, in which case the operator who executes it accepts those pauses in advance, in their own name. A step that fails halts the plan until it is retried or the plan is aborted. A plan can email its halts, waits, and final recovery report to addresses you give it. Every decision, gate result, and state change is recorded in the audit trail.
Separation of roles
Recovery permissions are held only by the Restore Operator role:
plan.approve—Draft and approve restores and recovery plans, and discard plans that were never executed.plan.execute—Run a restore or recovery plan, acknowledge its points of no return, attest to operator steps, retry a halted step, set a plan's notification addresses and email its report, and cancel, abandon, or abort.
No other role implies either capability. In particular, the System Admin role, which configures the product and manages operator accounts, cannot run a restore. Nobody can change their own roles, and the break-glass account cannot be changed by another administrator, so moving from account administration to running a restore always takes a second person. For the role definitions, see Managing Operators and Roles.
Scopes
A recovery has one of three scopes. Each is a different procedure, following the Microsoft Active Directory forest recovery guidance.
| Scope | What it does |
|---|---|
| Single-DC recovery | Restores one domain controller in a domain that is otherwise healthy. The directory converges from the healthy domain controllers, except for the subtrees and objects a DC state recovery names, which go back to the restore point on every domain controller. |
| Domain recovery | Restores one domain inside a forest that is still running, and reconciles the rest of the forest with it. |
| Forest recovery | Brings every domain back from backup, forest root first, on isolated targets, then reconnects the recovered forest to production. |
A single-DC recovery is a restore run. A domain or forest recovery is a recovery plan, which contains a restore run for each domain controller it restores. For details, see Recovery Scopes.
Methods
Each domain controller in a recovery is brought back by one of these methods:
- DC state recovery—Windows still starts. Active Directory goes back to the restore point through Directory Services Restore Mode. In a single-DC recovery, the subtrees and objects you name are marked authoritative, so they replicate out to the rest of the domain.
- Full system recovery—The whole server, operating system included, is restored from a full system backup, in place on the same machine, onto a candidate machine, or onto a new virtual machine booted from a recovery ISO built for the run.
- Rebuild—The domain controller is not restored. Its metadata is removed and a fresh domain controller is promoted in its place, with the Windows roles and features its last backup recorded reinstalled first. A domain or forest plan restores exactly one domain controller per domain and rebuilds the others.
In a domain or forest plan you can also exclude a domain controller. An excluded domain controller is neither restored nor rebuilt: its metadata is removed from the directory along with the domain's other domain controllers, and it is not brought back. Keep the machine off the network. For details of each method, see Restore Methods.
The same full system recovery path also runs test restores, which restore a backup onto an isolated virtual machine on an Isolated Recovery Host to prove it, and change nothing in production. See Test Restores.
It works when the directory does not
The Manager, its operator accounts, and its certificate authority do not depend on Active Directory or DNS, and agents reach the Manager by IP address. You can sign in, review restore points, and plan and run a recovery while every domain controller is offline. During a full system recovery, the recovery environment reaches the storage machine at its advertised address, by default an IP address, and needs DNS only if that address is a name; see Recovery Requirements.
The agent that stages a full system recovery writes its machine's time zone, and whether the machine keeps its hardware clock in local time or UTC, into the recovery job. The recovery environment reads the hardware clock through them, so the job's expiry, the Manager's certificate, and the times it reports are judged on the correct time wherever the machine is. The recovery environment never sets the clock, so the restored system starts on the clock as the machine kept it. Its reading of the clock is recorded in the run's transcript.
