Data centers
Our second site NBG01
The main site FRA01 and the second site NBG01, with the role each one plays in operations.
Solution · Resilience
Backup & disaster recovery: stored separately, restored regularly
In brief
At managed-cluster.net, managed backup and disaster recovery starts with one principle: a high availability cluster is not a backup. Replication protects against hardware failure but also copies deletions and errors to every replica. We back up to infrastructure separate from the cluster, keep defined retention periods and run regular restore tests. RTO and RPO are agreed in your operations contract.
Scope
High availability, backup and disaster recovery compared
High availability, backup and disaster recovery solve three different problems. High availability handles the failure of a single component automatically. A backup brings back an earlier, undamaged state of your data. Disaster recovery is the planned path back to operation after a major incident. A resilient setup needs all three, aligned with your recovery targets.
| Criterion | High availability | Backup | Disaster recovery |
|---|---|---|---|
| Protects against | Failure of a single component: disk, node, network path | Data loss from deletion, errors or corrupted data | Events beyond automatic failover |
| Does not protect against | Logical errors, which replication copies to every replica | Downtime until the restore completes; changes since the last backup are missing | Missing foundations: a runbook needs tested backups |
| Key metric | Availability | RPO: tolerable data loss | RTO and RPO: time until service is restored, tolerable data loss |
| How we implement it | Three or more nodes with quorum, Ceph with three replicas of every block | Separate backup infrastructure, retention periods, restore tests | Documented runbooks, RTO and RPO in the operations contract, failover tests with a written log |
An overview, not a promise of individual values; binding targets are set in the operations contract. As of October 2026
For the failures the cluster handles on its own, from quorum to fencing, see what high availability covers.
Backup
How we back up: separate infrastructure, monitored and restore-tested
Your backups run on independent backup systems that are separate from the cluster. They are stored in German data centers and kept for defined retention periods. Backup monitoring checks every backup job, and we restore backups regularly as a test. An additional copy at our second site, NBG01, is included in the Business package and available on request otherwise.
- Separate backup systems: independent infrastructure, separate from the cluster and its storage.
- Defined retention periods: part of our backup strategy with separate retention.
- Every backup job checked: failures surface during normal operations, not in an emergency. Details on backup monitoring in day-to-day operations.
- Regular restore tests: backups are restored as a test and the result is checked.
- Part of the build: backups and monitoring are in place before handover.
- Migrations included: when we migrate from VMware to Proxmox, the backup infrastructure is part of the target design.
Diagram 01
Separate backups with a copy at the second site
- Backup and restore
- Replication and copy
Diagram as text
- Inside the Proxmox cluster, Ceph keeps every data block on three different nodes and also replicates errors.
- Backups run to separate backup infrastructure in German data centers; every backup job is monitored.
- An additional copy is kept at the second site NBG01 in Nuremberg: included in the Business package, otherwise on request.
- A restore brings an earlier state back into the cluster; regular restore tests verify this path.
Restore testing
Restore testing: a backup is proven only once it has been restored
In a restore test, a backup is actually restored and the result is checked. Only this step shows whether the data is complete and readable and whether the way back works. A “backup successful” message only confirms that data was written. That is why we restore backups regularly as a test.
| Check | When | What it shows |
|---|---|---|
| Backup monitoring | On every backup job | The backup job ran. Whether it can be restored only becomes clear in a restore test. |
| Restore test | Regularly | The backup can be restored and actually used. |
| Failover test | A full test before go-live, then on an agreed schedule with a written log | The cluster handles a node failure automatically. It says nothing about your backups. |
None of the three checks can stand in for another. In the Business package, we test restores at the second site NBG01.
Second site
Offsite backup in Germany: copies at our second site, NBG01
For offsite backup copies, we use NBG01 in Nuremberg, a geographically separate second site. Our main site is the Maincubes FRA01 data center in the Rhine-Main region. In the Business package, backups are stored and restore-tested at the second site; in other setups, we keep the additional copy at NBG01 on request.
A copy at NBG01 sits in a different data center in a different city. An event that affects the building, power or cooling at FRA01 therefore does not reach it directly.
Both sites are German data centers, so this is disaster recovery hosting in Germany throughout: we process and store your cluster data exclusively in Germany.
Package
Business package with two sites
Scope and fixed price, compared with the other packages.
Recovery targets
RTO vs RPO: the two targets of disaster recovery
RTO and RPO define what is acceptable after an outage. The RTO sets how long a system may be down at most. The RPO sets how much data, measured in time, may be lost at most. We capture both during the initial assessment and agree on them with you in the operations contract.
- Recovery time objective (RTO)
- The maximum tolerable time from an outage until service is restored. It is the yardstick for whether failover, a restore or a runbook is fast enough.
- Recovery point objective (RPO)
- The maximum tolerable data loss, expressed as a period of time before the outage. Anything written after the last backup or replication point is missing after recovery.
| Method | How it works | Effect on the RPO | Role in the design |
|---|---|---|---|
| Ceph replication within the cluster | Synchronous within the cluster, every data block on three different nodes | If a disk or a node fails, no data is lost. Deletions and errors, however, reach every replica at once. | High availability; not a backup |
| ZFS replication | At intervals between nodes | Changes since the last replication run may be missing; the interval determines the RPO. | High availability; not a backup |
| Backup on separate infrastructure | At intervals, with defined retention periods | Changes since the last backup are missing; in return, you can go back to an earlier state within the retention period. | Fallback for deletion, errors and corrupted data |
The Essentials and Business packages use Ceph. We use ZFS replication in individually designed, more compact setups. Specific RTO and RPO targets are set in the operations contract. As of October 2026
Which method suits your workload is shown in the comparison Ceph or ZFS and the effect on your RPO.
DR planning
Disaster recovery plan: runbooks for events beyond failover
Automatic failover covers the failure of a node: the Proxmox HA Manager restarts the affected virtual machines on another node. For scenarios that go further, we write documented runbooks. They are part of the written documentation for your cluster, and they belong to you.
-
1
Set targets
We capture availability and recovery targets during the initial assessment; RTO and RPO go into the operations contract.
-
2
Protect
Replicated storage, separate backups with retention periods, and a copy at NBG01 (included in the Business package, otherwise on request).
-
3
Document
Architecture, configuration, access details and runbooks are provided in writing and belong to you.
-
4
Test
A full failover test before go-live, then tests on an agreed schedule with a written log, plus restore tests.
The Business package adds a documented switchover plan that is tested regularly. After an incident, you receive a post-incident report covering the root cause and the measures derived from it. How we test is described under runbooks and failover testing.
Ransomware
Ransomware: why replication alone falls short
Ransomware encrypts data, and Ceph or ZFS replication carries that change to every copy like any other. Recovering after an attack therefore requires a fallback outside the cluster. That is why our backups run on backup infrastructure separate from the cluster, with defined retention periods; replication inside the cluster does not reach these backups.
Replication copies encrypted data, too.
High availability helps with hardware failures. Against encrypted or deleted data, separate backups with restore tests are what help.
Prevention includes hardening (minimal services, restrictive firewalls, secured SSH access, network segmentation) and security patches with priority for critical vulnerabilities. Tell us your requirements; we will tell you plainly what we can document today.
Evidence
Backup and disaster recovery in your information security audits
When your information security team, an auditor or a customer asks about backup management and disaster recovery, you need answers for every layer of your environment. For the platform, our operations support your measures with separate backups and restore tests, documented runbooks and failover tests with a written log. You set the RTO and RPO targets, and they become binding in the operations contract; obligations arising from requirements that apply to your organization stay with you.
Responsibilities and documents
How the platform, application, security incidents, backup and data protection are split between us and you is shown in the overview what we take on and what stays with you. The same page lists the documents you receive from us for your vendor assessment.
Packages
Backup and recovery in our packages
In the Business package, backups are stored, and restore-tested, at the second site NBG01. In the Enterprise package, we agree on individual RPO/RTO and SLA targets; a multi-site architecture is designed to your requirements. We price Enterprise environments by data volume, RPO target and switchover time and state the fixed price in the proposal.
Pricing
Compare all packages and prices
Essentials, Business and Enterprise side by side. The published prices apply to the Essentials and Business packages.
FAQ
Frequently asked questions about backup and disaster recovery
Does a high availability cluster replace backups?
No. A high availability cluster protects against hardware failure, yet it also copies deletions, faulty changes and encrypted data to every replica. To recover from those, you need a backup on separate infrastructure that lets you restore an earlier state.
Where are the backups stored?
In German data centers, separate from the cluster, on independent backup infrastructure. An additional copy is kept at the second site NBG01 in Nuremberg: included in the Business package, otherwise on request.
How often do you test restores?
Regularly. We restore backups as a test and check the result, and backup monitoring checks every single backup job on top of that. In the Business package, we test restores at the second site NBG01.
What is the difference between RTO and RPO?
The RTO (recovery time objective) is the maximum tolerable downtime; the RPO (recovery point objective) is the maximum tolerable data loss, measured in time. Whether an RTO is met depends on the way back; whether an RPO is met depends on the replication or backup interval. Both targets are set in the operations contract.
Do backups protect against ransomware?
Partly. They do not prevent an attack, but backups kept separate from the cluster give you a fallback. Replication carries encryption to every copy in the cluster like any other change. That is why our backups run on independent backup infrastructure, separate from the cluster, with defined retention periods and regular restore tests.
Recovery targets
How fast do you need to recover, and how much data can you afford to lose?
Tell us about your application, data volume and RTO and RPO requirements. We will outline how backups, a second-site copy and runbooks fit together, and you receive an initial assessment within one business day.
Define your recovery targetsRelated