Two numbers,
not one
The recovery point (RPO) states how many minutes of work an outage costs. The recovery time (RTO) states how long it takes until someone can work again. Both are constantly confused and are guaranteed separately at ENTRONYX CLOUD: 0 min to 24 h data loss, 20 min to 8 h until recovery — depending on the tier.
Limitation: The strictest guarantee — Synchronous metro mirroring without data loss — only applies in the metro pair fra1 and fra2, 8.3 km apart as the crow flies. If you want to protect against an event that affects the entire metropolitan area, you need the second copy further away. In return, you accept a recovery point above zero.
- Data loss (RPO)
- 0 min – 24 h
- Recovery point: how many minutes of work an outage costs
- Recovery time (RTO)
- 20 min – 8 h
- Recovery time: how long it takes until the first functional response
- Distance to the second location
- 14 km
- Fibre path in the metro pair; the regional tiers require at least 200 km
- Base from
- €149.00$172.84
- per protected environment and month, net
The recovery point objective (RPO) states how much work is lost in an emergency. The recovery time objective (RTO) states how long it takes until the first functional response. Both figures only apply under one condition — and this is stated for each tier, not in the small print.
The replication interval is the reason why an RPO has a number at all: there are exactly 15 minutes between two runs of tier Asynchronous replication, and if you fail in minute fourteen, you lose those fourteen minutes. In tier Secured recovery, it is 24 hours. Only synchronous mirroring has no interval — there, every write operation is acknowledged at both locations before the application considers it complete.
The recovery time depends on a second condition that is not included in the number: the capacity in the target region. Secured recovery starts on free capacity and therefore only keeps its time commitment on weekdays during the day window. Pilot Light provisions a host and starts immediately — but with around a quarter of the productive performance until further hosts are added. The commitments therefore differ not only in the number, but in what they require.
Recovery
Logarithmic timeline · 5 min to 24 h
Recovery tiers: data loss and restart
- RPO — Data loss window before the incident
- RTO — Recovery after the incident
- Tightest tier — shortest recovery, highlighted
- RPO 0 — synchronously mirrored, no data loss
Both halves of the axis are logarithmically compressed. Drawn linearly, the fastest tier would be a line: 15 minutes is one percent of 24 hours. The compression comes at a price that should be mentioned here — equal distances mean equal factors, not equal minutes: the path from 15 minutes to 1 hour is just as long as the one from 6 to 24 hours. Both quadruple the time, one costs 45 minutes, the other 18 hours. An RPO of 0 has no place on a logarithmic axis and therefore sits as its own mark directly on the incident axis.
Recovery point objective (RPO), recovery time objective (RTO) and price components per tier. Amounts are net; the rate per protected gigabyte is less than one cent and is therefore shown with four decimal places.
| Tier | RPO | RTO | Replication interval | Target region | Tests per year | Base fee per month | Per protected GB |
|---|---|---|---|---|---|---|---|
| Secured recoveryNightly backup to a second EU region, restart on demand. | 24 h | 8 h | every 24 h | Second EU region, from 300 km | 1 | €149.00$172.84 | €0.0074$0.0086 |
| Pilot LightOne standby host in the target region, replication every four hours. | 4 h | 4 h | every 4 h | Region in the same jurisdiction, from 200 km | 2 | €490.00$568.40 | €0.0190$0.0220 |
| Asynchronous replicationQuarter-hourly block replication to a region in the same jurisdiction. | 15 min | 2 h | every 15 min | Region in the same jurisdiction, from 200 km | 4 | €990.00$1,148.40 | €0.0340$0.0394 |
| Synchronous metro mirroringNo data loss: every write operation is acknowledged at both locations. | 0 min | 20 min | synchronous | Metro pair in the same metropolitan area, 5 to 60 km | 4 | €1,890.00$2,192.40 | €0.0690$0.0800 |
Limitation per tier
- Secured recovery
- The restart uses free capacity in the target region. Without booked capacity reservation, the RTO commitment only applies Mon–Fri 08:00–18:00; outside this time, there is no guaranteed restart time.
- Pilot Light
- A single host runs in the target region with around 25% of the productive capacity. Full throughput is only available after adding more hosts — lead time up to 90 minutes.
- Asynchronous replication
- The RPO of 15 minutes applies up to a change rate of 40 MB/s per datastore. Above this, the replication lag grows, and the actual recovery point is further back than committed.
- Synchronous metro mirroring
- Only available between fra1 and fra2. Every write operation costs around 0.3 ms extra, and logical errors are mirrored synchronously — this tier does not replace a backup, it complements it.
Not every tier is available on every platform
Approval is not based on price, but on technology. Synchronous mirroring requires a shared datastore — a storage area shared by all hosts — and is therefore only available where one exists. Pilot Light is missing from the certified SAP nodes for the opposite reason: a provisioned host with around a quarter of the productive capacity does not correspond to the approved configuration. The certification applies exclusively to the delivered one.
Availability of the 4 recovery tiers on the four virtualisation platforms of the Private Cloud. Ticks and minuses each have their own name; the colour does not stand alone. · Table scrollable sideways
| Tier | KVM Platform | Managed vSphere | HCI | SAP Certified |
|---|---|---|---|---|
| Secured recoveryNightly backup to a second EU region, restart on demand. | ||||
| Pilot LightOne standby host in the target region, replication every four hours. | ||||
| Asynchronous replicationQuarter-hourly block replication to a region in the same jurisdiction. | ||||
| Synchronous metro mirroringNo data loss: every write operation is acknowledged at both locations. |
Two amounts, two bases
A recovery tier costs a fixed base fee per protected environment and an additional rate for each protected gigabyte. The two amounts measure different things and are therefore shown separately — even where a single number would be more convenient.
Component 1 · per environment
Base fee
€149.00$172.84up to €1,890.00$2,192.40 per month
This pays for what is incurred regardless of the data volume: orchestration of the failover, the maintained runbook (the written step-by-step guide for recovery), the provisioned target environment and the recovery tests of the year. Two terabytes and twenty terabytes cost the same here, because the effort is the same.
The base fee is the starting price of this page: €149.00$172.84 net per month for Secured recovery — corresponding to €177.31$205.68 incl. 19% VAT.
Component 2 · per gigabyte
Rate on the protected capacity
€0.0074$0.0086up to €0.0690$0.0800 per GB and month
This rate pays for the second copy: transfer, occupied capacity at the destination and its redundancy. It grows with every protected gigabyte and is therefore the variable that actually controls the price of an environment — not every volume needs to be protected.
Four decimal places, because two are not enough: €0.0074$0.0086 rounded to two places would be €0.01$0.01, and the rate of the entry tier would thus be significantly too high in the table.
Which component drives the cost, and when
Up to a protected capacity of around 19.7 TB to 28.4 TB — depending on the tier — you pay predominantly for the procedure, not for the data. Only above this does the ratio reverse. This is the number that should be asked for first in procurement, because it decides whether an environment becomes cheaper with fewer protected volumes or not.
Both price components separately, plus the monthly total for three protected capacities and the point at which the capacity share catches up with the base fee. All amounts net. The rate per gigabyte is under one cent and is therefore shown with four decimal places. · Table scrollable sideways
| Tier | Base fee per month | Per protected GB | Total at 1 TB | Total at 8 TB | Total at 64 TB | Parity from |
|---|---|---|---|---|---|---|
| Secured recovery | €149.00$172.84 | €0.0074$0.0086 | €156.58$181.63Base fee 95% | €209.62$243.16Base fee 71% | €633.97$735.41Base fee 24% | 19.7 TB |
| Pilot Light | €490.00$568.40 | €0.0190$0.0220 | €509.46$590.97Base fee 96% | €645.65$748.95Base fee 76% | €1,735.18$2,012.81Base fee 28% | 25.2 TB |
| Asynchronous replication | €990.00$1,148.40 | €0.0340$0.0394 | €1,024.82$1,188.79Base fee 97% | €1,268.53$1,471.49Base fee 78% | €3,218.22$3,733.14Base fee 31% | 28.4 TB |
| Synchronous metro mirroring | €1,890.00$2,192.40 | €0.0690$0.0800 | €1,960.66$2,274.37Base fee 96% | €2,455.25$2,848.09Base fee 77% | €6,411.98$7,437.90Base fee 29% | 26.7 TB |
The three example sizes are not quote tiers. Two of them are the minimum sizes of real datastore classes, the third is deliberately above all parity points — otherwise the table would only show base amounts and the second component would remain invisible. Recovery is billed in addition to hosts, licences, datastore and operations, not instead of them.
Proximity and protection pull in opposite directions
Each tier binds its replica to a rule for the destination. The rule is not a formality: it decides which event the copy actually helps against. A second location within sight will not survive an outage that affects the metropolitan area — a location a thousand kilometres away cannot carry a synchronous acknowledgement.
- Metro pair in the same metropolitan area
- The latency must remain so low that every write operation can be acknowledged at both locations before the application waits.
- Location in the same jurisdiction
- A change of location within the same jurisdiction leaves responsibility, reporting channels and the supervisory authority unchanged.
- Second location in the EU
- For the furthest tier, binding to the European jurisdiction is sufficient; the distance protects against an event that affects an entire region.
Destination rule, distance limit and the locations that meet them from fra1 (Frankfurt am Main). This is checked as the crow flies from the location coordinates — the stricter check, because a fibre path is never shorter than the straight line. · Table scrollable sideways
| Tier | Destination rule | Distance limit | Permitted from fra1 | Nearest destination |
|---|---|---|---|---|
| Secured recovery | Second location in the EU | from 300 km | Munich (muc1, 304 km) · Berlin (ber1, 423 km) · Helsinki (hel1, 1,515 km) | muc1 · 304 km |
| Pilot Light | Location in the same jurisdiction | from 200 km | Munich (muc1, 304 km) · Berlin (ber1, 423 km) | muc1 · 304 km |
| Asynchronous replication | Location in the same jurisdiction | from 200 km | Munich (muc1, 304 km) · Berlin (ber1, 423 km) | muc1 · 304 km |
| Synchronous metro mirroring | Metro pair in the same metropolitan area | 5 – 60 km | Frankfurt am Main (fra2, 8 km) | fra2 · 8 km |
Synchronous mirroring means: the application only receives its confirmation when both locations have acknowledged the write operation. The overhead for this is not an empirical value, but a distance divided by a speed. Both are listed below so that the number can be recalculated instead of believed.
Derivation
- Straight line fra1 ↔ fra2Great circle from the coordinates of both locations
- 8.3 km
- Fibre pathCatalogue value — routes follow roads and railway tracks, not the straight line
- 14 km
- Detour factorFibre path divided by straight line
- 1.68
- Signal speed in the glass coreAround two thirds of the speed of light in a vacuum, refractive index approx. 1.47
- 200.000 km/s
- One-way latency14 km divided by 200,000 km/s
- 0.070 ms
- Round-trip latencyWrite operation there, acknowledgement back
- 0.140 ms
- Guaranteed overheadCatalogue value of the metro pair
- 0.300 ms
- Share of active equipmentDifference: transponders, switches and storage controllers on both sides
- 0.160 ms
The result is more uncomfortable than it looks: the fibre only contributes 0.140 ms of the 0.300 ms. The larger share arises at the ends — in transponders, switches and storage controllers. This share does not shrink when the locations move closer together; it is the lower limit of any synchronous mirroring, no matter how short the distance.
Conversely, the same calculation explains the upper limit of 60 km: if the full permissible distance were present as a fibre path, the latency would rise to 0.600 ms and the overhead to 0.760 ms. That is almost double the guaranteed write latency of the fastest datastore class — the mirroring would then destroy the property for which this class is bought.
What 0.3 ms means in a serialised chain
An overhead of three tenths of a millisecond sounds like nothing until it adds up. It does this wherever a write operation waits for the acknowledgement of the previous one — in the transaction log of a database, this is exactly the normal case. The following calculation takes the guaranteed p99 latency of the class as a reference, i.e. the response time that 99 out of 100 write operations do not exceed. It thus shows the lower limit of the rate, not everyday life.
Effect of the metro overhead of 0.300 ms on a strictly serialised write chain. Calculated on the guaranteed p99 latency per datastore class; each write operation waits for the acknowledgement of the preceding one. · Table scrollable sideways
| Datastore class | Latency p99 | With mirroring | Serialised without | Serialised with | Loss |
|---|---|---|---|---|---|
| Datastore NVMe Performance | 0.4 ms | 0.7 ms | 2.500 /s | 1.429 /s | 43 % |
| Datastore NVMe Standard | 0.9 ms | 1.2 ms | 1.111 /s | 833 /s | 25 % |
| Datastore Capacity | 4.0 ms | 4.3 ms | 250 /s | 233 /s | 7 % |
| Read operations | Unchanged. Reading is done locally; only the write path waits for the second acknowledgement. | ||||
Multiple open queues raise the rate again — the waiting time then runs in parallel instead of one after the other. Anyone operating an application with a single write chain and needing the full write rate therefore does not choose synchronous mirroring, but an asynchronous level and accepts an RPO above zero. This decision is made before ordering, not in an emergency.
A recovery tier guarantees a point in time and a duration. It says nothing about which data actually arrives in the target region. This list is the answer to that, and the right column is the more important of the two.
What is replicated
The reference value is the protected capacity — the same amount on which the rate per gigabyte is calculated. Retained states are included, within the period of the respective datastore class — for the operational classes a maximum of 30 days.
- Blocks of the protected datastores
- Guest disks, configuration files and templates, provided they reside on a protected datastore. The replicated volume is exactly the volume billed for — there is no hidden surcharge for management data.
- Snapshots as part of retention
- The retention period of the datastore class also applies in the target region. It is the counterpart to replication: a replica protects against the loss of a location, a retained state against an error that was written to both locations.
- Placement and network assignment
- Which guest belongs in which segment, in what order it starts and what it depends on is detailed in the runbook and updated with every change. This is not a data stream, but a maintained document — and the part that stands out most often during a test.
What is not replicated
Six points where recovery typically gets stuck. None of these is a gap in the product — each is a decision that must be made on your side before it becomes apparent in an emergency.
- Memory content
- A restart is a cold start, even with synchronous mirroring. Writes to storage are mirrored, not the state of running processes. Whatever an application only held in memory is gone after the failover.
- Local drives outside protected datastores
- What resides on a host's local NVMe and does not belong to a protected datastore is not replicated. This particularly affects environments that were deliberately built without a shared datastore.
- The management plane itself
- vCenter or the cluster console are newly provisioned in the target region, not mirrored. In an emergency, a mirrored management plane would create two instances with the same claim to the same guests — the most expensive state imaginable.
- Public addresses
- A restart in another region runs under the addresses of that region. The switchover happens via the name service, unless you bring your own address ranges and announce them at the target location.
- Everything outside the protected environment
- Directory service, name resolution, time source, licence server, payment provider: whatever is not in the protected environment does not start up with it. Every such dependency needs its own answer before it stands out in the first test.
- The difference between location loss and data error
- A replication transfers every write operation, even the wrong one. A replica does not help against an accidentally deleted table, only a retained state from before does. Therefore, no tier on this page replaces a backup — each complements it.
Failover process
The takeover — in technical jargon failover, i.e. switching operations to the second location — runs in five steps, the sum of which results in the guaranteed recovery time: between 20 min and 8 h, depending on the tier. Individual steps deliberately do not have a minute specification: the sum is guaranteed, not its distribution.
- 01
Trigger
A failover is triggered by a named person in your organisation, not decided by us. The only exception is synchronous Metro mirroring: there, the cluster switches over itself as soon as the quorum — the majority of the cluster nodes — excludes the failed location — with zero data loss, there is nothing to weigh up.
- 02
Determine state
Before starting, it is recorded which recovery point is actually present. It is usually more recent than the guaranteed RPO — the commitment is an upper limit, not a target value. This determination is the reason why a failover does not begin with the first click.
- 03
Provision network
Segments, firewall rules and name resolution are activated in the target region. Until then, nothing starts: guests that start before their network report errors that no one can subsequently distinguish from real ones.
- 04
Start in order
The guests start in the order of the runbook — databases before applications, applications before external access. The order is in writing because in an emergency it is not derived, but executed.
- 05
Approve functionally
The environment is considered failed over when your functional checkpoints have passed — not when all machines are running. Only with this approval does the recovery time guaranteed on this page end.
Failback process
The failback — the return to the original location — is not an undo. It is a second switchover, with the same effort and care as the first. It runs in a maintenance window, i.e. in a previously agreed period, not during live operations. Only with Metro mirroring is it omitted as a separate process: automatically, as soon as the failed location is back in the quorum.
- 01
The target region remains primary
After a failover, the environment continues to run there until the original location is fully capable again. A quick return to a just-recovered location is the second outage, not the end of the first.
- 02
Replication in the opposite direction
The changes that have occurred since the failover flow back to the origin. How this happens depends on the tier: everything from a full restore to a switchover without full synchronisation is represented — the procedure per tier is in the table below.
- 03
Switchover in the window
The actual return happens in an agreed maintenance window, not during live operations. It is short because the data synchronisation has already run at this point; what remains is a final delta and the reversal of the direction.
- 04
Protection only applies again afterwards
Between failover and completed return, the environment runs at a single location. During this time, there is no second copy and therefore none of the commitments on this page. This is the most important side effect of a failover — and the reason why a return is planned and not waited for.
How the changes from the target region return to the origin — wording from the catalogue, different for each tier, because the replication interval determines the return direction just as much as the outward direction.
| Tier | Return |
|---|---|
| Secured recovery | Failback as full restore, duration same as restart |
| Pilot Light | Failback in the maintenance window, delta replication in the opposite direction |
| Asynchronous replication | Switchover in the opposite direction without full synchronization, maintenance window 30 minutes |
| Synchronous metro mirroring | Automatic, as soon as the failed location is back in the quorum |
A recovery time of twenty minutes that has never been timed with a stopwatch says nothing about twenty minutes — it says something about the operator's intention. That is why every tier includes a fixed number of tests per year, a procedure for how testing is done, and a criterion for when a test is passed.
The number of tests increases with the strictness of the commitment, and that is no coincidence: Secured recovery is tested 1 times a year because a recovery window of eight hours leaves plenty of leeway. A commitment of twenty minutes leaves none — it is proven 4 times a year or it does not apply. The failback is tested in the same test; a recovery with no way back is not a recovery, but a migration. Your procedure per tier is in the section above.
Contractually scheduled tests per year, from the service catalogue. The failback procedure is in “Scope and process” and is not repeated here.
| Tier | Tests / year |
|---|---|
| Secured recovery | 1 |
| Pilot Light | 2 |
| Asynchronous replication | 4 |
| Synchronous metro mirroring | 4 |
Test process
The order is not arbitrary. Step three prohibits the specially prepared special state, step five prohibits the mere proof of start. Without these two blocks, a test tests itself and always passes.
Step 01
Date and window
The date is agreed ten working days in advance and falls outside your closing and deadline periods. The test is announced, not a surprise — an unannounced test measures the readiness of people, not the recoverability of the environment.
Step 02
Isolated target network
Recovery takes place in a network segment with no path to production. Same addresses, same names, no repercussions. The productive environment continues to run unchanged throughout the test; switching production is explicitly not part of the test.
Step 03
Startup from the latest replica
The state that is already in the target region at the time of triggering is started. No specially taken snapshot, no prepared special state, no manual intervention on the replica before startup. What was not replicated is also not there in the test.
Step 04
Measurement against the committed figure
The clock runs from the trigger until the first functionally correct response from the application — not until the startup process is complete. In parallel, the actual data state is determined and compared against the committed recovery point.
Step 05
Functional testing by you
Login, a read and a write operation, a report or an interface query: you define the test points beforehand, and you execute them. Without this step, a test only proves that machines start.
Step 06
Dismantling and report
The target environment is dismantled, the report is sent to you within five working days: measured recovery time, actual data state, every deviation from the commitment and, for each deviation, a measure with a deadline and named responsibility.
When a test is passed
All three criteria must apply. Two out of three is not a partial success, but a finding — and triggers the same treatment as a complete failure.
- Time met: The measured recovery time is at or below the committed RTO of the booked tier.
- Data state met: The gap between the last committed write operation and the trigger time is within the committed RPO.
- Functionally passed: Every previously defined functional test point is passed. A system that has started but does not respond functionally is considered not recovered.
If it is not passed
A test without consequences is not a test. What follows a failure is therefore determined in advance — including the uncomfortable consequence for the commitment.
- Repetition within 30 days
- A failed test is repeated within 30 calendar days. It does not count as one of the contractually scheduled tests for the year — otherwise a failure would use up the testing budget intended to fix it.
- Blameless root cause analysis
- The system is investigated, not the person at the button. The report names the triggering condition, the chain up to the impact and the point where a safeguard was missing.
- Commitment suspended, not tacitly kept
- Until the repetition is passed, the time commitment of the tier is considered suspended. We do not carry forward a recovery time that was not achieved last time.
What must be present on your side
A recovery fails just as reliably due to a missing time source as it does due to missing capacity. These three points lie outside of what an operator can guarantee — they are nevertheless part of the commitment because they determine its outcome.
A runbook that works without its author
The order of the systems, the dependencies between them and the functional test points are documented in writing and cross-checked during every test. A runbook that only its author can execute is not a runbook.
Named dependencies outside replication
Directory service, name resolution, time source, licence server, payment provider: what lies outside the protected environment does not start up with it. Every such dependency needs its own answer before it becomes apparent in the test.
Access routes that survive the failure
Access data, second factors and emergency contacts are not located exclusively in the environment that is to be recovered. This sounds obvious and is the most common finding of the first test.
Three things this page explicitly does not cover
A recovery tier answers exactly one question: how does an environment come back if its location fails. It does not answer three related questions — and anyone who overlooks this buys the wrong commitment.
Availability during operations
The committed availability, its measurement method and the service credit scale are in the Service Level Agreement. They measure the ongoing operations of a platform. A recovery case begins where this measurement ends: with the loss of the location where the measurement took place. A level on this page therefore does not replace an availability class — and an availability class does not replace a recovery level.
Restriction: Service credits according to the SLA scale arise from availability falling short, not from an exceeded recovery time. The testing procedure applies to the time commitments on this page, not the service credit scale.
Protection against your own mistakes
Replication transfers every write operation, even the wrong ones. A deleted table, an encrypted file share or a faulty procedure will be exactly the same at the second location after the transfer. Only retention helps against this: a previous state that is not overwritten. Snapshot retention depends on the datastore class and lasts up to 90 days.
- Datastore NVMe Performance
- 14 days
- Datastore NVMe Standard
- 14 days
- Datastore Capacity
- 30 days
Restriction: Only available between fra1 and fra2. Every write operation costs around 0.3 ms extra, and logical errors are mirrored synchronously — this tier does not replace a backup, it complements it.
Capacity at the destination
A recovery time assumes that something starts up at the destination. The other two levels solve this differently — and both answers have a condition that is not included in the time specification. If you need a round-the-clock time commitment, you book the capacity reservation; it is not an accessory, but the reason why the number applies.
Restriction: The restart uses free capacity in the target region. Without booked capacity reservation, the RTO commitment only applies Mon–Fri 08:00–18:00; outside this time, there is no guaranteed restart time.
Restriction: A single host runs in the target region with around 25% of the productive capacity. Full throughput is only available after adding more hosts — lead time up to 90 minutes.
What you order as protected is protected. Volumes that are not in the protected capacity are not there after a location loss — even if they were on the same datastore. The smallest sensible protected capacity is therefore not zero, but the scope that a recovery actually needs — and that is never below the minimum purchase of the operational datastore, from 1 TB.
First check the condition, then order the number
In the configurator, host class, datastore, recovery level and operations level are side by side, and the total is calculated using the same rates as this page: base fee per protected environment plus rate per protected gigabyte. If you want to know in advance which level suits your application, do not start with the price, but with the question of how much work an outage is allowed to cost.
- Tiers
- 4
- RPO from
- 0 min
- RTO from
- 20 min
- Tests per year
- 1 – 4