Häufig gestellte Fragen
How much downtime per year do 99.9%, 99.99% and 99.999% availability mean?
Availability is usually expressed in the so-called “nines” system, which describes the percentage share of usable time. 99.9 percent corresponds to around 8.8 hours of unplanned downtime per year, 99.99 percent to just under 53 minutes and 99.999 percent (“five nines”) to a good five minutes. Each additional nine reduces the calculated downtime by roughly a factor of ten, but requires disproportionately more infrastructure and effort. These figures refer to unplanned outages, while planned maintenance windows are treated separately depending on the contract.
Is 99.99% availability realistic for an ERP in a mid-sized company?
With cloud and SaaS ERP solutions, high availability classes are usually achievable without extra effort of your own, because the provider operates redundancy and failover across several data centres and guarantees them via an SLA. For operation in your own data centre, by contrast, 99.99 percent requires a redundant cluster setup that comes with significant additional costs. Higher availability classes drive up the effort disproportionately, which is why they belong in the TCO assessment and should be aligned with actual business needs. Before committing to a target, it is advisable to assess which processes can tolerate an outage and for how long.
What is the difference between active-active and active-passive clusters?
In an active-active cluster, all nodes process load simultaneously and share the work; if one fails, the remaining nodes take over its tasks, so that ideally users notice no interruption, although the available total capacity then drops. In an active-passive cluster, operations run on one active node while a standby node stands ready and takes over the services completely in a failover. The active-passive variant is more predictable in terms of performance and often works without special adaptation of the application, whereas active-active generally requires corresponding support from the software. Which variant makes sense depends on the architecture of the ERP system and the requirements for performance and switchover time.
Does high availability replace a backup or a disaster recovery strategy?
No — high availability, backup and disaster recovery pursue different goals and do not replace one another. High availability uses redundancy and failover to ensure operation with minimal interruption and primarily addresses the Recovery Time Objective (RTO), i.e. how quickly a system is running again. A backup, by contrast, protects the data itself and addresses the Recovery Point Objective (RPO), i.e. the maximum tolerable data loss, because faulty or deleted data would be replicated to all redundant systems in an HA cluster. Disaster recovery, in turn, describes the orderly restoration after major damage such as fire or the loss of a site, which is why both concepts remain necessary in addition to high availability.
Who is responsible for high availability — the provider or the company?
Responsibility depends on the chosen operating model. With SaaS and cloud ERP it lies largely with the provider, who operates redundancy, failover and maintenance and guarantees the availability target via an SLA. When running the system in your own data centre (on-premises), the company itself bears the setup, maintenance and testing of the redundancy, while hybrid models split the responsibility accordingly. Regardless of the model, connected components such as network, authentication and interfaces should also be designed for resilience, since the ERP system can otherwise fail indirectly despite its own redundancy.
What happens if a provider fails to meet the promised availability?
The consequences are governed by the service level agreement, which defines the availability target, the measurement method and the sanctions. Service credits are common, often graduated by severity of the breach — for example a growing percentage of the monthly fee the further the actual availability falls below an agreed threshold. However, such credits usually compensate for only part of any economic damage, which is why companies should check whether the arrangement is appropriate to their risk and which exceptions, such as planned maintenance, are excluded. The SLA should therefore precisely specify the availability target, RTO, RPO and the handling of planned maintenance, and clearly regulate the sanctions.