Nicht jede Anwendung gehört in die Public Cloud. Eine Maschinensteuerung, die im Millisekundenbereich antworten muss, ein Warenwirtschaftssystem mit großen lokalen Datenbeständen, ein Fachverfahren mit strengen Vorgaben zur Datenhoheit – solche Workloads laufen aus guten Gründen dort, wo sie entstehen: im eigenen Haus. Latenz, Kontrolle über die Daten und die Kostenstruktur bei konstanter Last sprechen dann klar für den Server vor Ort.
Das Problem ist nicht der lokale Server. Das Problem ist der lokale Server als einziger Ort. Ein Serverraum an einem Standort ist eine Single-Point-of-Failure-Konstruktion – gegen Brand, Wasserschaden, Diebstahl, Stromausfall und, längst der häufigste Fall, gegen einen Angreifer, der das gesamte Netz gleichzeitig verschlüsselt. Wer die Vorteile des lokalen Betriebs behalten will, ohne dessen Fragilität in Kauf zu nehmen, kommt an einer Frage nicht vorbei: Was passiert, wenn dieser eine Raum morgen nicht mehr da ist?
Die falsche Alternative: entweder vor Ort oder Cloud
Die verbreitete Erzählung lautet, man müsse sich entscheiden – Rechenzentrum oder eigener Serverraum, Cloud oder On-Premises. Das ist eine falsche Alternative. Der lokale Betrieb löst reale Anforderungen an Latenz und Datenhoheit, die eine reine Cloud-Migration nicht wegdiskutiert. Umgekehrt löst das externe Rechenzentrum das Standortrisiko, das ein reiner Vor-Ort-Betrieb strukturell nicht abdeckt. Beide Seiten sind für unterschiedliche Aufgaben stark.
Die tragfähige Antwort ist kein Entweder-oder, sondern eine Arbeitsteilung: Die Produktivsysteme laufen dort, wo sie hingehören – vor Ort. Ihre Sicherung und ein Wiederanlaufpfad liegen dort, wo sie ein lokales Ereignis überleben – im geografisch getrennten Rechenzentrum. Wir nennen das die hybride Brücke: lokaler Betrieb und externe Wiederanlauffähigkeit als ein durchgängiges Betriebsmodell, nicht als zwei getrennte Verträge.
Was lokal bleibt – und was repliziert wird
Die Aufteilung folgt keiner Ideologie, sondern der Frage, wo eine Workload ihren Nutzen entfaltet und wo eine Kopie im Ernstfall gebraucht wird.
Lokal bleibt der produktive Betrieb. Alles, was von kurzen Wegen und niedriger Latenz profitiert oder große Datenmengen ständig im Zugriff braucht, läuft auf dem Server im Haus: Virtualisierungshosts, Datei- und Datenbankdienste, Fachanwendungen, Maschinen- und Standortnähe. Hier zählt Antwortzeit, hier zählt volle Kontrolle über den physischen Standort der Daten.
Repliziert wird die Wiederherstellbarkeit. In das externe Rechenzentrum wandert nicht der Produktivbetrieb, sondern seine Absicherung: konsistente Sicherungspunkte der virtuellen Maschinen und der Daten – als replizierte Kopie außer Haus, geografisch getrennt vom Original. Damit ist die letzte Kopie nie nur an einem Ort, und der Wiederanlauf hängt nicht an genau dem Gebäude, das der Vorfall getroffen hat.
Dass mindestens eine Kopie zusätzlich unveränderbar liegen muss, damit sie einen Angreifer mit Administratorrechten überlebt, ist die zweite Bedingung. Wie Immutability und die erweiterte 3-2-1-1-0-Regel technisch funktionieren, haben wir an anderer Stelle ausführlich beschrieben; für dieses Betriebsmodell genügt der Merksatz: Die replizierte Kopie im Rechenzentrum ist nur dann eine echte Rückfalloption, wenn sie sich weder vom kompromittierten Netz aus löschen noch verändern lässt.
Der eigentliche Gewinn: zentraler Wiederanlauf
Eine Sicherungskopie außer Haus ist Voraussetzung, aber noch nicht der ganze Wert. Entscheidend ist, was im Ernstfall mit dieser Kopie geschieht.
Fällt der lokale Serverraum aus – gleich ob durch Brand, Hardware-Totalschaden oder Verschlüsselung – lassen sich die Dienste aus der replizierten Kopie zentral im Rechenzentrum wieder anfahren, während die Umgebung vor Ort in Ruhe wiederhergestellt wird. Das entkoppelt zwei Uhren, die sonst gnadenlos gekoppelt sind: die Zeit bis der Betrieb wieder läuft und die Zeit bis der Serverraum wieder steht. Ohne diese Brücke wartet das Geschäft auf die Reparatur der Hardware. Mit ihr laufen die kritischen Dienste zentral weiter, und die Wiederherstellung vor Ort wird von einem Notfall zu einer geplanten Arbeit.
Genau hier liegt der Unterschied zwischen „wir haben ein Backup“ und „wir kommen wieder hoch“. Ein Backup, das im selben brennenden Raum liegt, beantwortet die zweite Aussage nicht.
RTO und RPO: die Zahlen vor der Technik
Wie schnell und mit welchem Datenstand ein Dienst wieder laufen muss, ist eine Geschäftsentscheidung, keine technische. Zwei Kennzahlen machen sie besprechbar:
- RTO (Recovery Time Objective) – wie lange darf ein Dienst nach einem Ausfall stehen? Minuten, Stunden, ein Arbeitstag?
- RPO (Recovery Point Objective) – wie viel Datenverlust ist verkraftbar? Der Stand von vor einer Stunde, von letzter Nacht, vom Wochenende?
Diese Werte fallen je Dienst unterschiedlich aus – und das ist der Punkt, an dem die hybride Brücke ihr Geld verdient. Ein ERP-System mit RTO von zwei Stunden und RPO von 15 Minuten braucht häufige Replikation und einen vorbereiteten Wiederanlauf im Rechenzentrum. Ein Archiv, das einmal täglich gesichert einen Tag Rückstand verträgt, braucht das nicht. Wer für alles den strengsten Wert ansetzt, zahlt für Reserven, die niemand braucht; wer für alles den lockersten ansetzt, entdeckt die Lücke erst im Vorfall. Die saubere Reihenfolge lautet: erst die Prozesse priorisieren und ihre RTO/RPO-Ziele festlegen, dann Replikationsfrequenz und Wiederanlaufpfad danach dimensionieren.
Und weil ein Wiederanlaufplan ohne Beleg nur eine Behauptung ist, gehört zur hybriden Brücke der geübte Ernstfall: Wiederherstellungen werden getestet, nicht angenommen. Der strukturierte Rahmen dafür – von der Prozesspriorisierung bis zum dokumentierten Notfallplan – gehört in ein durchdachtes Business-Continuity-Konzept und nicht in ein Bauchgefühl.
Ein Betriebsmodell, kein Produkt
Der Reiz dieser Architektur liegt darin, dass sie nichts erzwingt, was der Betrieb nicht ohnehin braucht. Die Server stehen dort, wo Latenz und Datenhoheit es verlangen. Die Absicherung liegt dort, wo ein Standortereignis sie nicht erreicht. Und die Zuordnung ist nicht in Stein gemeißelt: Ändert sich die Anforderung – eine Workload wird cloud-tauglich, eine andere muss aus Compliance-Gründen zurück ins Haus – verschiebt sich die Grenze, ohne dass das Modell neu erfunden werden muss. Wichtig ist nur, dass die replizierte Kopie und der zentrale Wiederanlaufpfad von Anfang an mitgeplant sind und nicht als teure Nachrüstung nach dem ersten Ausfall entstehen.
Wie sector7 unterstützt
Wir planen, beschaffen und betreiben Server, Storage und Virtualisierung direkt bei Ihnen vor Ort – als HPE-Partner zu Partnerkonditionen, bei begründetem Bedarf auch Dell, Fujitsu oder Spezialsysteme auf Anfrage. Die Sicherung setzen wir Veeam-basiert um und replizieren sie in unseren eigenen, geografisch redundanten Serverpark in Deutschland – damit die letzte Kopie nie nur an einem Ort liegt und Dienste im Ernstfall zentral wieder anlaufen, während wir Ihre Umgebung vor Ort wiederherstellen. Neue Systeme laufen dokumentiert in unserem NOC-Monitoring rund um die Uhr mit. Als inhabergeführtes Haus aus Solingen, herstellerzertifiziert für Juniper, Cisco, HPE, F5, Fortinet und Palo Alto Networks, verbinden wir lokale Nähe und Rechenzentrum aus einer Hand. Wie wir Ihre Infrastruktur vor Ort aufbauen und absichern, beschreiben wir auf unserer Seite Server & Backup vor Ort.