Rechenzentren
Zweitstandort NBG01
Hauptstandort FRA01 und Zweitstandort NBG01 mit ihren Rollen im Betrieb.
Lösung · Resilienz
Backup & Disaster Recovery: getrennt gesichert, regelmäßig zurückgespielt
Kurzantwort
Backup und Disaster Recovery beginnen bei managed-cluster.net mit einem Grundsatz: Ein HA-Cluster ersetzt kein Backup. Replikation schützt vor dem Ausfall von Hardware, überträgt aber auch Löschungen und Fehler auf alle Kopien. Deshalb sichern wir auf einer vom Cluster getrennten Backup-Infrastruktur und spielen Sicherungen regelmäßig testweise zurück. Wiederanlaufziele (RTO und RPO) legen wir gemeinsam im Betriebsvertrag fest.
Abgrenzung
Hochverfügbarkeit, Backup und Disaster Recovery im Vergleich
Hochverfügbarkeit, Backup und Disaster Recovery lösen drei verschiedene Probleme. Hochverfügbarkeit fängt den Ausfall einzelner Komponenten automatisch ab. Ein Backup holt einen früheren, unbeschädigten Datenstand zurück. Disaster Recovery beschreibt, wie Sie nach einem größeren Ereignis geplant wieder anlaufen. Ein belastbares Konzept braucht alle drei, abgestimmt auf Ihre Wiederanlaufziele.
| Kriterium | Hochverfügbarkeit | Backup | Disaster Recovery |
|---|---|---|---|
| Schützt vor | Ausfall einzelner Komponenten: Platte, Node, Netzpfad | Datenverlust durch Löschen, Fehler oder beschädigte Daten | Ereignissen über den automatischen Failover hinaus |
| Schützt nicht vor | Logischen Fehlern, denn die Replikation überträgt sie auf alle Kopien | Ausfallzeit bis zur Rücksicherung; Änderungen seit der letzten Sicherung fehlen | Fehlenden Grundlagen: Ein Notfallplan braucht getestete Sicherungen |
| Kennzahl | Verfügbarkeit | RPO: tolerierbarer Datenverlust | RTO und RPO: Zeit bis zum Wiederanlauf, tolerierbarer Datenverlust |
| So setzen wir es um | Ab drei Nodes mit Quorum, Ceph mit drei Repliken je Datenblock | Getrennte Backup-Infrastruktur, Aufbewahrungsfristen, Restore-Tests | Dokumentierte Notfallpläne, RTO und RPO im Betriebsvertrag, Failover-Tests mit Protokoll |
Einordnung, keine Zusage einzelner Werte; verbindliche Ziele stehen im Betriebsvertrag. Stand: Oktober 2026
Was Hochverfügbarkeit abdeckt, von Quorum bis Fencing, beschreibt unsere Seite zum High Availability Cluster.
Sicherung
So sichern wir: getrennte Backup-Infrastruktur, überwacht und getestet
Ihre Backups laufen bei managed-cluster.net auf eigenständigen Backup-Systemen, die vom Cluster getrennt sind. Sie liegen in deutschen Rechenzentren und werden nach definierten Aufbewahrungsfristen vorgehalten. Unsere Backup-Überwachung kontrolliert jede einzelne Sicherung, und in regelmäßigen Restore-Tests spielen wir Sicherungen zurück. Eine zusätzliche Kopie am Zweitstandort NBG01 ist im Business-Paket enthalten und sonst auf Wunsch möglich.
- Getrennte Backup-Systeme: eigenständige Infrastruktur, getrennt vom Cluster und seinem Storage.
- Definierte Aufbewahrungsfristen: Teil unserer Backup-Strategie mit getrennter Aufbewahrung.
- Überwachung jeder Sicherung: Fehler fallen im laufenden Betrieb auf und nicht erst im Notfall. Details zur Backup-Überwachung im Betrieb.
- Regelmäßige Restore-Tests: Sicherungen werden testweise zurückgespielt und geprüft.
- Teil des Aufbaus: Backups und Monitoring sind vor der Übergabe eingerichtet.
- Auch bei Migrationen: Bei der Migration von VMware zu Proxmox ist die Backup-Infrastruktur Teil des Zielbilds.
Schema 01
Getrennte Sicherung mit Kopie am Zweitstandort
- Sicherung und Rücksicherung
- Replikation und Kopie
Schema als Text
- Im Proxmox-Cluster hält Ceph jeden Datenblock dreifach auf verschiedenen Nodes und repliziert dabei auch Fehler.
- Sicherungen laufen auf eine getrennte Backup-Infrastruktur in deutschen Rechenzentren; jede Sicherung wird überwacht.
- Eine zusätzliche Kopie liegt am Zweitstandort NBG01 in Nürnberg: im Business-Paket enthalten, sonst auf Wunsch.
- Die Rücksicherung spielt einen früheren Stand in den Cluster zurück; Restore-Tests prüfen diesen Weg regelmäßig.
Restore-Tests
Restore-Test: erst das Zurückspielen prüft eine Sicherung
Bei einem Restore-Test wird eine Sicherung tatsächlich zurückgespielt und das Ergebnis geprüft. Erst dieser Schritt zeigt, ob die Daten vollständig und lesbar sind und ob der Weg zurück funktioniert. Die Meldung „Sicherung erfolgreich“ belegt nur, dass geschrieben wurde. Deshalb spielen wir Sicherungen regelmäßig testweise zurück.
| Prüfung | Wann | Was sie zeigt |
|---|---|---|
| Backup-Überwachung | Bei jeder Sicherung | Die Sicherung ist gelaufen. Ob sie sich zurückspielen lässt, zeigt erst der Restore-Test. |
| Restore-Test | Regelmäßig | Die Sicherung lässt sich zurückspielen und verwenden. |
| Failover-Test | Vor der Inbetriebnahme vollständig, danach im abgestimmten Rhythmus mit Protokoll | Der Cluster fängt einen Node-Ausfall automatisch ab. Über die Sicherungen sagt er nichts. |
Keine der drei Prüfungen ersetzt eine andere. Im Business-Paket testen wir die Wiederherstellung am Zweitstandort NBG01.
Zweitstandort
Backup am zweiten Standort: Kopien in NBG01 Nürnberg
Für Sicherungen außerhalb des Hauptstandorts nutzen wir NBG01 in Nürnberg, einen geografisch getrennten zweiten Standort. Der Hauptstandort ist das Rechenzentrum Maincubes FRA01 im Rhein-Main-Gebiet. Im Business-Paket liegen die Backups mit Restore-Tests am Zweitstandort; in anderen Konstellationen legen wir die zusätzliche Kopie in NBG01 auf Wunsch ab.
Eine Kopie in NBG01 liegt in einem anderen Rechenzentrum in einer anderen Stadt. Ein Ereignis, das Gebäude, Stromversorgung oder Kühlung in FRA01 betrifft, erreicht sie deshalb nicht unmittelbar.
Damit bleibt auch Ihr Disaster Recovery Hosting in Deutschland: Ihre Cluster-Daten verarbeiten und speichern wir ausschließlich in Deutschland.
Paket
Business-Paket mit zwei Standorten
Leistungsumfang und Festpreis im Vergleich der Pakete.
Wiederanlaufziele
RTO und RPO: die zwei Kennzahlen der Notfallwiederherstellung
RTO und RPO beschreiben, was nach einem Ausfall akzeptabel ist. Der RTO legt fest, wie lange ein System höchstens stehen darf. Der RPO legt fest, wie viele Daten, gemessen in Zeit, höchstens verloren gehen dürfen. Beide Werte erfassen wir in der Bestandsaufnahme und legen sie gemeinsam mit Ihnen im Betriebsvertrag fest.
- Recovery Time Objective (RTO)
- Die höchstens tolerierbare Zeit vom Ausfall bis zum Wiederanlauf. An ihr messen Sie, ob Failover, Rücksicherung oder Notfallplan schnell genug sind.
- Recovery Point Objective (RPO)
- Der höchstens tolerierbare Datenverlust, ausgedrückt als Zeitspanne vor dem Ausfall. Was nach dem letzten Sicherungs- oder Replikationsstand geschrieben wurde, fehlt nach der Wiederherstellung.
| Verfahren | Arbeitsweise | Folge für den RPO | Rolle im Konzept |
|---|---|---|---|
| Ceph-Replikation im Cluster | Synchron innerhalb des Clusters, jeder Datenblock dreifach auf verschiedenen Nodes | Fällt eine Platte oder ein Node aus, gehen keine Daten verloren. Löschungen und Fehler liegen aber sofort auf allen Repliken. | Hochverfügbarkeit; ersetzt kein Backup |
| ZFS-Replikation | In Intervallen zwischen den Nodes | Änderungen seit dem letzten Replikationslauf können fehlen; das Intervall bestimmt den RPO. | Hochverfügbarkeit; ersetzt kein Backup |
| Backup auf getrennter Infrastruktur | In Intervallen, mit definierten Aufbewahrungsfristen | Änderungen seit der letzten Sicherung fehlen; dafür ist ein früherer Stand innerhalb der Aufbewahrungsfrist erreichbar. | Rückfallebene bei Löschung, Fehlern und beschädigten Daten |
Die Pakete Essentials und Business nutzen Ceph. ZFS-Replikation setzen wir in individuell konzipierten, kompakteren Setups ein. Konkrete RTO- und RPO-Ziele legen wir im Betriebsvertrag fest. Stand: Oktober 2026
Welches Verfahren zu Ihrem Lastprofil passt, zeigt der Vergleich Ceph oder ZFS: Auswirkung auf den RPO.
Notfallplanung
Disaster-Recovery-Plan: Notfallwiederherstellung über den Failover hinaus
Der automatische Failover deckt den Ausfall eines Nodes ab: Der Proxmox HA Manager startet die betroffenen virtuellen Maschinen auf einem anderen Node neu. Für Szenarien, die darüber hinausgehen, erstellen wir dokumentierte Notfallpläne. Sie sind Teil der schriftlichen Dokumentation zu Ihrem Cluster und gehören Ihnen.
-
1
Ziele festlegen
Verfügbarkeits- und Wiederanlaufziele erfassen wir in der Bestandsaufnahme; RTO und RPO stehen im Betriebsvertrag.
-
2
Absichern
Replizierter Storage, getrennte Backups mit Aufbewahrungsfristen, eine Kopie in NBG01 (im Business-Paket enthalten, sonst auf Wunsch).
-
3
Dokumentieren
Architektur, Konfiguration, Zugänge und Notfallpläne liegen schriftlich vor und gehören Ihnen.
-
4
Testen
Failover-Tests vor der Inbetriebnahme vollständig, danach im abgestimmten Rhythmus mit Protokoll; dazu Restore-Tests.
Im Business-Paket kommt ein dokumentierter Umschaltplan hinzu, der regelmäßig getestet wird. Nach einem Vorfall erhalten Sie einen Nachbericht mit Ursache und abgeleiteten Maßnahmen. Wie wir testen, beschreibt die Leistung Notfallpläne und Failover-Tests.
Ransomware
Backup gegen Ransomware: warum Replikation allein nicht reicht
Ein Verschlüsselungstrojaner verändert Daten, und Ceph oder die ZFS-Replikation übertragen diese Änderung wie jede andere auf alle Kopien. Für den Weg zurück brauchen Sie eine Rückfallebene außerhalb des Clusters. Deshalb laufen unsere Backups auf einer vom Cluster getrennten Backup-Infrastruktur mit definierten Aufbewahrungsfristen; die Replikation im Cluster erreicht diese Sicherungen nicht.
Replikation überträgt auch eine Verschlüsselung.
Hochverfügbarkeit hilft bei Hardware-Ausfällen. Gegen verschlüsselte oder gelöschte Daten helfen getrennte Backups mit Restore-Tests.
Zur Vorbeugung gehören Härtung (minimale Dienste, restriktive Firewalls, abgesicherte SSH-Zugänge, Netztrennung) und Sicherheits-Patches mit Vorrang für kritische Lücken. Sprechen Sie uns auf Ihre Anforderungen an; wir sagen Ihnen offen, was wir heute belegen können.
Nachweise
Backup und Notfallvorsorge in Audits Ihrer Informationssicherheit
Fragen Ihre Informationssicherheit, ein Audit oder ein Kunde nach Backup-Management und Wiederherstellung nach einem Notfall, brauchen Sie Antworten für jede Ebene Ihrer Umgebung. Für die Plattform unterstützt unser Betrieb Ihre Maßnahmen mit getrennten Backups und Restore-Tests, dokumentierten Notfallplänen und Failover-Tests mit Protokoll. Die Ziele für RTO und RPO geben Sie vor, verbindlich werden sie im Betriebsvertrag; Pflichten, die sich aus Anforderungen an Ihr Unternehmen ergeben, bleiben bei Ihnen.
Zuständigkeiten und Unterlagen
Wie sich Plattform, Anwendung, Sicherheitsvorfälle, Backup und Datenschutz zwischen uns und Ihnen aufteilen, zeigt die Übersicht Was wir übernehmen und was bei Ihnen bleibt. Auf derselben Seite stehen die Unterlagen, die Sie für Ihre Lieferantenbewertung von uns erhalten.
Pakete
Backup und Wiederanlauf in den Paketen
Im Business-Paket liegen die Backups mit Restore-Tests am Zweitstandort NBG01 in Nürnberg. Im Enterprise-Paket vereinbaren wir individuelle RPO/RTO- und SLA-Ziele; eine Multi-Standort-Architektur planen wir nach Anforderung. Enterprise-Umgebungen kalkulieren wir nach Datenmenge, RPO-Ziel und Umschaltzeit und nennen den Festpreis im schriftlichen Konzept.
Preise
Alle Pakete und Preise
Essentials, Business und Enterprise im Vergleich. Für die Pakete Essentials und Business gelten die veröffentlichten Preise.
FAQ
Häufige Fragen zu Backup und Disaster Recovery
Ersetzt ein HA-Cluster ein Backup?
Nein. Ein HA-Cluster schützt vor Hardware-Ausfällen, überträgt aber auch Löschungen, fehlerhafte Änderungen und verschlüsselte Daten auf alle Kopien. Dagegen brauchen Sie ein Backup auf getrennter Infrastruktur, aus dem sich ein früherer Stand zurückspielen lässt.
Wo liegen die Backups?
Getrennt vom Cluster in deutschen Rechenzentren, auf einer eigenständigen Backup-Infrastruktur. Eine zusätzliche Kopie liegt am Zweitstandort NBG01 in Nürnberg: im Business-Paket inklusive, sonst auf Wunsch.
Wie oft wird die Wiederherstellung getestet?
Regelmäßig. Wir spielen Sicherungen testweise zurück und prüfen das Ergebnis; zusätzlich kontrolliert die Backup-Überwachung jede einzelne Sicherung. Im Business-Paket testen wir die Wiederherstellung am Zweitstandort NBG01.
Was ist der Unterschied zwischen RTO und RPO?
Der RTO (Recovery Time Objective) ist die höchstens tolerierbare Ausfallzeit, der RPO (Recovery Point Objective) der höchstens tolerierbare Datenverlust, gemessen in Zeit. Ob ein RTO eingehalten wird, entscheidet der Weg zurück; ob ein RPO eingehalten wird, das Replikations- oder Sicherungsintervall. Beide Ziele legen wir im Betriebsvertrag fest.
Schützen Backups vor Ransomware?
Teilweise. Sie verhindern keinen Angriff, aber vom Cluster getrennte Backups geben Ihnen eine Rückfallebene. Replikation überträgt eine Verschlüsselung wie jede andere Änderung auf alle Kopien im Cluster. Unsere Backups laufen deshalb auf einer eigenständigen, vom Cluster getrennten Backup-Infrastruktur mit definierten Aufbewahrungsfristen und regelmäßigen Restore-Tests.
Wiederanlaufziele
Wie schnell und mit welchem Datenstand müssen Sie wieder anlaufen?
Nennen Sie uns Anwendung, Datenmenge und Ihre Anforderungen an RTO und RPO. Wir ordnen ein, wie Backup, Zweitstandort und Notfallplan dazu passen; eine erste Einschätzung erhalten Sie innerhalb eines Werktags.
Wiederanlaufziele festlegenWeiterführend