Backup-Strategien zwischen On-Prem und Cloud: Kosten-Nutzen-Entscheidung für CIOs

Die Diskussion um Backup-Strategien zwischen On-Prem und Cloud wird in vielen Unternehmen erst dann konkret, wenn es knallt: Ransomware, Storage-Ausfall, versehentlich gelöschte Daten oder ein Audit mit unangenehmen Fragen. Für CIOs und IT-Leitungen ist Backup dabei keine rein technische Disziplin, sondern eine Kosten-Nutzen-Entscheidung mit direkter Wirkung auf Betriebsfähigkeit, Haftungsrisiken, Lieferfähigkeit und Verhandlungsmacht gegenüber Providern.

Wer heute „Cloud“ sagt, meint oft automatisch „weniger Aufwand“. In der Praxis verschiebt sich der Aufwand: weg von Hardwarebeschaffung und Medienrotation, hin zu Datenklassifizierung, Netzwerk- und Identitätskontrollen, laufender Kostenkontrolle, Exit-Planung und – entscheidend – sauberer Restore-Fähigkeit. Dieser Beitrag bietet eine strukturierte Entscheidungslogik, die Sie als Management- und Governance-Thema führen können: mit klaren Optionen, Kostenblöcken, Risiken, Verantwortlichkeiten und auditfähigen Nachweisen.

Backup-Strategien zwischen On-Prem und Cloud in der Praxis

Backups sind dann gut, wenn sie nachweisbar wiederherstellen. Alles andere ist Archivierung oder Datenhaltung – beides wichtig, aber nicht identisch mit Business Continuity. Der Schlüssel ist, Anforderungen in RTO und RPO zu übersetzen:

• RTO (Recovery Time Objective): Wie schnell muss ein Service wieder laufen, damit der Geschäftsbetrieb nicht untragbar leidet?
• RPO (Recovery Point Objective): Wie viel Datenverlust (Zeitfenster) ist maximal akzeptabel, gemessen an der letzten konsistenten Sicherung?

Diese zwei Kennzahlen bestimmen die Architektur stärker als jede Produktwahl. Ein 24-Stunden-RTO erlaubt andere Verfahren (z. B. Band-Offsite) als ein 2-Stunden-RTO (z. B. Snapshot-basierte Replikation plus schnelle Restore-Pipelines). In Audits ist genau diese Nachvollziehbarkeit zentral: Warum ist eine Methode „angemessen“, und wie wird die Einhaltung regelmäßig geprüft?

Entscheidungsrahmen für CIOs: Drei Zielkonflikte sauber auflösen

Die meisten Organisationen scheitern nicht an „Technik“, sondern an nicht explizit entschiedenen Zielkonflikten. Für eine belastbare Kosten-Nutzen-Entscheidung sollten Sie drei Spannungsfelder dokumentiert auflösen:

1) Sicherheit vs. Bedienbarkeit (Ransomware-Realität)

Ransomware-Akteure zielen gezielt auf Backups, Admin-Konten und Backup-Kataloge. „Gute“ Backups brauchen daher nicht nur Verschlüsselung, sondern Manipulationsschutz (immutable, WORM) und Trennung von Identitäten (separate Accounts/Keys, getrennte Admin-Pfade). Jede Vereinfachung im Betrieb kann eine Angriffsfläche öffnen.

2) Kostenplanbarkeit vs. Elastizität

On-Prem ist typischerweise kapital- und lifecycle-getrieben (CapEx + Abschreibung, Wartung, Strom/Fläche). Cloud ist nutzungsgetrieben (OpEx), aber mit variablen Komponenten: Speicherklasse, API-Requests, Indexierung, Egress (Datenabfluss), Cross-Region-Replikation. Kostenplanbarkeit ist machbar, aber nur mit Governance (Budgets, Tags, Quotas, Reports).

3) Compliance/Datenresidenz vs. Betriebsführung

Regulatorische Anforderungen (z. B. Aufbewahrung, Nachvollziehbarkeit, Zugriffskontrolle) kollidieren oft mit „einfacher“ Backup-Praxis. Datenresidenz bedeutet nicht nur „Region auswählen“, sondern auch: Wer hat Zugriff? Wo liegen Schlüssel? Welche Subunternehmer sind beteiligt? Wie wird ein Exit nachgewiesen? Diese Fragen müssen in Beschaffung, Security und Betrieb zusammenspielen.

Optionen im Vergleich: On-Prem, Cloud, Hybrid – und wann welche Variante sinnvoll ist

On-Prem-Backup: Kontrolle, aber volle Betriebslast

On-Prem-Backups (lokales Backup-Repository, ggf. zweites Rechenzentrum oder Band) liefern maximale Kontrolle über Datenpfade und Latenzen. Typische Stärken:

• Geringe Restore-Latenz im lokalen Netz, insbesondere für große Datenmengen (VM-Images, File-Server).
• Klare Datenhoheit (physische Kontrolle, eigene Schlüsselverwaltung, eigener Zugriffspfad).
• Kostenprofil häufig gut planbar, wenn Lifecycle und Kapazitätsplanung reif sind.

Typische Schwächen, die in der Praxis schmerzen:

• Offsite ist aufwendig: Medienhandling, Transport, Lagerung, zweite Site, oder WAN-Replikation.
• Skalierung erfordert Vorinvestitionen; Kapazitätsspitzen sind teuer.
• Ransomware-Risiko: Wenn Backup-Server und Storage in derselben Identitäts- und Netzwerkdomäne hängen, ist das Backup oft „mitkompromittiert“.

Cloud-Backup: Offsite by default, aber neue Kosten- und Kontrollthemen

Cloud-Backups (Object Storage, Cloud-Backup-Services oder eigene Backup-Repositories in der Cloud) sind für Offsite sehr attraktiv. Stärken:

• Physische Trennung vom eigenen Rechenzentrum, gut für Standortausfälle.
• Skalierung ohne Vorlauf; Speicher wächst mit Bedarf.
• Immutable-Optionen (z. B. Object-Lock/WORM-Mechanismen) sind oft technisch sauber umsetzbar.

Schwächen und typische Fallstricke:

• Restore-Kosten und -Zeit: Große Restores können durch Bandbreite und Egress teuer und langsam werden.
• Komplexere Governance: Identity & Access Management (IAM), Schlüsselverwaltung, Logging, Provider-Rollen, Mandantentrennung.
• Exit-Risiko: Datenrückführung und Providerwechsel müssen realistisch geplant und getestet werden.

Hybrid-Backup: Praxisstandard, aber nur mit klaren Regeln

In vielen Umgebungen ist Hybrid (lokal schnell + cloud/offsite robust) der beste Kompromiss. Typisches Muster: schnelle lokale Backups (für operative Wiederherstellung), plus cloudbasiertes Offsite mit Immutability (für Desaster und Ransomware). Der Gewinn entsteht aber nur, wenn Sie sauber entscheiden:

• Welche Workloads dürfen ausschließlich lokal gesichert werden (z. B. Latenz, Datenklassifizierung)?
• Welche müssen zwingend Offsite/immutable sein (z. B. kritische ERP-/Produktion-Daten)?
• Wie wird verhindert, dass derselbe Admin-Pfad sowohl Produktion als auch Backup zerstören kann?

Kosten-Nutzen sauber rechnen: Welche Kostenblöcke CIOs oft übersehen

Eine belastbare Entscheidung braucht ein Kostenmodell, das die Realität abbildet – nicht nur „Speicherpreis pro TB“. Praktisch bewährt ist eine Aufteilung in direkte, indirekte und Risiko-/Folgekosten.

Direkte Kosten (Budget sichtbar)

• Speicher: On-Prem (Disk/Band/Objektspeicher), Cloud (Speicherklasse, Replikation).
• Backup-Software/Subscriptions: Lizenzen, Agents, Kapazitätsmetriken.
• Netzwerk: WAN-Anbindung, VPN/Direct Connect, ggf. zweite Leitung.
• Compute für Restore/Validation: Test-Umgebungen, Wiederanlauf in der Cloud, Restore-Fenster.

Indirekte Kosten (Personal, Zeit, Prozess)

• Betriebsaufwand: Patching, Monitoring, Kapazitätsmanagement, Medienrotation, Störungsbehebung.
• Change-Management: neue Anwendungen, neue Datenquellen, neue Policies, neue Zugriffsrollen.
• Audit- und Nachweisaufwand: Protokolle, Reports, Restore-Nachweise, Dokumentation.

Risiko- und Folgekosten (CIO-relevant, oft nicht im IT-Topf)

• Produktionsausfall (Umsatz, Vertragsstrafen, Lieferverzug).
• Datenverlust (Rekonstruktion, Nacharbeit, rechtliche Folgen).
• Reputationsschaden und Eskalation bis Vorstand/Aufsicht.
• Ransomware-Verhandlungsmacht: Ohne nachweislich sauberes, isoliertes Backup steigt der Druck massiv.

Für die Kosten-Nutzen-Entscheidung empfiehlt sich ein Format, das auch im Risiko-Committee trägt: „Kosten pro erreichter RTO/RPO-Klasse“ plus „Rest-Risiko“ (welche Szenarien bleiben trotz Backup kritisch?).

Governance und Verantwortlichkeiten: Wer entscheidet was – und wer unterschreibt?

Backup ist eine Querschnittsaufgabe. Wenn Verantwortlichkeiten nicht klar sind, entsteht ein gefährlicher Zustand: technisch betrieben, aber geschäftlich nicht legitimiert. Bewährt ist eine klare Zuordnung:

• Service Owner (Fach/IT): definiert Business-Kritikalität, akzeptierbares RTO/RPO, Datenklassifizierung.
• IT-Betrieb: setzt Verfahren um, betreibt Monitoring, führt Restore-Tests aus, pflegt Runbooks.
• Security: definiert Mindestkontrollen (Immutability, MFA, Segmentierung, Schlüssel, Logging), prüft Angriffsflächen.
• Compliance/Datenschutz: prüft Aufbewahrung, Zugriff, Löschkonzepte, Datenresidenz, Drittlandthemen.
• CIO/IT-Leitung: entscheidet Zielniveau, Budgetrahmen, akzeptiertes Restrisiko, Providerstrategie.

Für Audits zählt nicht, dass „jemand“ sich kümmert, sondern dass es ein nachvollziehbares Betriebsmodell gibt: Policies, Ausnahmen, Review-Zyklen und evidenzbasierte Tests.

Audit-Perspektive: Welche Nachweise Sie in der Praxis brauchen

Ob interne Revision, externer Prüfer oder Kundenfragebogen: Es wiederholen sich typische Prüfpunkte. Wenn Sie diese systematisch abdecken, wird Backup vom Bauchgefühl zur nachweisbaren Fähigkeit.

Nachweise, die fast immer gefragt werden

• Backup-Policy: Scope, Frequenz, Aufbewahrung, Verantwortlichkeiten, Verschlüsselung, Offsite.
• Systeminventar / Datenlandkarte: Welche Systeme sind gesichert, welche nicht, und warum?
• Restore-Tests: Protokolle, Ergebnisse, Abweichungen, Maßnahmen (inkl. Nachtest).
• Zugriffs- und Schlüsselkonzept: wer darf Backups löschen, wer darf restore ausführen, wie wird das protokolliert?
• Ransomware-Resilienz: immutable/air-gapped Anteile, getrennte Identitäten, Notfallzugänge.
• Exit-Plan (bei Cloud): Datenrückführung, Fristen, Kostenannahmen, technische Schritte.

Regulatorische Einordnung (ohne Paragraphenreiterei)

Unabhängig vom konkreten Regelwerk (branchenspezifisch, Kundenanforderungen, interne Governance) läuft es auf dieselben Kernprinzipien hinaus: Verfügbarkeit, Integrität, Vertraulichkeit, Nachvollziehbarkeit und angemessene Kontrollen. Entscheidend ist, dass Sie „angemessen“ mit Ihrem Schutzbedarf begründen: Kritische Systeme bekommen strengere RTO/RPO-Ziele, stärkere Isolation und häufigere Tests.

Technische Leitplanken, die Entscheidungen vereinfachen

Die konkrete Produktauswahl ist nachrangig, wenn Leitplanken stimmen. Folgende Mechanismen sind für den Betrieb besonders relevant:

Immutability und Air-Gap: zwei unterschiedliche Schutzmechanismen

Immutable Backups sind technisch gegen nachträgliche Änderung/Löschung geschützt (WORM-ähnlich). Das schützt stark gegen „Admin löscht alles“, aber nicht zwingend gegen alle Szenarien (z. B. Fehlkonfiguration vor dem Lock, kompromittierte Schlüsselverwaltung, oder Katalog-Manipulation). Ein Air-Gap bedeutet eine operative Trennung: Backups sind zeitweise oder dauerhaft nicht aus dem Produktivnetz erreichbar. Air-Gap kann physisch (Band), logisch (separates Netz/Account) oder organisatorisch (getrennte Rollen, getrennte Credentials) umgesetzt werden. In der Praxis sind Kombinationen am wirksamsten.

Verschlüsselung: at rest, in transit, und Schlüsselhoheit

„Verschlüsselt“ ist ohne Kontext wertlos. Prüfen Sie drei Ebenen: Transportverschlüsselung (in transit), Speicherung (at rest) und Key Management (wer kontrolliert die Schlüssel, wie wird Rotation/Notfallzugang geregelt). Für Compliance zählt außerdem die Protokollierung von Schlüsselzugriffen und das Vier-Augen-Prinzip für besonders kritische Aktionen.

Netzwerk und Identity: der unterschätzte Teil von Cloud-Backups

Viele Restore-Desaster sind keine Datenprobleme, sondern Netzwerk- und Identitätsprobleme: fehlende Routen, gesperrte Ports, abgelaufene Credentials, falsche Rollen. Wenn Backup in die Cloud geht, muss die Wiederherstellung inklusive der notwendigen Netzwerkpfade, DNS-Abhängigkeiten und IAM-Rollen getestet werden. Sonst testen Sie nur „Daten kopieren“, nicht „Service wiederherstellen“.

Entscheidungsmatrix: Welche Workloads wohin gesichert werden

Eine CIO-taugliche Matrix basiert nicht auf Technologie, sondern auf Workload-Eigenschaften. Nutzen Sie folgende Kriterien als standardisierte Vorlage:

• Kritikalität: Umsatz-/Sicherheits-/Reputationswirkung bei Ausfall
• Datenänderungsrate: beeinflusst RPO und Übertragungsvolumen
• Datenvolumen: beeinflusst Restore-Zeit und Egress-Kosten
• Abhängigkeiten: Datenbank + Files + Konfiguration + Secrets müssen gemeinsam konsistent sein
• Compliance: Aufbewahrung, Löschpflichten, Datenresidenz, Zugriffsprotokolle
• Bedrohungsmodell: Zielwert für Immutability/Air-Gap, getrennte Admin-Pfade

Typische Zuordnungen (als Startpunkt, nicht als Dogma):

• Tier-1 (kritisch): lokal schnelle Restore-Möglichkeiten + offsite immutable + regelmäßige Restore-Übungen
• Tier-2 (wichtig): lokal oder cloud, je nach Datenvolumen; offsite Pflicht, Immutability empfohlen
• Tier-3 (unterstützend): kosteneffiziente Sicherung, längere RTO/RPO, aber dennoch nachweisbare Restore-Fähigkeit

Restore-Tests als Steuerungsinstrument: Wie Sie „0“ in 3-2-1-1-0 erreichen

Die bekannte 3-2-1-Regel (drei Kopien, zwei Medien, eine Offsite) wird heute oft als 3-2-1-1-0 erweitert: zusätzlich eine immutable/offline Kopie und 0 Fehler in verifizierten Restore-Tests. Der „0“-Teil ist die Management-relevante Komponente: Sie brauchen nicht perfekte Backups, sondern einen Prozess, der Fehler findet, priorisiert und schließt.

Was Restore-Tests in der Praxis abdecken müssen

• Datei-Restore (operative Fälle): einzelne Dateien, Berechtigungen/ACLs, Versionsstände
• Applikations-Restore: Datenbank + Applikationsdaten konsistent, Startreihenfolge, Konfigurationsstände
• System-Restore: VM/Server, Bootfähigkeit, Treiber, Netzwerk
• Desaster-Szenario: Wiederanlauf aus Offsite/Cloud inkl. IAM, Netzwerk, DNS, Secrets

Wichtig für die Auditfähigkeit: Jeder Test braucht Datum, Scope, Ergebnis, Abweichungen, Ticket-Referenz und Nachtest. Damit wird Backup „prüfbar“ statt „behauptet“.

Praktische Checklisten und Vorlagen (auditfest nutzbar)

Checkliste 1: Cloud-Backup-Risiken vor Freigabe

• Ist das RTO/RPO je Service beschlossen und dokumentiert?
• Gibt es getrennte Identitäten für Backup (separater Account/Mandant/Subscription) und sind Admin-Rechte minimiert?
• Sind Immutability-Mechanismen aktiviert und gegen Fehlkonfiguration abgesichert (z. B. Governance-Lock, getrennte Rolle)?
• Ist Key Management geklärt (Rotation, Notfallzugang, Protokollierung)?
• Wurden Restore-Kosten (Egress, temporärer Compute) im Budgetmodell berücksichtigt?
• Existiert ein Exit-Plan mit technischen Schritten und Zeit-/Kostenannahmen?
• Gibt es Monitoring für Backup-Failures, Aufbewahrungs-Policy-Drift und Immutability-Status?

Checkliste 2: On-Prem-Backup-Risiken vor Freigabe

• Ist Offsite so umgesetzt, dass Standortausfall und Domänenkompromittierung abgedeckt sind?
• Gibt es Netzwerksegmentierung (Backup-Netz) und getrennte Admin-Pfade?
• Sind Backups gegen Löschung/Manipulation geschützt (WORM/immutable oder offline Medien)?
• Ist Kapazitätsplanung inkl. Wachstum und Aufbewahrung belastbar (keine „stille Kürzung“ der Retention)?
• Werden Restore-Tests durchgeführt und operativ nachverfolgt?

Vorlage: Minimal-Backup-Policy (Inhaltsstruktur)

Folgende Gliederung hat sich bewährt, um eine Policy kurz, aber prüfbar zu halten:

• Scope und Begriffe (Backup vs. Archiv, RTO/RPO, Offsite, immutable)
• Service-Klassifizierung (Tier-Modell) und Verantwortlichkeiten
• Backup-Frequenzen, Aufbewahrung, Medien/Targets (On-Prem/Cloud)
• Sicherheitskontrollen (MFA, Rollen, Schlüssel, Segmentierung, Logging)
• Restore-Tests (Frequenz, Umfang, Nachweise, Eskalation)
• Ausnahmenprozess (Genehmigung, Laufzeit, Kompensationsmaßnahmen)
• Review-Zyklus (z. B. halbjährlich) und Reporting an IT-Leitung/Risiko-Committee

Konkrete, kopierbare Beispielartefakte (Policies & Prüfschritte)

Die folgenden Source-Blöcke sind bewusst generisch gehalten, um als Startpunkt für interne Standards zu dienen. Sie ersetzen keine Detailkonfiguration, helfen aber bei der auditfesten Formulierung.

# Beispiel: Backup-Kontrollanforderungen (Kurzstandard)
# Zweck: Mindestkontrollen für alle kritischen Services (Tier-1)

- Es existieren mindestens zwei administrative Rollen:
  (1) Backup-Operator (Restore/Job-Management)
  (2) Backup-Security-Admin (Retention/Immutability/Policy-Änderungen)

- Backups werden verschlüsselt übertragen und verschlüsselt gespeichert.
  Schlüsselverwaltung: dokumentiert, rotierbar, Zugriffe protokolliert.

- Mindestens eine Kopie ist gegen Löschung/Manipulation geschützt (immutable oder offline).

- Restore-Tests:
  - monatlich: Stichprobe File/DB-Restore
  - quartalsweise: Applikations-Restore in isolierter Testumgebung
  - jährlich: Desaster-Szenario aus Offsite inkl. Netzwerk/IAM

- Nachweisführung:
  - jeder Test erzeugt ein Ticket mit Ergebnis, Abweichungen, Maßnahmen, Nachtest.

# Beispiel: Audit-Fragenkatalog (Auszug)

1) Welche Systeme sind NICHT im Backup-Scope? Wer hat das Restrisiko genehmigt?
2) Wie wird verhindert, dass ein kompromittiertes Domain-Admin-Konto Backups löscht?
3) Wo ist die letzte erfolgreiche Wiederherstellung eines Tier-1-Services dokumentiert?
4) Wie wird die Einhaltung der Aufbewahrungsfristen technisch erzwungen?
5) Wie sieht der Exit-Plan aus der Cloud aus (Datenrückführung, Kosten, Zeit)?

# Beispiel: Restore-Runbook-Struktur (ohne Produktbezug)

- Auslöser/Incident-Typ (Ransomware, Hardware-Defekt, Fehlbedienung, Standortausfall)
- Entscheidungsbaum: lokal restore vs. offsite restore vs. neu bereitstellen + restore
- Abhängigkeiten: DNS, Zertifikate, Secrets, IAM-Rollen, Netzwerksegmente
- Reihenfolge: DB -> Middleware -> Applikation -> Batch/Jobs -> Schnittstellen
- Validierung: Datenkonsistenz, Benutzerrechte, Transaktionsstände
- Kommunikation: Stakeholder, Zeitlinien, Dokumentation für Audit/Nachbereitung

Typische Fehlentscheidungen – und wie Sie sie vermeiden

„Wir sind in der Cloud, also ist das Backup erledigt“

Cloud-SLAs ersetzen kein Backup. Viele Plattformdienste bieten Redundanz, aber nicht zwingend point-in-time Wiederherstellung, lange Aufbewahrung oder Schutz gegen logische Fehler (Fehlkonfiguration, Löschung, Ransomware über kompromittierte Konten). Klären Sie explizit: Welche Daten sind durch Provider-Mechanismen abgedeckt, welche nicht?

„Wir haben Offsite, also sind wir sicher“

Offsite ohne Immutability und ohne getrennte Identitäten kann im Angriff genauso fallen wie das On-Prem-Repository. Entscheidend ist die Trennung der Macht: Wer Produktion administriert, darf nicht automatisch Backups zerstören können.

„Wir testen Restore nur einmal im Jahr“

Ein jährlicher Test ist besser als keiner, aber operativ häufig zu selten: Personalwechsel, Versionssprünge, neue Abhängigkeiten, neue Keys – all das führt zu stillen Restore-Fehlern. Sinnvoller ist ein gestuftes Modell: häufige kleine Tests plus seltene große Desaster-Übungen.

Empfohlener Umsetzungsplan in 6 Schritten (90-Tage-fähig)

Für CIOs ist wichtig, dass es eine umsetzbare Sequenz gibt, die schnell Risiken senkt und gleichzeitig Governance aufbaut.

1. Scope & Tiering: Services klassifizieren, RTO/RPO je Tier festlegen, Ausnahmen genehmigungspflichtig machen.
2. Zielarchitektur: On-Prem/Cloud/Hybrid pro Tier entscheiden, Offsite/Immutability als Mindeststandard für Tier-1.
3. Identity & Separation: getrennte Rollen, MFA, getrennte Accounts/Subscriptions, Logging verpflichtend.
4. Retention & Kostenmodell: Aufbewahrung technisch erzwingen, Kostenblöcke (inkl. Restore/Egress) in Reporting aufnehmen.
5. Restore-Tests operationalisieren: Testkalender, Runbooks, Evidence (Tickets/Reports), Eskalationspfade.
6. Audit-Readiness: Policy finalisieren, Nachweise bündeln, regelmäßige Reviews (z. B. halbjährlich) im Risiko-Committee.

Schlussfazit: Die beste Backup-Strategie ist die, die Sie regelmäßig wiederherstellen können

Die Kosten-Nutzen-Entscheidung zwischen On-Prem und Cloud ist keine Glaubensfrage, sondern eine Frage von Zielwerten (RTO/RPO), Bedrohungsmodell (Ransomware), Governance (Rollen, Kontrollen, Nachweise) und einem Kostenmodell, das Restore-Realität und Exit-Fähigkeit einpreist. In der Praxis ist Hybrid oft der tragfähigste Pfad: lokal schnell für den Alltag, cloud/offsite robust und immutable für den Ernstfall. Entscheidend ist, dass Sie Backups als wiederholbaren Prozess mit Tests, Verantwortlichkeiten und auditfähigen Evidenzen führen – dann wird Backup von „Versicherung auf dem Papier“ zu gelebter operativer Resilienz.

Für dieses Thema sind auch Offsite-Backup wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.