Illustration Absmeier foto freepik

Cyberresilienz entscheidet sich nicht beim Backup, sondern bei der Wiederherstellung. Angesichts von Ransomware, kompromittierten Identitäten und komplexen Cloud‑Abhängigkeiten müssen Unternehmen ihre Backup‑Strategie konsequent auf messbare Recovery‑Ergebnisse ausrichten. Dieser Beitrag zeigt, wie eine architekturgetriebene Enterprise‑Backup‑Strategie Wiederherstellbarkeit, Sicherheit und Resilienz systematisch in den Mittelpunkt stellt.

Die Enterprise-Backup-Strategie hat sich weit über ihre traditionelle Rolle als operative Absicherung hinaus entwickelt. In modernen digitalen Unternehmen bildet die Backup-Architektur eine zentrale Grundlage für Business Continuity, Cyberresilienz, regulatorische Compliance sowie Incident Response.

Hardwareausfälle, Ransomware-Kampagnen, kompromittierte Zugangsdaten, Insider-Bedrohungen und regionale Cloud-Ausfälle haben den Schwerpunkt von der Backup-Erstellung hin zur verlässlichen Wiederherstellung verlagert.

Vor diesem Hintergrund muss die Backup-Strategie mit Blick auf ein zentrales Prinzip entwickelt werden: Wiederherstellung unter erschwerten Bedingungen. Ziel ist nicht die bloße Erzeugung von Sicherungskopien, sondern die deterministische und zeitgerechte Wiederherstellung, und das selbst bei bereits kompromittierten Systemen, Identitäten oder gar gesamten Trust-Domains.

Dieser Beitrag beschreibt einen strukturierten, auf die Architektur ausgerichteten Ansatz zur Entwicklung einer Enterprise Backup-Strategie, die Wiederherstellung-Ergebnisse, Resilienz sowie operative Validierung bewusst über die Entscheidungen zu eingesetzten Werkzeugen stellt.

Eine wirksame Enterprise Backup-Strategie wird durch die zu schützenden Geschäftsziele definiert und nicht durch die eingesetzte Software oder Speicherplattform. Vor der Produktauswahl sind vier Kernfragen zu klären:

Welche Daten und Systeme sind geschäftskritisch?

Nicht alle Workloads tragen dasselbe Risikoprofil. Kern-Datenbanken, umsatzrelevante Systeme, Identity-Plattformen und ERP-Umgebungen erfordern ein signifikant höheres Schutzniveau als Umgebungen in der Entwicklung oder Archivsysteme. Übertriebener Schutz erzeugt unnötige Kosten, vernachlässigter Schutz exponiert existenzielle Risiken.

Wie viel Datenverlust ist tolerierbar? (RPO)

Das Recovery Point Objective (RPO) definiert den maximal akzeptablen Datenverlust in Zeiteinheiten. Ein RPO von fünf Minuten erfordert kontinuierliche oder nahezu kontinuierliche Datensicherung mit hoher Ingest-Kapazität. Ein RPO von 24 Stunden hingegen erlaubt batch-orientierte Verfahren. Das RPO bestimmt die Sicherungsfrequenz, Anforderungen an die Bandbreite sowie die Speicherarchitektur.

Wie lange dürfen Systeme ausfallen? (RTO)

Das Recovery Time Objective (RTO) definiert die maximal zulässige Wiederherstellungsdauer. Dabei beeinflusst das RTO unmittelbar Restore-Durchsatz, die Fähigkeit zur Parallelisierung, die Storage-Performance und die Infrastruktur-Dimensionierung. Es handelt sich oft um die am stärksten unterschätzte Designlimitierung.

Wie wird Wiederherstellbarkeit nachgewiesen?

Der erfolgreiche Abschluss eines Backup-Jobs ist für sich genommen kein Beweis für die Wiederherstellbarkeit. Verifikation muss belegen, dass Systeme unter realistischen Lastbedingungen innerhalb definierter Zeitfenster wiederhergestellt werden können. Diese Anforderungen sind als messbare SLAs für jede Workload-Kategorie zu formalisieren. Die Architektur leitet sich rückwärts aus diesen SLAs ab.

Daten klassifizieren und RPO/RTO-Ziele zuordnen

Eine effektive Strategie startet mit der Klassifizierung: Ein Tier-basiertes Modell sorgt dafür, dass Ressourcen zum Schutz korrekt zugewiesen werden.

Tier 1 – Kritische Produktionssysteme
Beispiele: ERP, Zahlungsplattformen, Kundendatenbanken
RPO: Minuten
RTO: < Eine Stunde

Tier 2 – Wichtige Geschäftsanwendungen
Beispiele: Applikationsserver, VDI, E-Mail Plattformen
RPO: Stunden
RTO: Innerhalb eines Geschäftstags

Tier 3 – Fachbereichs-Daten, Daten zur Kollaboration
Beispiele: File Shares, Collaboration-Repositories
RPO: Täglich
RTO: Mehrere Tage

Tier 4 – Langzeitarchive
Beispiele: Compliance-Daten, abgeschlossene Projekte
RPO: Tage oder länger
RTO: Tage bis Wochen

Sicherungsfrequenz, Aufbewahrungsfristen und Restore-Infrastruktur müssen an diese Tiers individuell angepasst werden. Eine Gleichbehandlung aller Daten führt in der Regel zu höheren Kosten bei geringerer Leistung zur Wiederherstellung.

Bei sehr großen Datenvolumen in Langzeitarchiven stößt die traditionelle Vorgehensweise der Datensicherung und -wiederherstellung zunehmend an technische wie auch wirtschaftliche Grenzen. Vor diesem Hintergrund ist ein Umdenken hinsichtlich der Absicherung dieser Daten erforderlich. Die enorme Datenmenge führt dazu, dass vollständige Sicherungen und insbesondere eine zeitnahe Wiederherstellung oftmals nur noch mit erheblichem Aufwand oder gar nicht mehr möglich sind. Stattdessen rücken zunehmend Schutzmaßnahmen, die auf der Architektur basieren, in den Fokus. Zu nennen wären hier beispielsweise Objektspeicher-Plattformen mit revisionssicheren Funktionen, die Datenstände unveränderlich vorhalten, sowie standortübergreifende Redundanzverfahren wie Erasure Coding, mit denen sich Ausfälle gezielt absichern lassen.

In solchen Architekturen wird der Schutz der Daten primär durch die inhärente Resilienz der zugrunde liegenden Speicherplattform gewährleistet. Die Einschätzung hängt selbstverständlich immer vom Einzelfall ab, aber für diese Datenklassen erweisen sich klassische Sicherungs- und Wiederherstellungsprozesse häufig als weder erforderlich noch praktikabel.

Die 3-2-1-Regel für moderne Modelle der Bedrohung erweitern

Die klassische 3-2-1-Regel bleibt grundlegend:

Drei Datenkopien
Zwei unterschiedliche Speichermedien
Eine Offsite-Kopie

Dieses Modell adressiert Hardwareausfälle und lokale Störungen, setzt jedoch implizit voraus, dass administrative Strukturen des Vertrauens intakt bleiben. Moderne Angriffe kompromittieren häufig privilegierte Zugangsdaten vor der Ausbringung von Ransomware. Wenn alle Backup-Kopien derselben administrativen Trust-Domain unterliegen, bietet die reine geografische Trennung nur begrenzten Schutz.

Erweiterung zu 3-2-1-0:

Drei Datenkopien (Redundanz gegen Hardware) sowie Betriebsfehler
Zwei unterschiedliche Speichersysteme oder Technologien, Reduktion systemischer Risiken
Eine logisch isolierte Kopie außerhalb der primären Trust-Domain, Trennung der Control Plane
Keine Wiederherstellungsfehler, kontinuierlich überprüfte Integrität und Wiederherstellung

Ziel ist hierbei nicht die theoretische Perfektion, sondern die Eliminierung unbekannter Ausfallmodi vor dem Hintergrund eines realen Vorfalls.

Immutability auf der richtigen Kontrollebene durchsetzen

Immutability ist eine nicht verhandelbare Kontrollmaßnahme in Ransomware-resilienten Architekturen, allerdings ist nicht jede Implementierung gleichwertig.

Weiche Immutability:

Konfiguriert über UI oder Meta-Daten
Administrativ umkehrbar
Anfällig bei Credential-Kompromittierung

Erzwingbare (Hard) Immutability:

Beim Schreibvorgang angewendet
Auf der Speicherebene technisch durchgesetzt
Löschen oder Modifizieren selbst mit erhöhten Rechten ausgeschlossen

Für wirksamen Schutz gilt:

Durchsetzung auf API-Ebene
Aufbewahrungsfristen dürfen administrativ nicht verkürzt werden
Backup-Repositories dürfen keine Löschrechte mit Produktionssystemen teilen

Immutability muss eine echte technische Grenze darstellen und keine bloße Policy-Empfehlung.

Storage auf Wiederherstellung statt nur auf Retention ausrichten

Backup-Software orchestriert Jobs und verwaltet Metadaten. Die Speicherarchitektur bestimmt dabei die tatsächliche Fähigkeit zur Wiederherstellung. Zu bewerten sind dabei insbesondere:

Datenintegrität und Dauerhaftigkeit

Checksummen, Erasure Coding und Background Scrubbing zur Erkennung stiller Korruption von Daten.

Restore-Performance unter Parallelität

Massen-Wiederherstellungen legen Engpässe offen, die Einzel-Restores nicht zeigen.

Unabhängige Retention-Durchsetzung

Retention muss vom Speichersystem selbst erzwungen werden, unabhängig von der Backup-Logik.

Operative Skalierbarkeit

Kapazität und Durchsatz müssen skalieren, ohne die Architektur zu beeinträchtigen.

Objektspeicher als strategische Option

Viele Unternehmen setzen auf Objektspeicher als primäres Backup-Ziel aufgrund:

Nativem Scale-out-Design
Hoher Datenhaltbarkeit
API-basierter Immutability
Planbarer Wirtschaftlichkeit im Petabyte-Bereich

Objektspeicher ersetzt nicht zwangsläufig andere Tiers, schafft jedoch architektonische Unabhängigkeit sowie skalierbare Leistung zur Wiederherstellung.

Im Kontext moderner Anforderungen zur Sicherheit und Resilienz geht eine zeitgemäße Objektspeicher-Architektur jedoch deutlich über rein API-basierte Unveränderbarkeit hinaus. Ein Beispiel hierfür ist ein mehrschichtiges Sicherheitsmodell (Scality CORE5). Neben der Immutability auf API-Ebene wird der Schutz der Daten konsequent bis in den Daten- und Storage-Layer erweitert.

Dazu zählt eine durchgehende Verschlüsselung sowohl der übertragenen Daten (Data in Flight) als auch der gespeicherten Daten (Data at Rest), wodurch der Schutz während der Übertragung ebenso wie im Ruhezustand gewährleistet ist. Auf Speicherebene sorgt zusätzlich Erasure Coding nicht nur für eine hohe Haltbarkeit der Daten und eine effiziente Wiederherstellbarkeit, sondern erhöht darüber hinaus insgesamt auch die Sicherheit gegenüber potenzieller Exfiltration von Daten.

Da Daten dabei in kodierte Fragmente (Chunks) aufgeteilt und verteilt gespeichert werden, besitzen einzelne Fragmente außerhalb des definierten Erasure-Coding Schemas keinen verwertbaren Informationsgehalt. Selbst bei einem Angriff auf das Dateisystem oder aber im Fall eines physischen Diebstahls von Datenträgern bleiben isolierte Fragmente wertlos, da eine Rekonstruktion der Daten ohne Zugriff auf das vollständige, systeminterne Kodierungsschema sowie die notwendigen Quorum-Fragmente nicht möglich ist.

Ergänzt wird dieses Sicherheits- und Resilienzkonzept durch gezielte geografische Ausfallsicherheit. Diese kann über synchron gestreckte Cluster mit standortübergreifendem Erasure Coding oder aber über asynchrone Cross-Region Replication (CRR) realisiert werden. Dadurch lassen sich sowohl lokale Störungen in der Infrastruktur als auch regionale Ausfälle zuverlässig abfangen.

Schließlich wird eine solche Architektur idealerweise als gehärtete Software-Appliance bereitgestellt: ohne Root-Zugriff, mit konsistent gepatchten Software-Komponenten einschließlich Betriebssystem sowie einer stark reduzierten Angriffsfläche. Auf diese Weise entsteht eine integrierte Plattform, die in der Lage ist, Skalierbarkeit, Datenintegrität sowie Sicherheitsanforderungen gleichermaßen zu adressieren.

Architekturmuster risikoorientiert auswählen

Pattern A: Direkt auf unveränderlichen Objektspeicher
Backup schreibt direkt auf unveränderlichen Objektspeicher. Replikation sorgt für Standort-Redundanz. Geeignet für: große Datenmengen, moderate RTO-Anforderungen, Fokus auf Skalierung sowie operativer Einfachheit.
Pattern B: Performance-Tier und Immutable Capacity-Tier
Aktuelle Backups auf hochperformantem Speicher, sofortige Replikation auf unveränderlichem Objektspeicher. Geeignet für: niedrige RTOs, hohe Restore-Geschwindigkeit, lange Retention.
Pattern C: Logisch isolierte oder aber Air-Gapped Architektur
Trennung von Management- und Datenebene, restriktiver Netzwerkzugang, Retention außerhalb operativer Administrations-Kontrolle. Geeignet für: regulierte Branchen, Umgebungen der Hochsicherheit, erhöhte Insider-Risiken. Jedes Muster repräsentiert eine individuelle Mischung (Kosten, Komplexität, Sicherheit zur Wiederherstellung).

Kontinuierliche Validierung institutionalisieren

Eine nicht getestete Backup-Strategie versagt unter Druck.

Automatisierte Restore-Tests
Regelmäßige Wiederherstellung in isolierten Umgebungen inklusive Validierung der Applikationen.
Integritätsprüfung
Checksummen und Scrubbing zur frühzeitigen Erkennung von Korruption.
Messung der Performance
Messung des Restore-Durchsatzes unter parallelen Szenarien der Wiederherstellung.
Auditierbarkeit
Unveränderbare Protokolle aller Backup- und Restore-Vorgänge zur Compliance- und Forensik-Unterstützung. Validierung muss kontinuierlich und operativ verankert sein. Eine jährliche Compliance-Übung ist nicht ausreichend.

Umsetzung über eine strukturierte Roadmap

Tage 0–30: Analyse und Architektur-Design

Workload-Klassifizierung
Definition von RPO/RTO-Tiers
Identifikation von Lücken bei Immutability und Isolation
Auswahl geeigneter Architekturmuster

Tage 31–60: Härtung von Sicherheit und Kontrolle

Aktivierung von API-basierter Immutability
Verschlüsselung, granulare Kontrollen des Zugriffs
Einschränkung administrativer Rechte, Trennung von Trust-Domains

Tage 61–90: Validierung und Skalierung

Einführung automatisierter Restore-Tests
Messung realer Recovery-Performance
Implementierung einer zusätzlichen isolierten Kopie, bedarfsorientiert

Nach jeder Übung oder Incident-Simulation sind Annahmen zu überprüfen, Zugriffspfade zu härten sowie Modelle zur Kapazität anzupassen.

Vermeidbare Ausfallmuster erkennen

Häufige Designfehler:

Reversible oder rein Policy-basierte Unveränderlichkeit
Gleichsetzung von Backup-Erfolg mit Wiederherstellbarkeit
Unterdimensionierter Restore-Durchsatz
Geteilte administrative Trust-Domains mit Produktion
Single-Site- oder Single-Copy Architekturen

Die Vermeidung dieser Fehler steigert Resilienz häufig stärker als die bloße Einführung zusätzlicher Werkzeuge.

Von der Datensicherung zur messbaren Resilienz

Enterprise-Backup ist längst keine Übung in Sachen Speicheroptimierung mehr, sondern eine strategische Fähigkeit zur Resilienz. Eine wirksame Strategie plant für Wiederherstellung unter Bedingungen eines Ausfalls und nicht für den Backup-Erfolg im Normalbetrieb. Sie richtet die Architektur an messbaren SLAs aus, erzwingt Immutability auf der richtigen Kontrollebene, stellt die Unabhängigkeit des Speichers sicher und validiert Wiederherstellbarkeit kontinuierlich. Wenn Backup-Architektur konsequent am Geschäftsrisiko ausgerichtet und Wiederherstellung als getestete, auditierbare Fähigkeit verstanden wird, entsteht im Kontext klassischer Datensicherung tatsächliche und vorhersagbare Cyberresilienz.

Christoph Storzum, VP Sales Europe, Scality

Der Beitrag wurde in Teilen mit KI erstellt.

207 Artikel zu „Cyberresilienz Backup“

News | IT-Security | Strategien

Vier Säulen der Cyberresilienz

6. März 2026

Trotz langjähriger Investitionen in Abwehrmaßnahmen nehmen Cyberangriffe und kostspielige Ausfallzeiten weiter zu. Traditionelle Sicherheitsmethoden zur Bedrohungsprävention und -erkennung bleiben zwar nach wie vor relevant, doch unter CISOs zeigt sich eine Veränderung in der Herangehensweise. Viele erweitern ihr Aufgabengebiet, um zusätzlich die Leitung von Wiederherstellungsmaßnahmen nach Sicherheitsvorfällen zu übernehmen, damit ihr Unternehmen rasch wieder betriebsbereit ist.…