Recovery Plan Commands
The recovery commands build and drive a recovery plan for a whole forest or, with --domain, for one domain in a forest that stays live. You decide what happens to each domain controller: restore it from a backup, rebuild it (clean up its metadata and promote a new one), or exclude it (clean up its metadata and not bring it back). The Manager builds the ordered steps from the topology. You then approve the plan, supply each domain's administrator credential and the new DSRM password, execute the plan, and answer the decisions a running plan waits on. You can supply credentials at any time before the steps that need them run; a step that needs one it does not have waits for it. A plan built with --unattended does not stop for those decisions, except at trust resets carried out by hand.
A typical forest recovery:
cdr recovery plan corp.example.com --restore dc01.corp.example.com=10/05/2026-02:30 --rebuild dc02.corp.example.com --ntp time.example.com cdr recovery approve 7c41e0a2b9d3 cdr recovery secrets 7c41e0a2b9d3 --domain corp.example.com --admin CORP\Administrator --dsrm cdr recovery execute 7c41e0a2b9d3 cdr recovery show 7c41e0a2b9d3 --wait cdr recovery report 7c41e0a2b9d3
A plan moves through these states: draft, approved, running, then completed or aborted. A running plan that stops on a failed or rejected step is halted until the step is retried with cdr recovery retry or the plan is aborted. Abort is final: a recovery is planned again, not resumed.
Steps are identified by a step ID and a code, both shown by cdr recovery show. For each step waiting on you, cdr recovery show prints the exact command to run next, including the step ID and, for a point of no return, the code to type.
For the procedures, see Recovering a Domain and Recovering a Forest. To restore a single domain controller, use the restore commands in Restore Commands. For how to run cdr and the global options, see Command-Line Reference.
recovery list
Lists the domain and forest recovery plans, a page at a time: plans in progress first, then newest first. For each it shows its forest, scope, status, and steps completed, when it was created (CREATED) and ended (ENDED), and how long it ran from execution to its end, including any time halted (DURATION, with + after a figure that is still growing). When there are more plans than the page shows, the command says how many and how to page.
Requirements: The plan.view capability (every role).
Syntax
cdr recovery list [--limit <N>] [--skip <N>]
-n or --limit sets how many plans to show, from 1 to 200 (default 50). --skip skips that many first, so --skip 50 with the default limit is the second page.
Example
cdr recovery list
recovery candidates
Lists the candidate machines: bare machines with the DC agent enrolled that are not domain controllers, and can receive a full system recovery. The AGENT ID column is what --onto takes, here and in cdr restore plan.
Requirements: The plan.view capability (every role).
Syntax
cdr recovery candidates [options]
Takes the global options only.
Example
cdr recovery candidates
recovery plan
Builds a forest recovery plan, or with --domain a domain recovery plan, from the topology and your choice for each domain controller, and shows its gates and steps. At least one domain controller must be restored.
If the plan has hard gates, clear what they report and plan again. Otherwise, approve the plan, then supply each domain's credential with cdr recovery secrets.
Each domain must restore exactly one domain controller; restoring two in one domain is a hard gate, with or without --breach. Rebuild the others. Some options apply to only one kind of plan: --ntp and --gc to a forest recovery, and --gc-strategy to a domain recovery. Giving one to the other kind is refused rather than ignored.
Requirements: The plan.approve capability (Restore Operator role). For what a recovery needs, see Recovery Requirements.
Syntax
cdr recovery plan <FOREST> --restore <SPEC> [options]
Arguments
| Argument | Description |
|---|---|
<FOREST>
|
Required. The forest to recover, by the DNS name of its root domain. |
Options
| Option | Description |
|---|---|
--restore <SPEC>
|
Required at least once. A domain controller to restore, as <fqdn>=<version>[:mode], where mode is rollback (DC state recovery) or server (full system recovery). Default mode: server. A plan's DC state recovery is non-authoritative and names nothing to roll back; to roll back subtrees or objects across a running domain, use cdr restore plan with --authoritative-subtree or --authoritative-object. Repeat the option for each domain controller. |
--onto <SPEC>
|
Bind a candidate machine to a domain controller, as <fqdn>=<agent-id>. A restore recovers onto it instead of in place; a rebuild renames and promotes it instead of waiting for the domain controller's own machine. Each machine can be bound to only one domain controller. cdr recovery candidates lists the agent IDs. Repeatable. |
--rebuild <FQDN>
|
A domain controller to clean out of the directory and promote again, with its roles and features reinstalled from its last backup's record. Every domain controller of a domain but the one restored. Repeatable. |
--exclude <FQDN>
|
A domain controller to neither restore nor rebuild: its metadata is cleaned out of the directory along with the domain's other domain controllers, and it is not brought back. Keep the machine off the network. Repeatable. |
--breach
|
Plan a recovery from a security breach: all trusts are reset, and the breach-response resets are added. Without it, a forest recovery resets no trust, and each side of a trust keeps the trust password its own restore point holds. A domain recovery resets the domain's trusts either way. |
--reverify
|
Re-hash every backup in full before it is restored, instead of trusting the storage agent's own recent verification. Adds the time a full read takes, for each domain controller. |
--ntp <SERVER>
|
Forest recovery only. An external time source for the forest root domain's PDC emulator. Repeatable. |
--rid-increase <N>
|
How many RIDs to invalidate, to protect the RID pool from reuse. Default: 100000. |
--gc <FQDN>
|
Forest recovery only. The restored root domain controller to make a global catalog again. |
--domain <FQDN>
|
Plan a domain recovery of this one domain instead of a forest recovery. The rest of the forest stays live; only this domain's domain controllers are restored, rebuilt, or excluded. |
--gc-strategy <STRATEGY>
|
Domain recovery only. How the global catalogs in the other domains are reconciled with the recovered domain: lingering-objects (they stay online) or rehost (the partition is removed from them and added back, site by site). Default: lingering-objects. |
--unattended
|
Run without stopping for anyone: every point of no return, attestation, backup checkpoint, and restore preflight confirmation is accepted in the name of whoever executes the plan, and audited. Confirmed at execution with cdr recovery execute --confirm <NAME> --isolated. A failure still halts, a missing credential still waits, and a trust reset carried out by hand—an external trust, or a partner with no DC agent—still stops for a person. Trust resets the agents carry out are accepted. |
--notify <ADDRESS>
|
Email the plan's halts, aborts, and waits for a person, and its recovery report on completion, to this address. Repeatable, or comma-separated. Without it nothing is emailed. Needs plan.execute. |
--dsrm
|
Set the new DSRM administrator password the plan puts on every domain controller it recovers, now. It is prompted for twice, or read from the CYGNADR_RECOVERY_DSRM_PW environment variable, and held by the Manager in memory only. Without it, the DSRM step waits for one (cdr recovery secrets <PLAN> --dsrm). |
Examples
A forest recovery that restores one domain controller from a full system backup and rebuilds another:
cdr recovery plan corp.example.com --restore dc01.corp.example.com=10/05/2026-02:30 --rebuild dc02.corp.example.com --ntp time.example.com
A domain recovery of a child domain, restoring onto a candidate machine:
cdr recovery plan corp.example.com --domain emea.corp.example.com --restore dc1.emea.corp.example.com=10/05/2026-01:15:server --onto dc1.emea.corp.example.com=6d2f9a1c-4b8e-4f7a-9c3d-2e1b0a9f8c7d --rebuild dc2.emea.corp.example.com
An unattended forest recovery that emails the incident team and holds the new DSRM password from the start:
cdr recovery plan corp.example.com --restore dc01.corp.example.com=10/05/2026-02:30 --rebuild dc02.corp.example.com --ntp time.example.com --unattended --notify ad-team@corp.example.com --dsrm
recovery show
Shows a plan in full: its gates, what each domain controller is planned to do, at which step, and from which backup, what each rebuild reinstalls and does not carry, the time source, and every step with its state and the reason for any check that failed. From the reconnect until the last rebuilt domain controller is back, it says which domain controllers each domain is serving on. For each step waiting on you, it prints the command that unblocks it. For a plan that is a draft, approved, running, or halted, it also lists the credentials that steps still to run need: domain credentials held (in memory): <domains>, and, for each domain whose credential the Manager does not hold, domain credential not held: <domain> — cdr recovery secrets <plan> --domain <domain> --admin <DOMAIN\user>. With --wait, it re-reads the plan every 10 seconds until the plan is completed or aborted.
Requirements: The plan.view capability (every role).
Syntax
cdr recovery show <PLAN> [--wait]
| Argument or option | Description |
|---|---|
<PLAN>
|
Required. The plan ID cdr recovery list prints. |
--wait
|
Follow the plan, re-reading it until it reaches a final state. |
Example
cdr recovery show 7c41e0a2b9d3 --wait
recovery secrets
Supplies a domain's administrator credential, the new DSRM password, or both, to a plan. The Manager holds them in memory only, and drops them when the plan ends or the Manager restarts. Run the command once for each domain in the plan, at any time before the steps that need the credential run; a step that needs one the Manager does not hold waits for it. For the forest root domain, give an account that is an Enterprise Admin and a Schema Admin; for other domains, a Domain Admin.
The domain password is read from the CYGNADR_RECOVERY_ADMIN_PW environment variable, or prompted for. You can also give the password that the domain's built-in Administrator account had at the backup point, with --rid500: it is read from the CYGNADR_RECOVERY_RID500_PW environment variable, or prompted for. The variable is read without --rid500 too. The new DSRM password is read from CYGNADR_RECOVERY_DSRM_PW, or prompted for twice. Keep it per your policy: it is never shown again.
Requirements: The plan.execute capability (Restore Operator role).
Syntax
cdr recovery secrets <PLAN> [--domain <FQDN> --admin <USER> [--rid500]] [--dsrm]
| Argument or option | Description |
|---|---|
<PLAN>
|
Required. The plan ID. |
--domain <FQDN>
|
The domain the credential is for. Give it with --admin. |
--admin <USER>
|
A domain administrator, for example CORP\Administrator. For the forest root domain, an Enterprise Admin and Schema Admin. Give it with --domain. |
--rid500
|
Also supply the password the domain's built-in Administrator account (RID 500) had at the backup point. Give it with --domain and --admin. |
--dsrm
|
Supply the new DSRM administrator password the plan sets on every domain controller it recovers. With or without --domain and --admin; give at least one of the two. |
Examples
cdr recovery secrets 7c41e0a2b9d3 --domain corp.example.com --admin CORP\Administrator cdr recovery secrets 7c41e0a2b9d3 --domain corp.example.com --admin CORP\Administrator --rid500 cdr recovery secrets 7c41e0a2b9d3 --dsrm
recovery approve
Approves a plan whose hard gates are clear. The approval is recorded under your name.
Requirements: The plan.approve capability (Restore Operator role).
Syntax
cdr recovery approve <PLAN>
| Argument | Description |
|---|---|
<PLAN>
|
Required. The plan ID. |
Example
cdr recovery approve 7c41e0a2b9d3
recovery execute
Starts an approved plan. Follow it with cdr recovery show --wait. An unattended plan also needs --confirm with its name and --isolated. With them, you accept in your own name every pause the plan would otherwise stop for, and attest now that the restore targets are isolated, because nobody will be asked when the plan reaches that step. Make sure every original domain controller is already off and the network is ready for the reconnect; see Recovering a Forest.
Requirements: The plan.execute capability (Restore Operator role), and an active license: without one the Manager refuses to execute the plan, and the command exits with code 3. See Licensing.
Syntax
cdr recovery execute <PLAN> [--confirm <NAME> --isolated]
| Argument | Description |
|---|---|
<PLAN>
|
Required. The plan ID. |
--confirm <NAME>
|
An unattended plan only. The forest's name (for a domain plan, the domain's), typed to confirm that every pause for a person is accepted in your name. |
--isolated
|
An unattended plan only. Attest now that every restore target is isolated. See Isolating Recovery Targets. |
Examples
cdr recovery execute 7c41e0a2b9d3 cdr recovery execute 7c41e0a2b9d3 --confirm corp.example.com --isolated
recovery ack
Acknowledges a step that is a point of no return, so that it can be issued. A plan stops before each such step—for example, seizing the operations master roles or cleaning up metadata—and waits for you. To acknowledge it, type the step's own code with --confirm. cdr recovery show prints the step ID and code, and the full command, for each step waiting on acknowledgment. Every acknowledgment is audited.
Requirements: The plan.execute capability (Restore Operator role).
Syntax
cdr recovery ack <PLAN> <STEP> --confirm <CODE>
| Argument or option | Description |
|---|---|
<PLAN>
|
Required. The plan ID. |
<STEP>
|
Required. The step ID, as cdr recovery show prints it in the STEP column. |
--confirm <CODE>
|
Required. The step's code, as cdr recovery show prints it in the CODE column, typed to acknowledge the point of no return. |
Example
cdr recovery show 7c41e0a2b9d3 cdr recovery ack 7c41e0a2b9d3 <STEP> --confirm <CODE>
recovery attest
Attests, or rejects, a step that an operator performs or checks outside Cygna Forest Recovery—for example, confirming that the recovered domain controllers are isolated from the network, or the check that the backup predates the damage. Attesting marks the step done. Rejecting it fails the step and halts the plan, and needs a note saying why. A restore step waiting on its restore's preflight cannot be attested: decide it on the restore run instead, with cdr restore approve --accept, or cancel the run.
Requirements: The plan.execute capability (Restore Operator role).
Syntax
cdr recovery attest <PLAN> <STEP> [--reject --note <TEXT>]
| Argument or option | Description |
|---|---|
<PLAN>
|
Required. The plan ID. |
<STEP>
|
Required. The step ID. |
--reject
|
Reject the step instead of attesting it. This fails the step and halts the plan. |
--note <TEXT>
|
A note recorded with the attestation. Required with --reject. |
Examples
cdr recovery attest 7c41e0a2b9d3 <STEP> cdr recovery attest 7c41e0a2b9d3 <STEP> --reject --note "dc01 is still connected to the production network"
recovery retry
Retries the step that halted a plan, once what failed it is fixed—for example, an agent updated or a machine brought back. The step runs again from its checkpoint, without repeating what it already did, and keeps its point-of-no-return acknowledgment. The plan then carries on. cdr recovery show prints the step ID of the failed step.
Requirements: The plan.execute capability (Restore Operator role).
Syntax
cdr recovery retry <PLAN> <STEP>
| Argument | Description |
|---|---|
<PLAN>
|
Required. The plan ID. |
<STEP>
|
Required. The step ID of the failed step. |
Example
cdr recovery retry 7c41e0a2b9d3 FR-09@corp.example.com
recovery override-wait
Shortens a step's wait. By default there is no wait between the first and second reset of the krbtgt account: both run while the directory is isolated, and going live waits for the second. Only a plan created with a gap between the resets waits, and only then is there anything to override. Overriding the wait makes the step run now, and Kerberos tickets issued in the window are invalidated. The reason is required, because it is the audit record of the decision; the recovery report lists it.
Requirements: The plan.execute capability (Restore Operator role).
Syntax
cdr recovery override-wait <PLAN> <STEP> --reason <TEXT>
| Argument or option | Description |
|---|---|
<PLAN>
|
Required. The plan ID. |
<STEP>
|
Required. The step ID of the waiting step. |
--reason <TEXT>
|
Required. Why the wait is being shortened. Recorded in the audit trail. |
Example
cdr recovery override-wait 7c41e0a2b9d3 <STEP> --reason "Business outage; accepted ticket invalidation per incident 4471"
recovery abort
Abandons a plan. This is final: the plan cannot be resumed, and the credentials it held are dropped. To continue the recovery, plan it again. Before it aborts, the command says what aborting now leaves—which points of no return are behind the plan, and which changes stay to finish or undo by hand—and asks you to confirm.
Requirements: The plan.execute capability (Restore Operator role).
Syntax
cdr recovery abort <PLAN> [--reason <TEXT>] [--yes]
| Argument or option | Description |
|---|---|
<PLAN>
|
Required. The plan ID. |
--reason <TEXT>
|
Why the plan is being abandoned. |
--yes
|
Skip the confirmation. Required when standard input is not a terminal. |
Example
cdr recovery abort 7c41e0a2b9d3 --reason "Re-planning with dc03 as the restore source"
recovery attended
Takes an unattended plan back: from now on every pause waits for a person, as on any plan. A plan cannot be made unattended again once it is running.
Requirements: The plan.execute capability (Restore Operator role).
Syntax
cdr recovery attended <PLAN>
Example
cdr recovery attended 7c41e0a2b9d3
recovery notify
Changes who a plan emails: its halts, aborts, and waits for a person, and its recovery report when it completes. The addresses replace the ones the plan had. Emails need the Manager's email settings; see Settings Reference.
Requirements: The plan.execute capability (Restore Operator role).
Syntax
cdr recovery notify <PLAN> (--to <ADDRESS>... | --clear)
| Argument or option | Description |
|---|---|
<PLAN>
|
Required. The plan ID. |
--to <ADDRESS>
|
Where the plan's notifications and report go. Repeatable, or comma-separated. |
--clear
|
Stop emailing this plan's notifications. Give --to or --clear, not both. |
Examples
cdr recovery notify 7c41e0a2b9d3 --to ad-team@corp.example.com cdr recovery notify 7c41e0a2b9d3 --clear
recovery report
Gets the recovery report of a plan that has started: what the plan did, what went wrong on the way, and the manual follow-ups it left. It is built from the plan's records each time, so it describes the plan as it is now. Saved as HTML (the default, in the current folder as cygnadr-recovery-<plan>.html) or as a PDF, or emailed. For what it contains, see After a Recovery.
Requirements: The plan.view capability (every role) to save it; plan.execute (Restore Operator role) to email it. The Manager makes the PDF with its own renderer. Email needs the Manager's email settings; see Settings Reference.
Syntax
cdr recovery report <PLAN> [--html <FILE>] [--pdf <FILE>] [--email [--to <ADDRESS>...]]
| Argument or option | Description |
|---|---|
<PLAN>
|
Required. The plan ID. |
--html <FILE>
|
Save the report as HTML here. The default when nothing else is asked for. |
--pdf <FILE>
|
Save the report as a PDF here, made by the Manager's own PDF renderer. cdr waits for the PDF however short --timeout is. |
--email
|
Email the report, with its PDF attached when the Manager can make one. |
--to <ADDRESS>
|
Who to email it to, with --email. Repeatable. Without it, the plan's notification addresses. |
Examples
cdr recovery report 7c41e0a2b9d3 cdr recovery report 7c41e0a2b9d3 --pdf corp-recovery.pdf cdr recovery report 7c41e0a2b9d3 --email --to ad-team@corp.example.com
