Who this is for
If you can't state how much data you can lose and how long recovery takes, for each application, start here.
You probably need this if…
- Servers are out of warranty with no replacement plan in place.
- Backups exist but have never been tested end to end.
- Ransomware is a board-level concern with no isolated recovery copy.
- A new ERP or database needs guaranteed performance and uptime.
- A DR audit or customer requirement is coming up.
- Storage is running out faster than anyone expected.
Where it applies
Probably not the right fit when…
- A handful of workloads already well served by a small cloud footprint, with no on-premise need.
- Non-critical systems where a short outage genuinely doesn't cost anything.
Technical overview
Resilience is a number: RPO (how much data you can lose) and RTO (how long recovery may take). We start from those targets per application and engineer compute, storage and backup to meet them.
Technologies we work with
Reference architecture
Design principles
- Size compute, memory, storage IOPS and network bandwidth using workload measurements and tested peak demand.
- Design N+1 capacity against the loss of the required failure unit and ensure remaining infrastructure can sustain critical workloads.
- Use independent storage paths, protected management access and documented failure behaviour for critical systems.
- Maintain isolated or immutable backup copies, application-consistent restore points and regular restore tests.
Specification baseline
| Aspect | Specification | Why it matters |
|---|---|---|
| Compute resilience | Maintain sufficient post-failure CPU and memory capacity for critical workloads | Host redundancy is insufficient if remaining hosts cannot run required services. |
| Storage performance | Specify usable capacity, IOPS, latency, throughput, block size and read/write mix | Capacity alone does not establish suitability for a production workload. |
| Data protection | Apply a 3-2-1-1-0 backup approach with an isolated or immutable copy and verified recovery | Independent copies reduce the risk of one incident destroying all recoverable data. |
| Replication | Choose synchronous or asynchronous replication from measured latency, bandwidth and data-loss objectives | Replication mode determines the balance between recovery objectives and distance constraints. |
| Recovery | Document application dependency order, recovery credentials, network changes and service validation | A recoverable dataset alone does not constitute a recovered business service. |
| Operations | Monitor capacity, latency, media health, backup completion and restore-test outcomes | Trend data enables remediation before resource exhaustion or failure. |
Key design decisions
Infrastructure architecture
Integrated compute and storage management and scale-out operations are priorities.
Independent compute and storage scaling, specialised storage features or established SAN operations are important.
Replication mode
Near-zero data loss is required and measured latency, bandwidth and platform support allow remote acknowledgement before write completion.
The recovery design permits non-zero replication lag or greater site separation.
Sizing & calculations
N+1 cluster capacity must satisfy critical workload requirements after the largest specified host or failure-unit loss.
Four hosts with 32 physical CPU cores each provide 128 cores; after one host fails, 96 cores remain before hypervisor overhead and workload reservations.
Usable storage = raw capacity adjusted for protection overhead, metadata, reserved space and operational headroom.
A 100 TB raw pool with a hypothetical 2:1 effective data-reduction ratio may represent 200 TB of logical data only if that ratio is demonstrated for the workload.
Replication bandwidth must cover changed data per second plus protocol overhead, peak bursts and resynchronisation demand.
A workload changing 200 GB over 8 hours generates an average change rate of about 6.94 MB/s before overhead and bursts.
Standards, protocols & references
Handover documentation
- Compute, network and storage architecture diagrams
- Capacity and performance baseline
- Storage mapping and multipath validation
- Backup policies and immutable-copy configuration
- Restore and disaster-recovery exercise results
- Operational monitoring and recovery runbooks
What you get
- RPO / RTO targets backed by tested runbooks, not assumptions
- Ransomware-resilient backups with immutable, offsite copies
- Capacity planned ahead of growth, not reacted to
What we deliver
Server & compute
- Rack and blade, cluster and failover
- Hyperconverged (HCI), virtualisation
- Consolidation, VDI, GPU compute
Enterprise storage
- SAN, NAS and unified storage
- Replication, dedup, compression
Backup & recovery
- VM, database and application backups
- Tape, archival and cloud / DRaaS
Disaster recovery
- Multi-site recovery strategy
- DR drills and failover testing
High availability
- Active-active storage
- Application continuity validation
Datacentre services
- Rack elevation, cabling and power
- Capacity and scalability planning
