Infrastructure that survives a failure you have already rehearsed
We size servers, storage and virtualization for the workloads you run, then design backup and disaster recovery around the recovery times your business needs, and prove them with restores.
What an infrastructure engagement covers
Local infrastructure still makes sense for many workloads. The work below describes a platform refresh or a backup and recovery overhaul.
A good fit when
- Servers or storage are out of warranty, near capacity or causing performance complaints.
- Backups run, but nobody can say how long a full restore would take.
- A ransomware attack or site outage would stop operations for longer than the business can accept.
- You are consolidating several standalone servers into a virtualization cluster.
What the work covers
- Capacity and performance baseline of current servers, storage and workloads.
- Server, storage and virtualization cluster design, with the capacity to survive a host failure calculated.
- Backup design: schedules, retention, offsite and immutable or offline copies, and separate backup administration.
- Disaster recovery design: recovery time and recovery point objectives per system, and a recovery site or cloud target.
- Installation, migration of virtual machines and data, and decommissioning of old hardware.
- Timed restore tests of representative systems before acceptance.
What you receive
- D1Capacity baseline and sizing rationale
- D2Infrastructure and cluster design
- D3Backup and retention policy
- D4Disaster recovery runbook
- D5Restore test report with measured recovery times
What it depends on
- Agreed recovery objectives for each critical system, signed off by the business owner.
- Rack space, power, cooling and network capacity for new equipment.
- Licensing for the hypervisor, backup software and operating systems.
- A maintenance window for migration and restore testing.
How an infrastructure refresh runs
STEP 01
Baseline
Measure CPU, memory, storage growth and disk activity over a representative period, and list what depends on what.
D1Capacity baseline
STEP 02
Set recovery objectives
Agree how long each system can be down and how much data it can lose; these numbers drive the whole design.
D2Recovery objectives register
STEP 03
Design and specify
Size the cluster for a host failure and choose storage, backup targets and the recovery site.
D3Design and bill of materials
STEP 04
Install and migrate
Rack, configure, and migrate virtual machines and data in scheduled windows with rollback.
D4Migration records
STEP 05
Prove recovery
Restore representative systems against the clock and fix what the test reveals.
D5Restore test report
What we design for
- A host failure, not just a disk failure
- A cluster is only highly available if the remaining hosts can run every critical virtual machine. We calculate that capacity instead of assuming it.
- Backups an attacker cannot delete
- Immutable storage or offline copies, separate backup credentials and alerts on deletion attempts protect recovery points during a ransomware incident.
- The 3-2-1 principle
- At least three copies of important data, on two different types of storage, with one copy kept offsite.
- Recovery in the right order
- Identity services, networking and databases usually have to come back before applications. The runbook records that sequence.
- Hardware lifecycle
- Warranty end dates, firmware support and refresh budgets are tracked, so the next refresh is planned rather than triggered by a failure.
Common questions
How often should we test restores?
Test a representative restore regularly, for example every quarter, and run a fuller disaster recovery exercise at least once a year and after major changes. The right frequency depends on how critical the systems are.
Is cloud backup enough on its own?
It can be one of the copies, but restoring large amounts of data over the internet can take days. Most designs keep a fast local copy for everyday restores and an offsite or cloud copy for disasters.
What is the difference between RTO and RPO?
The recovery time objective (RTO) is how long a system can be unavailable. The recovery point objective (RPO) is how much recent data you can afford to lose, measured in time. Both are business decisions that the technology then has to meet.
Do we need a virtualization cluster?
Not always. A cluster pays off when several workloads must keep running through a host failure or maintenance. For a few servers, good backup and a documented restore process may be the better investment.
Related guides and scenarios
Guides
Not sure your backups would work?
We can review your current backup and recovery setup and test a restore before you invest in new hardware.