Disaster Recovery Hardware: What You Would Actually Restore Onto
Disaster recovery plans are frequently written around software and tested never. This covers the hardware side: what you would actually restore onto, and how long it would take.
The two numbers that decide everything
How much data can you afford to lose? That sets backup frequency, which sets how much backup hardware has to absorb and how often.
How long can you afford to be down? That sets what hardware has to be ready and where.
Both are business decisions rather than technical ones, and both are frequently assumed rather than agreed. A plan built on an assumed answer fails at the moment the assumption is tested.
The question most plans skip
What hardware receives the restore?
If the plan says restore to the server, and the reason you are restoring is that the server failed, the plan does not work. Four options, in increasing cost.
Rebuild on replacement hardware ordered after the event. Cheapest, and the recovery time includes procurement and lead time, which our lead times guide covers as no longer being days.
A cold spare — hardware on site, configured, powered off. Recovery is a restore rather than a purchase.
A warm standby — hardware running, data replicated periodically, ready to take over with some work.
Hot standby — running and current, taking over automatically or near-automatically.
Each costs more and recovers faster. The right one depends on the downtime number above, not on what feels sensible.
Restoring to different hardware
The technical obstacle people find during the event.
A bare-metal restore to identical hardware is straightforward. To different hardware it can fail on storage controllers, network adapters and firmware differences that the restored system does not expect.
Three responses. Keep a spare matching the platform, which avoids the problem. Test restoring to different hardware before you need to, which finds the obstacles while they are fixable. Or virtualise, since a virtual machine restored onto any host sees the same virtual hardware — one of the strongest practical arguments for virtualisation. Our backup guide covers testing.
The dependencies that break recovery
Four, and they are found during the event rather than in the plan.
Network and addressing. Systems restored to a different address or network break anything hard-coded to the old one.
Authentication. If the directory service is also down, nobody can log in to the systems being restored, including the people restoring them.
Licensing. Software tied to hardware identifiers may refuse to run on replacement hardware until reissued, which takes time and a working connection to the vendor.
The documentation. A recovery plan stored on the system being recovered is not available. Neither are credentials in a password manager on that system.
Our documentation guide covers keeping records somewhere that survives.
What to hold, and where
Three principles.
Spares for what would take longest to replace. Not the cheapest parts, and not the most likely to fail — the ones whose absence would extend recovery most. Our spares guide covers sizing by consequence.
Not all in one place. Spares in the room that flooded are not spares.
Tested. An untested spare is a hope. Power it on, confirm it works, record its firmware level, and check it again periodically.
Test the plan, not the backups
Backups completing is not recovery working.
A real test restores a system onto the hardware you would actually use, with the people who would actually do it, without the person who wrote the plan. That test finds the gaps: the undocumented step, the credential nobody has, the dependency nobody listed.
Do it at least annually, and after any significant change. Our acceptance testing guide covers a similar discipline at commissioning, and the same principle applies: a process untested is a process unproven.
Frequently asked questions
What hardware do I restore onto after a failure?
That is the question most plans skip. Options are rebuilding on hardware ordered after the event, a cold spare on site, a warm standby with replicated data, or hot standby. Each costs more and recovers faster; the right one depends on your downtime tolerance.
Can I restore a backup to different hardware?
It can fail on storage controllers, network adapters and firmware differences the restored system does not expect. Keep a matching spare, test restoring to different hardware before you need to, or virtualise so the restored system sees the same virtual hardware anywhere.
What breaks recovery that is not the backup?
Addressing that changed, authentication when the directory service is also down, licensing tied to hardware identifiers, and a recovery plan stored on the system being recovered.
Which spares should I hold for recovery?
Whatever would take longest to replace, not the cheapest parts or the most likely to fail. Keep them somewhere other than the room they would be recovering, and test them rather than assuming.
How do I test a recovery plan properly?
Restore a system onto the hardware you would actually use, with the people who would actually do it, without the person who wrote the plan. That finds the undocumented step, the missing credential and the unlisted dependency.
Does virtualisation help disaster recovery?
Substantially, because a virtual machine restored onto any host sees the same virtual hardware. It removes the hardware-difference obstacle that causes bare-metal restores to fail, and it is one of the strongest practical arguments for virtualising.
Tell us your downtime tolerance and the platforms involved, and we will help you work out what hardware needs to be ready and where.
