How to Build a Disaster Recovery Runbook for Bare-Metal Infrastructure (Step-by-Step Guide)

Disaster recovery in the cloud has become almost push-button. Spin up a new instance in another AWS region, reattach a snapshot, update DNS, and you're back online in minutes. Bare-metal disaster recovery is a different discipline entirely.

When you own the hardware, there is no abstraction layer to fall back on. A bare-metal disaster recovery runbook has to account for physical provisioning, firmware and driver compatibility, network re-configuration, and manual verification steps that simply don't exist in a virtualized environment.

Skipping any of these steps turns a planned recovery into hours of improvisation during an outage.

This guide walks through building a practical, execution-ready runbook for recovering physical servers after hardware failure, data corruption, or a security incident the kind of document your team can follow line-by-line at 3 a.m. without guessing.

What You'll Learn

Why Bare-Metal Disaster Recovery Is Different (And Harder)

Cloud DR and bare-metal DR solve the same problem restoring service after failure but the mechanics diverge sharply.

• Physical hardware dependencies: A cloud VM can be recreated anywhere in seconds because the underlying hardware is abstracted away. (If you are planning to move away from cloud VMs, see our guide on how to migrate from a VPS to a dedicated server). A physical server recovery, by contrast, depends on actual components being racked, cabled, and powered before any restore can begin.

• MAC addresses and licensing: Some software licenses, network configurations, and even certain OS activation schemes are tied to MAC addresses or hardware IDs. Replacement hardware can trigger licensing conflicts or require manual re-binding.

• Network switch and VLAN configuration: In the cloud, virtual networking is redefined with an API call. On bare metal, someone has to physically or manually reconfigure switch ports, VLAN tagging, and routing to bring a replacement server into the network correctly and without colliding with production.

• Hardware-agnostic restores: If the original server model is no longer available, you may be restoring an image built for one chipset and RAID controller onto entirely different hardware. This is where bare-metal restore (BMR) software has to inject the correct drivers during the recovery process, or the restored OS won't boot.

Because of this complexity, RTO/RPO for bare-metal environments tends to be measured in hours, not minutes which is exactly why a documented, rehearsed runbook matters so much.

Pre-Requisites: What You Need Before Executing the Runbook

A runbook only works if the supporting infrastructure and access already exist before disaster strikes. Confirm the following are in place:

• Recovery site tier: Define whether you're recovering to a cold site (empty facility, hardware provisioned on demand), a warm site (hardware present but not actively running production), or a hot site (fully mirrored, ready for near-instant failover). Each tier carries a different RTO and cost profile.

• Reliable bare-metal backup software: Tools such as Veeam, Acronis, or Datto need to support full image-based backups with driver injection for dissimilar hardware restores, not just file-level backup.

• Comprehensive network documentation: IP address ranges, VLAN configurations, routing tables, and firewall rules must be documented and version-controlled, not stored only in one engineer's memory.

• Emergency access credentials: Out-of-band management credentials (iLO, iDRAC, IPMI), physical access keys or badges, and break-glass admin accounts should be stored in a secure, offline-accessible vault.

If any of these are missing, the runbook below cannot be executed reliably—fix the gaps first.

The Step-by-Step Bare-Metal DR Runbook

This is the operational core of the plan. Each step should be assigned an owner and a target completion time when you adapt this into your own documentation.

Step 1: Incident Declaration and Initial Triage

The first action is confirming that what you're facing qualifies as a disaster under your organization's defined criteria not every outage warrants a full DR invocation.

• Validate the failure through monitoring alerts, hardware diagnostics, or on-site inspection.

• Formally declare the incident according to your incident response policy.

• Notify the DR team and key stakeholders using the pre-defined communication tree (status page, Slack/Teams channel, phone tree for after-hours events).

• Open an incident ticket to log every action taken from this point forward—this becomes your post-incident review record.

Step 2: Hardware Provisioning & Network Isolation

Once the incident is declared, physical recovery begins.

• Rack the replacement server(s) at the designated recovery site.

• Connect power and network cabling per your documented rack diagram.

• Power on and confirm the server responds via out-of-band management (iLO/iDRAC/IPMI).

• Isolate the recovery environment on a dedicated VLAN before doing anything else.

Critical Warning: Restoring a server with its original IP address while still cabled into the production network can cause IP conflicts, ARP table corruption, or routing loops.

Example of assigning a recovery VLAN on a managed switch:

interface GigabitEthernet1/0/12
 switchport mode access
 switchport access vlan 999
 description DR-RECOVERY-ISOLATED

Step 3: Booting the Recovery Environment (ISO/PXE Boot)

With the hardware isolated, boot into the recovery environment using one of the following methods:

• Bootable USB media with your BMR vendor's recovery ISO—reliable for single-server recoveries or sites without PXE infrastructure.

• Out-of-band virtual media via iLO/iDRAC, mounting the recovery ISO remotely without physical media handling.

• PXE boot over the network, pulling the recovery image from a dedicated DR PXE server the fastest option when recovering multiple servers simultaneously.

Example of mounting a recovery ISO remotely via iDRAC racadm:

racadm remoteimage -c -l //10.0.99.5/iso/bmr-recovery.iso
racadm serveraction powercycle

Step 4: The Bare-Metal Restore (BMR) Process

This is where the actual data and OS restoration happens.

• Launch the BMR software's recovery wizard from the booted environment.

• Select the correct backup point (verify the timestamp against your RPO target).

• Restore the OS, volume structure, and RAID configuration to match the original layout—or reconfigure RAID manually if you are migrating to a new storage dedicated server.

• Inject hardware-agnostic drivers: If restoring to dissimilar hardware, inject the network, storage controller, and chipset drivers during the restore process so the OS can boot.

• Reboot into the restored OS and confirm it boots cleanly to a login prompt.

Step 5: Application & Data Verification

A server that boots is not the same as a server that's ready for production traffic.

• Run database consistency checks (e.g., CHECKDB for SQL Server, pg_dump --schema-only validation for PostgreSQL) to confirm no corruption occurred during backup or restore.

• Start application services in the isolated VLAN and test functionality internally—do not expose to production traffic yet.

• Compare restored data against your last known-good state and RPO target to quantify any data loss.

• Sign off verification with whoever owns application-level testing before proceeding to cutover.

Step 6: Network Re-Routing and Go-Live

The final step brings the recovered server back into production.

• Remove the server from the isolated recovery VLAN.

• Assign it the correct production IP address(es).

• Update DNS records if the IP or hostname has changed, and confirm propagation.

• Route live traffic to the recovered server (via load balancer, firewall rule update, or direct cutover).

• Monitor closely for the first 30–60 minutes post-cutover before closing the incident.

Best Practices for Maintaining Your Bare-Metal DR Plan

A runbook that isn't maintained is a liability disguised as a safety net.

• Test regularly, and vary the test type: Run quarterly tabletop exercises (walking through the plan verbally as a team) and at least one full physical restore test annually to confirm the runbook actually works under real conditions.

• Update documentation immediately: Every hardware refresh, VLAN change, or IP re-assignment should trigger an update to the runbook the same day. Stale documentation creates false confidence.

• Maintain air-gapped, offline backups: Keeping at least one backup copy physically or logically isolated from the network protects against ransomware. Learn how to configure immutable backups on a dedicated server for maximum security.

Conclusion

Bare-metal disaster recovery will never be as automated as cloud DR—but it can still be fast, predictable, and stress-free if the runbook is detailed, current, and rehearsed. The steps above cover the full lifecycle: declaring the incident, isolating and provisioning hardware, restoring the system, verifying it, and safely cutting over to production.

Don't wait for an outage to find out your documentation is outdated. Download our free DR Runbook Template PDF to build your own step-by-step plan, or contact our infrastructure team to review your current disaster recovery strategy.