Disaster Recovery Hardware: Specifying a DR Site
Disaster recovery hardware is bought once, sits unused, and is discovered to be inadequate at exactly the moment it matters. The failures are consistent and mostly come from decisions made at purchase rather than from the event itself.
Start from the two numbers
Everything follows from recovery objectives, and specifying hardware before setting them is how DR budgets get spent badly.
Recovery point objective — how much data you can afford to lose, measured in time. This determines how frequently data must reach the DR site, which determines the link and the replication approach.
Recovery time objective — how long you can afford to be down. This determines whether DR hardware must be running and current, or can be built when needed.
Set these per system rather than globally. A file share and a transactional database usually have very different tolerances, and treating them identically means overspending on one and underprotecting the other. Our backup guide covers the same principle.
Three levels of readiness
The RTO decides which you need, and the cost difference between them is large.
Cold. Hardware exists but is not configured or running. Recovery means building it — installing, restoring, configuring. Cheapest, measured in days.
Warm. Hardware is running and configured, with data replicated periodically. Recovery means bringing services up and accepting some data loss. Measured in hours.
Hot. Systems are running and synchronised, ready to take over. Most expensive, measured in minutes.
Most organisations need warm for their important systems and cold for the rest. Hot is justified where downtime cost per hour genuinely exceeds the cost of maintaining a duplicate environment.
Where refurbished fits naturally
DR is the clearest case for secondary-market hardware, for three reasons.
The hardware is idle. It is not carrying production load, so current-generation performance frequently is not required.
Matching production matters more than being current. A DR environment that matches production means the same configurations, the same firmware, the same drivers, and a restore that behaves predictably. Buying the same platform — which for an older production platform means refurbished — removes a whole category of surprises.
Budget is limited by definition. DR spending competes with production spending and usually loses. Refurbished frequently makes the difference between having a DR environment and having a plan to build one.
Our TCO guide covers where this reasoning applies and where it does not.
Capacity: match or reduce?
A real decision with a defensible answer either way.
Matching production means full performance during an incident, and it means a restore behaves the same way it did in testing. It costs the most.
Reduced capacity accepts degraded performance during recovery — running critical systems while non-critical ones stay down. Considerably cheaper and adequate for many organisations, provided the degradation is understood and agreed in advance rather than discovered.
What must not be reduced is storage capacity. Data is the same size wherever it sits. A DR environment that cannot hold the data is not a DR environment, and this is a surprisingly common oversight — particularly as production storage grows and DR does not.
Size it backwards from usable capacity, since RAID overhead and unit conversion both reduce it. Our capacity guide covers the arithmetic.
What gets forgotten at the DR site
The production servers get planned. These do not.
Network equipment. Servers with no switch are unreachable. The DR site needs its own switching, and it needs enough of it.
Firewall and internet access. If users connect from outside, the DR site needs a working path, and that path needs to be tested. Our firewall guide covers sizing.
Power protection. A DR site that fails on a power event is not adding much. UPS and shutdown integration apply here too.
Out-of-band access. Frequently a remote site with nobody in it, which is exactly where console access and remote power control earn their cost.
Credentials and documentation. If the runbook and passwords are stored only on production systems, they are unavailable precisely when needed. This is one of the most common DR failures and costs nothing to fix.
Encryption keys. Encrypted backups without keys are unrecoverable. Keys must survive the loss of the systems that created them.
Test it, or you do not have one
The same rule as backup, and DR fails it more often.
A DR environment that has never been failed over to is an assumption. Common discoveries during a first real test: the restore took far longer than the RTO allowed; a dependency existed that nobody documented; the DR hardware was not on the compatibility list for the current OS version; storage had grown beyond DR capacity; or nobody present knew the procedure.
Test on a schedule. Time it against the RTO. Involve the people who would actually be doing it, not only the person who designed it.
And keep DR hardware current with production. A DR environment that has drifted — different firmware, different OS versions, smaller storage — degrades quietly until the drift is what stops the recovery.
Common questions
Does DR hardware need to match production?
Compute capacity can often be reduced if degraded performance during an incident is agreed in advance. Storage capacity cannot — data is the same size wherever it sits, and a DR environment that cannot hold it is not one.
Why is refurbished a good fit for DR?
The hardware is idle rather than carrying production load, matching the production platform matters more than being current, and DR budget competes with production spending. It frequently makes the difference between having a DR environment and planning one.
Cold, warm or hot standby?
Decided by your recovery time objective. Cold means building it, measured in days. Warm means running and replicated, measured in hours. Hot means synchronised and ready, measured in minutes. Most organisations need warm for important systems and cold for the rest.
What is most often forgotten at a DR site?
Network equipment, internet access, power protection, out-of-band access, and — most commonly — runbooks, credentials and encryption keys stored only on production systems, making them unavailable exactly when needed.
What do first real DR tests usually reveal?
That the restore took longer than the RTO allowed, an undocumented dependency existed, storage had grown beyond DR capacity, the hardware was no longer on the compatibility list, or nobody present knew the procedure.
Tell us your recovery objectives and production platform and we will help specify a DR environment that matches it.
