The right level of protection depends on the outage a business must withstand. Backup provides a recoverable data state. Local high availability can mitigate a host failure. A second site extends protection beyond the original fault domain, but requires its own capacity, networks and rehearsed failover. None of these approaches replaces business acceptance testing of the application.
The recovery test and the difference between Proxmox HA and backup already have their own articles. Here we make a different decision: which combination of backup, local replacement and geographically separate continuity operations suits a particular service and fault domain? The public platform overview does not replace this application-level view either.
Start with the business process and two time objectives
Our explicitly fictional example is an ERP with an application VM, database and invoice files. If the entire site fails, the business department wants to resume order processing within four hours and lose no more than 15 minutes of consistent business data. These are objectives for RTO and RPO, neither a DAXS commitment nor a measured result. A single host failure could have a shorter objective; an accidentally deleted transaction instead requires an older, unchanged recovery point.
The business impact analysis must therefore assess host failure, site failure and corrupted or deleted data separately. A service is back only when sign-in, a database operation and its associated file attachment work in continuity mode. Power, the site network, DNS, identity, keys and external interfaces are all dependencies. If one is missing, a replacement server that has started still does not provide usable operations.
Three protection levels with different limits
| Protection level | What it can do | What remains unresolved |
|---|---|---|
| A · Backup and restore | Separate backups allow a return to a verified data state; the application is restored once a target system is available. | Replacement capacity, restore duration and business consistency determine the RTO. After site loss, no reliable four-hour commitment is possible without a prepared recovery location. |
| B · Local redundancy plus backup | Multiple hosts with appropriately designed storage, quorum and networking can start a VM on other resources following a host failure. | Shared power, a fire compartment or site access remain a fault domain. Deleted or corrupted data may be replicated; separate backup is still necessary. |
| C · Second site plus backup | Geographically separate, prepared recovery capacity with replicated application data can cover site loss, provided failover and the business process have been rehearsed. | Replication lag, shared identity services, connections, keys and failed failover can cause the 15-minute/four-hour objectives to be missed. Separate backups are required here too. |
Local HA can therefore address a host failure, but does not automatically provide disaster recovery for the whole site. Microsoft explicitly distinguishes redundancy and replication from backup: a replicated error or deletion remains an error. AWS architecture guidance describes backup/restore, pilot light, warm standby and active multi-site models as strategies with increasing effort. These cloud patterns provide a decision framework, not universal RPO/RTO values for the privately operated ERP assumed here.
Equivalent scope: a transparent three- and five-year calculation
Every level compares the same production ERP service and the same separate baseline backup programme. The existing production platform is therefore excluded from every option. The backup runbook and test foundation require 24 person-hours once; annual assumptions are €3,600 for external backup/storage, 12 × 4 person-hours of operations and two restore exercises of 16 person-hours each. The freely assumed fully loaded rate is €80 per person-hour: €1,920 once, and annually 3,600 + (48 + 32) × 80 = €10,000. These are not vendor prices.
Level B adds 60 person-hours once for host/storage/network design and acceptance, then annually €7,800 of illustrative additional local capacity including power and support, 12 × 4 extra operating hours and two HA exercises of eight additional person-hours each. Level C instead adds 96 person-hours once for site, data and failover design, then annually €18,000 for prepared recovery capacity and networking, €3,600 for data transfer, 12 × 8 extra operating hours and two site exercises of 24 additional person-hours each. Exercise hours are totals across the team; the common backup baseline is counted only once per option.
| Level | One-off | Annual | 3 years | 5 years |
|---|---|---|---|---|
| A · Backup/restore | 24 × 80 = €1,920 | €10,000 baseline | €31,920 | €51,920 |
| B · Local redundancy | 1,920 + 60 × 80 = €6,720 | 10,000 + 7,800 + 3,840 + 1,280 = €22,920 | €75,480 | €121,320 |
| C · Second site | 1,920 + 96 × 80 = €9,600 | 10,000 + 18,000 + 3,600 + 7,680 + 3,840 = €43,120 | €138,960 | €225,200 |
Sensitivity: If prepared second-site capacity costs €500 more per month than assumed, level C increases by €6,000 per year: to €156,960 over three years or €255,200 over five. Before procurement, add spare parts, taxes, actual connectivity and site quotes, licensing rights, operations beyond the assumed hours and the cost of an actual outage. No option promises savings or guaranteed recovery.
Make the decision through testing
For the assumed four-hour/15-minute objectives following a site failure , A and B cannot suffice alone unless another usable location with data, identity and network access is ready. C is only a candidate: the team must measure replication state, database/file consistency, access, the failover decision, capacity under load and the return path in a real test window. If the business accepts longer continuity operations with manual order intake, a less costly approach may suffice. This must be explicitly agreed, documented and rehearsed.
DAXS can document the service and its dependencies, define the smallest usable business continuity operation and compare the three options using actual quotes and restore/failover results. Contact DAXS.
Sources: Microsoft Learn: redundancy, replication and backup · AWS Well-Architected: disaster recovery strategies · Proxmox VE: HA and backup features.
