Disaster Recovery Plans

Disaster Recovery (DR) plans let you define how to bring your systems back online after a major incident. You organize devices into ordered recovery groups, set overall RTO/RPO targets, and rehearse the plan before you need it.

---

Creating a DR Plan

1. Navigate to the Disaster Recovery section.
2. Click Create Plan.
3. Enter the plan details:
   • Name — descriptive label (e.g., “Primary site failover”)
   • Description — operator notes explaining the plan’s scope and assumptions
   • RPO target — maximum acceptable data loss in minutes
   • RTO target — maximum acceptable recovery time in minutes
4. Click Save.

---

Adding Recovery Groups

Recovery groups define which devices to recover and in what order. Groups execute sequentially — group 1 completes before group 2 starts.

1. Open your DR plan.
2. Click Add Recovery Group.
3. Configure the group:
   • Name — e.g., “Domain Controllers”, “Database Servers”, “Application Tier”
   • Devices — select which devices belong to this group
   • Step type — how to restore each device in the group; see Step Types below
   • Sequence order — execution priority (lower numbers run first)
   • Dependencies — optionally set a group to depend on another group completing first
4. Repeat for each recovery tier.

Step Types

Every recovery group has one step type, which determines how its devices are restored:

Step type	What it does
VM restore from backup	Restores the snapshot as a new Hyper-V virtual machine.
VM instant boot	Boots a VM directly from backup storage while data migrates to the host in the background.
Hyper-V restore	Restores a Hyper-V export/backup back onto a Hyper-V host.
SQL Server restore	Restores a SQL Server backup chain.
Bare-metal recover (boot media)	Boots the device from Breeze recovery media and enters a recovery code.
Bare-metal rebuild (rebuild engine)	Runs the rebuild engine against a rebuild host running the same platform as the snapshot. See Bare-metal rebuild step below.

Steps never store credentials (v0.118.0+)

A step’s restore settings cannot include a recovery token or storage credentials. Breeze resolves the storage destination from the snapshot when the step runs. Saving a step that includes one is rejected. Steps saved on an earlier release that stored one fail when they run; the v0.118.0 upgrade removes those keys, so open each such step and save it again.

Bare-metal rebuild step

The bare-metal rebuild step type behaves differently depending on the execution type:

• Rehearsal — rebuilds each group device’s latest bare-metal restorable snapshot into a VHDX image on a rebuild host, without touching production hardware. Configure:
  • Rebuild host — an online device running the same platform as the group’s snapshots (Linux: qemu-utils installed; Windows: Hyper-V role) that runs the rehearsal rebuilds. A mismatched pairing is refused.
  • Output directory — where the rebuild host writes one VHDX image per device; defaults to a per-OS path on the rebuild host (/var/lib/breeze/rebuild/out on Linux, C:\ProgramData\Breeze\rebuild\out on Windows) when left blank.
  • Rehearsals only write the VHDX — they never create a Hyper-V VM automatically, even on a Windows rebuild host; that automatic VM creation is a Restore as VM feature (see Restore as VM).
• Failover and Failback — boot each group device from Breeze recovery media instead, restoring it in place with its original device identity. The rebuild host and output directory settings are only used for rehearsals.

The Wait timeout (minutes) setting applies to all three execution types. It is how long each device’s recovery may run before the step marks that device failed and cancels its recovery. For a failover or failback, this includes the time before someone boots the recovery media. The default is 1440 (24 hours), which is also the maximum. A whole-machine rebuild can take several hours: in testing, a Windows rebuild of about 133,000 files (20.6 GB) took over 5 hours. Steps saved on an earlier release stored the old default of 240 (4 hours) and keep it. On such a plan, a large rehearsal is cancelled at 4 hours, so open the step and raise the value.

Each device recovers from its own latest snapshot marked Bare-metal restorable; a device with no such snapshot fails the step with a specific “no restorable snapshot” error rather than a generic one. During execution, the per-device recovery status is shown in the execution view, where you can also Reissue code (rotate an unused recovery code) or Cancel recovery for a device that’s in progress.

Rebuild host requirements

	Linux rebuild host	Windows rebuild host
OS	Any Linux with the tools below; same distro family is not required	Windows Server or Windows 10/11 with Hyper-V
Tools	util-linux, sgdisk, dosfstools, e2fsprogs/xfsprogs, grub-efi, efibootmgr, qemu-utils (used to convert a raw image to VHDX)	Built-in bcdboot.exe, dism.exe, format.com; Hyper-V role for automatic VM creation
Target snapshot platform	Must match the rebuild host’s OS — Breeze refuses the pair otherwise	Must match the rebuild host’s OS — Breeze refuses the pair otherwise

Example Recovery Order

Order	Group	Devices	Why
1	Domain Controllers	DC01, DC02	Authentication must be online first
2	Database Servers	SQL01, SQL02	Applications need their data layer
3	Application Servers	APP01–APP04	Now that auth and data are up
4	File Servers	FS01	Lower priority, can wait

Tip

Model your recovery groups after your service dependency chain. If Application Server depends on Database Server, put the database in an earlier group.

---

Execution Types

Type	What happens	When to use
Rehearsal	Validates recovery steps without modifying production systems	Regular DR testing (quarterly recommended)
Failover	Live execution — actually restores systems according to the plan	Real disaster or planned migration
Failback	Returns services to the primary environment after a failover	After the original site is repaired

---

Running a DR Plan

1. Open the plan and click Execute.
2. Select the execution type: Rehearsal, Failover, or Failback.
3. Confirm to start.
4. Recovery groups execute in sequence order. Track progress in the execution detail view.
5. To stop a running execution, click Abort.

If a group can’t start, the execution error names the specific missing prerequisite — for example, no restorable snapshot for a device, or no valid recovery source — instead of a generic error, so you know exactly what to fix before retrying.

Viewing Execution History

Past executions are listed on the plan detail page, showing:

• Execution type (rehearsal/failover/failback)
• Start and end times
• Status (running, completed, failed, aborted)
• Per-group results

---

DR Testing Best Practices

• Rehearse quarterly at minimum. Real disasters are not the time to discover your plan doesn’t work.
• Start with a rehearsal before relying on a plan for production failover.
• Review after each rehearsal — update device assignments, sequence orders, and targets based on what you learned.
• Keep plans current — when you add or decommission servers, update the recovery groups.
• Combine with SLA monitoring — your SLA policies track whether RPO/RTO targets are achievable day-to-day, giving you confidence before a DR event.