A successful restore depends on the destination environment being ready to receive it. This checklist ensures that target hardware, network configuration, storage capacity, and driver compatibility are verified before restore execution begins.
The Destination Assumption
Teams assume that the recovery destination will be ready when needed. In practice, destination environments often lack required drivers, have insufficient storage capacity, or are missing network configurations that the restored system depends on. These gaps are discovered only during restore, when fixing them is most expensive.
When to Use This Checklist
Run through this checklist before every recovery exercise and before any real recovery operation. The checklist should be completed by the infrastructure team responsible for the destination environment, with sign-off from the recovery lead.
Checklist Categories
The checklist covers five categories of destination readiness. Each category must be verified independently — passing one does not imply passing others.
Priority
What returns first and why. Without a defined restore sequence, teams attempt parallel restorations that fail when upstream dependencies are missing.
CPU architecture matches (x86_64 vs ARM).
Memory capacity meets or exceeds source system.
Disk controller types are compatible or drivers are pre-staged.
Dependencies
Every restored system depends on other systems, credentials, network paths, and storage locations that may not exist in the recovery environment.
Storage controller drivers extracted and available on rescue media.
Network interface drivers for target hardware pre-loaded.
GPU or specialized hardware drivers available if required.
Assumptions
Teams carry silent assumptions about what will be available during recovery. Testing validates or disproves these assumptions before they cause failures.
VLAN tags and subnet assignments match recovery plan.
Firewall rules permit required inbound and outbound traffic.
DNS and DHCP services are accessible from the target network.
Ownership
Recovery requires decisions at every stage. Without pre-assigned ownership, decisions stall or conflict.
Disk capacity exceeds source system with margin for growth.
“Files restored” is not “service operational.” Verification must test at the application level, not just the file level.
Administrative credentials for hypervisor and storage controllers.
Network access to destination environment via VPN or direct connection.
Out-of-band management access (iDRAC, iLO, IPMI) for bare-metal systems.
Checklist Output
A completed and signed-off checklist confirms that the destination environment is ready to receive the restored system. Any unchecked item becomes a pre-recovery action item that must be resolved before restore execution.
Use hardware-independent restore features (such as Macrium ReDeploy) and pre-stage the required drivers on rescue media. Test the restore to dissimilar hardware before an incident to verify that drivers load correctly and the system boots.
Use an isolated test network that mirrors the production VLAN configuration. Verify DNS resolution, firewall rules, and connectivity from the test network before attempting actual restore. Document any differences between test and production network configurations.
Capacity is the minimum requirement, but IOPS and latency are equally critical. A restored database on slow storage may boot but will be functionally unusable. Verify that destination storage performance matches or exceeds the source system performance profile.