Backup und Disaster Recovery entlang von RPO und RTO planen

Die meisten Backup-Programme werden an dem Tag beurteilt, an dem sie gebraucht werden, und viele scheitern an diesem Tag aus Gründen, die lange vorher sichtbar waren: ein Job, der stillschweigend ein Volume auslässt, eine Datenbank, die mitten im Schreibvorgang kopiert wurde, eine Wiederherstellung, die über eine nie gemessene Leitung Tage dauert, oder Backups, die derselbe Angreifer verschlüsselt hat, der auch die Produktion verschlüsselt hat.

Dieser Leitfaden geht von diesen Zahlen aus, dem Recovery Point Objective (RPO) und dem Recovery Time Objective (RTO), und baut darauf auf: wie viele Kopien Sie vorhalten, wie Sie eine davon ransomwaresicher machen, wie Sie Datenbanken konsistent sichern, wie oft Sie nachweisen, dass Wiederherstellungen funktionieren, wie Sie Runbooks schreiben und wohin das Geld fließt.

Beginnen Sie mit RPO und RTO für jedes System

Das RPO gibt an, wie viel Datenverlust Sie sich leisten können, gemessen in Zeit. Ein RPO von 24 Stunden bedeutet, dass ein nächtliches Backup ausreicht. Ein RPO von 15 Minuten bedeutet kontinuierliches Log Shipping, Replikation oder sehr häufige Snapshots. Das RTO gibt an, wie lange ein System nicht verfügbar sein darf, gemessen vom Ausfall bis zu dem Zeitpunkt, an dem die Nutzer wieder arbeiten können.

Diese Zahlen sollten vom fachlichen Verantwortlichen jedes Systems kommen, nicht von der IT allein, und sie sollten schriftlich festgehalten werden. Systeme lassen sich meist in wenige Stufen einteilen:

• Tier 1. Umsatzrelevante und kundennahe Systeme wie Auftragsabwicklung, Zahlungen und zentrale Datenbanken. Typische Ziele: RPO von Minuten, RTO von 1 bis 4 Stunden.
• Tier 2. Interne Systeme, auf die Mitarbeitende täglich angewiesen sind, etwa ERP, Dateifreigaben, E-Mail und Ticketsysteme. Typische Ziele: RPO von 1 bis 4 Stunden, RTO von 8 bis 24 Stunden.
• Tier 3. Archive, Reporting-Replikate, Entwicklungs- und Testumgebungen. Typische Ziele: RPO von 24 Stunden, RTO von mehreren Tagen.
• Wiederaufbaubar. Zustandslose Server, die aus Code oder Images gebaut werden. Sichern Sie die Konfiguration und die Build-Pipeline, nicht die Server selbst.

Das RTO umfasst alles: das Erkennen des Ausfalls, die Entscheidung zur Wiederherstellung, den Zugriff auf das Backup-System, die Bereitstellung von Hardware, die Datenübertragung und die Validierung der Anwendung.

Die 3-2-1-Regel und ihre moderne Erweiterung

Die klassische 3-2-1-Regel besagt, drei Kopien Ihrer Daten vorzuhalten (Produktion plus zwei Backups), auf zwei verschiedenen Speichersystemen oder Medien, mit einer Kopie an einem externen Standort.

Viele Teams nutzen inzwischen 3-2-1-1-0: Eine Kopie ist offline oder unveränderlich, und Wiederherstellungen werden mit null Fehlern verifiziert. Die zusätzlichen Glieder gibt es, weil Ransomware-Betreiber erreichbare Backups suchen und löschen, bevor sie die Produktion verschlüsseln. Ein Backup, das ein Administratorkonto löschen kann, ist nur ein weiteres Ziel.

In der Praxis bedeuten „zwei Medien“ heute meist zwei unabhängige Speichersysteme statt Festplatte und Band. Eine lokale Backup-Appliance plus Object Storage in einem anderen Rechenzentrum erfüllt die Anforderung. Zwei Volumes auf demselben Array erfüllen sie nicht, und ein Snapshot allein ist kein Backup, weil er Hardware und Zugangsdaten mit den Daten teilt, die er schützt.

Unveränderliche und isolierte Kopien gegen Ransomware

Eine unveränderliche Kopie kann bis zum Ablauf ihrer Aufbewahrungsfrist weder geändert noch gelöscht werden, auch nicht von einem Administrator. Gängige Optionen sind Object Storage mit Write-once-Aufbewahrungssperren im Compliance-Modus, Backup-Appliances mit gehärteter Aufbewahrung und Medien, die physisch offline genommen werden.

Unveränderlichkeit hilft nur, wenn die umgebenden Kontrollen dazu passen. Gehen Sie davon aus, dass ein Angreifer in der Produktion Domänenadministratorrechte besitzt, und fragen Sie, worauf er trotzdem keinen Zugriff hat:

• Getrennte Identitäten. Die Backup-Plattform nutzt eigene Konten, nicht das Produktionsverzeichnis, mit Multi-Faktor-Authentifizierung bei jeder administrativen Anmeldung.
• Gesperrte Aufbewahrung. Aufbewahrungssperren, die sich nachträglich nicht verkürzen lassen, wobei jede Änderung der Aufbewahrungsrichtlinie zwei Personen erfordert.
• Netztrennung. Backup-Speicher, der nur von den Backup-Servern aus erreichbar ist, in einem separaten Managementnetz, ohne eingehenden Zugriff aus Nutzernetzen.
• Aufbewahrungstiefe. Genug Historie, um bis vor die Infektion zurückzureichen. Angreifer halten sich oft wochenlang unbemerkt in einem Netz auf, daher sind 30 bis 90 Tage ein realistisches Minimum für die unveränderliche Stufe.
• Alarmierung bei Anomalien. Alarme bei sprunghaft steigenden Datenänderungen, gelöschten Backup-Sätzen und geänderten Aufbewahrungsfristen, oft die ersten sichtbaren Anzeichen eines Angriffs.

Planen Sie die Wiederherstellung nach Ransomware getrennt von der Wiederherstellung nach Hardwareausfall. Nach Ransomware müssen Sie unter Umständen in eine isolierte Umgebung wiederherstellen, die Daten scannen, den letzten bekannten guten Zeitpunkt finden und Zugangsdaten neu aufbauen, bevor Sie irgendetwas wieder verbinden.

Datenbankkonsistenz: woran dateibasierte Backups scheitern

Das Kopieren der Dateien einer laufenden Datenbank erzeugt in der Regel ein Backup, das vollständig aussieht und bei der Wiederherstellung scheitert, weil die Seiten zu unterschiedlichen Zeitpunkten erfasst wurden. Nutzen Sie Methoden, die die Datenbank versteht.

• Native oder Hot-Backup-Tools. Nutzen Sie die unterstützte Online-Backup-Methode der Datenbank-Engine oder einen Backup-Agenten, der sich in sie integriert, damit die Kopie transaktionskonsistent ist.
• Log Shipping für ein kurzes RPO. Kombinieren Sie regelmäßige Vollbackups mit kontinuierlicher Archivierung der Transaktionslogs. Das ermöglicht Point-in-Time-Recovery, einschließlich der Rückkehr zu einem Zeitpunkt kurz vor einem fehlerhaften Deployment oder einer böswilligen Änderung.
• Anwendungskonsistente Snapshots. Wenn Sie auf Storage- oder VM-Snapshots setzen, versetzen Sie die Datenbank zuerst in einen Ruhezustand oder frieren sie ein (oder nutzen die Snapshot-Integration der Engine), damit der Snapshot einen konsistenten Zustand erfasst.
• Replikation ist kein Backup. Ein Replikat übernimmt Löschungen, Beschädigungen und fehlerhafte Updates getreu innerhalb von Sekunden. Nutzen Sie es für Verfügbarkeit und ein kurzes RTO, und halten Sie separate Backups für die Wiederherstellbarkeit vor.

Messen Sie die Wiederherstellungszeit der Datenbank, nicht nur die Backup-Zeit. Eine Wiederherstellung umfasst oft das Einspielen von Logs über Stunden und den Neuaufbau von Indizes, was ein Mehrfaches der Backup-Dauer benötigen kann. Wenn eine Datenbank mit 4 TB ein RTO von 2 Stunden hat, prüfen Sie, ob eine Wiederherstellung das einhalten kann oder ob Sie zusätzlich ein Standby-Replikat brauchen.

Eine 1-Gbps-Leitung überträgt bei voller Auslastung etwa 125 MB pro Sekunde, also rund 10 TB pro Tag. In der Praxis begrenzen Protokoll-Overhead, die Rehydrierung deduplizierter Daten und die Lesegeschwindigkeit des Speichers den dauerhaften Durchsatz oft auf 50 bis 80 Prozent der Leitungsrate.

• Beispiel. Die Wiederherstellung von 20 TB über 1 Gbps bei 70 Prozent Effizienz dauert etwa 2,9 Tage. Über 10 Gbps dauert sie etwa 7 Stunden, sofern der Speicher auf beiden Seiten mithalten kann.
• Zuerst eine lokale Kopie. Eine lokale Backup-Stufe nahe der Produktion bedient die meisten Wiederherstellungen schnell; die externen und unveränderlichen Stufen sind für Katastrophen und Angriffe da.
• Den kritischen Teil zuerst wiederherstellen. Legen Sie die Architektur so aus, dass die Tier-1-Daten zuerst und für sich allein wiederhergestellt werden können, statt auf den gesamten Datenbestand zu warten.

Ein Plan für Wiederherstellungstests, der die Wiederherstellbarkeit belegt

Ein Backup, das nie wiederhergestellt wurde, ist eine Annahme. Skalieren Sie den Testaufwand mit dem Tier:

• Täglich. Automatisierte Prüfung des Jobstatus und, sofern die Plattform es unterstützt, automatisierte Integritätsprüfung der Backup-Dateien. Jeder fehlgeschlagene oder übersprungene Job erzeugt ein Ticket.
• Wöchentlich. Stellen Sie eine Zufallsstichprobe von Dateien und Ordnern aus verschiedenen Systemen wieder her und vergleichen Sie sie mit Prüfsummen oder der Quelle.
• Monatlich. Stellen Sie mindestens eine Tier-1-Datenbank in einer isolierten Umgebung wieder her, führen Sie eine Konsistenzprüfung durch und bestätigen Sie, dass die Anwendung sie lesen kann. Halten Sie die benötigte Zeit fest.
• Vierteljährlich. Stellen Sie einen vollständigen Tier-1-Anwendungsstack einschließlich Abhängigkeiten aus der externen oder unveränderlichen Stufe wieder her. Vergleichen Sie die tatsächliche Wiederherstellungszeit mit dem RTO.
• Jährlich. Führen Sie eine vollständige Disaster-Recovery-Übung durch, einschließlich eines Ransomware-Szenarios, mit den Personen, die tatsächlich Rufbereitschaft hätten. Beziehen Sie den Entscheidungsprozess ein, nicht nur die technischen Schritte.

Dokumentieren Sie jeden Test: Datum, System, Quellkopie, Datenmenge, benötigte Zeit und gefundene Probleme. Wenn ein Test sein RTO überschreitet, behandeln Sie das als Vorfall mit einem Verantwortlichen und einer Frist.

Runbooks, denen man unter Druck folgen kann

Wiederherstellungen führt meist durch, wer gerade verfügbar ist, zu ungünstiger Stunde und unter Stress. Schreiben Sie Runbooks für diese Person: konkret, nummeriert und getestet, mit Befehlen, Hostnamen und erwarteten Ausgaben.

• Auslöser und Befugnis. Welche Bedingungen die Wiederherstellung auslösen, wer einen Katastrophenfall ausrufen darf und wer informiert werden muss.
• Kontakte. Verantwortliche, Dienstleister und Anbieter, mit Telefonnummern, die nicht davon abhängen, dass E-Mail funktioniert.
• Zugang. Wie die Backup-Plattform und die Wiederherstellungsumgebung erreichbar sind, wenn das primäre Verzeichnis, das VPN oder der Passwortmanager nicht verfügbar ist. Hinterlegen Sie Notfallzugangsdaten in einem versiegelten, auditierten Break-Glass-Verfahren.
• Wiederherstellungsreihenfolge. Die Abfolge der Systeme entsprechend ihren Abhängigkeiten: Netzwerk und DNS, Identität, Datenbanken, dann Anwendungen.
• Schrittweise Verfahren. Genaue Schritte pro System, mit der erwarteten Dauer jedes Schritts und der Art, wie der Erfolg überprüft wird.
• Validierung und Übergabe. Wie der fachlich Verantwortliche bestätigt, dass das System nutzbar und die Daten ausreichend aktuell sind, und wie der Normalbetrieb und die Backups wieder aufgenommen werden.

Bewahren Sie Runbooks an einem Ort auf, der die beschriebene Katastrophe übersteht: eine gedruckte Kopie, eine verschlüsselte Offline-Kopie und eine Kopie außerhalb der Produktionsumgebung.

Kostenabwägungen und wie man sie trifft

Jede Verkürzung von RPO oder RTO kostet Geld, und die Kurve ist am unteren Ende steil. Der Schritt von einem RPO von 24 Stunden auf 1 Stunde kostet vor allem häufigere Jobs und Logspeicher. Der Weg in Richtung null bedeutet meist kontinuierliche Replikation und eine Standby-Umgebung und damit ungefähr die doppelte Infrastruktur für diese Systeme.

• Speichervolumen. Die Aufbewahrungstiefe vervielfacht den Speicherbedarf. Deduplizierung und Komprimierung helfen bei Datei- und VM-Backups erheblich, bei bereits komprimierten oder verschlüsselten Daten weniger.
• Unveränderliche Stufe. Gesperrte Aufbewahrung bedeutet, dass Sie den gesamten Zeitraum bezahlen, auch für Daten, die Sie gern früher löschen würden. Dimensionieren Sie sie bewusst.
• Egress und Transfer. Manche Speicherdienste berechnen ausgelesene oder übertragene Daten, was große Wiederherstellungen und häufige Tests verteuert. Beziehen Sie die Wiederherstellungskosten in Ihre Schätzung ein, nicht nur den Speicher.
• Standby-Rechenleistung. Ein Warm Standby erfüllt kurze RTOs, kostet aber fast so viel wie eine zweite Produktionsumgebung. Ein Pilot-Light-Design repliziert die Daten und stellt die Rechenleistung erst während der Wiederherstellung bereit: günstiger, aber langsamer.
• Personal und Testzeit. Wiederherstellungstests und die Pflege der Runbooks kosten jeden Monat Arbeitsstunden. Planen Sie sie ein, denn ohne sie ist der Rest der Ausgaben unbewiesen.

Eine einfache Entscheidungsregel: Vergleichen Sie für jedes Tier den erwarteten jährlichen Schaden bei den aktuellen Zielen mit den jährlichen Kosten der Architektur, die strengere Ziele erfüllt. Kostet die Verbesserung weniger als der Schaden, den sie verhindert, setzen Sie sie um. Falls nicht, dokumentieren Sie das akzeptierte Risiko und lassen Sie es vom fachlich Verantwortlichen abzeichnen.

Checkliste für Backup und Wiederherstellung

• Jedes System: RPO, RTO, Tier und Verantwortlicher schriftlich.
• Abhängigkeiten erfasst; die Wiederherstellungsfolge folgt ihnen.
• Drei Kopien pro betroffenem System, auf mindestens zwei unabhängigen Speichersystemen, eine extern.
• Mindestens eine unveränderliche oder Offline-Kopie, 30 Tage oder mehr für kritische Daten.
• Backup-Administration über separate Konten mit MFA. Änderungen an der Aufbewahrung erfordern zwei Personen.
• Backups in isoliertem Netz, aus Nutzernetzen nicht erreichbar.
• Konsistente, Engine-gerechte Datenbank-Backups, mit Log-Archivierung, wo das RPO unter einigen Stunden liegt.
• Wiederherstellungsdurchsatz gemessen; größte Tier-1-Wiederherstellung passt ins RTO.
• Geplant und dokumentiert: tägliches Job-Monitoring, wöchentliche Datei-, monatliche Datenbank- und vierteljährliche Anwendungswiederherstellung, jährliche Gesamtübung.
• Runbooks nummeriert, getestet, offline, nach Tests oder größeren Änderungen überprüft.
• Alarme: fehlgeschlagene Jobs, gelöschte Backups, geänderte Aufbewahrung, Spitzen bei Datenänderungen.
• Kosten: Speicher, Transfer, Standby-Rechenleistung, Personalzeit. Fachverantwortliche zeichnen akzeptierte Risiken ab.

Nächste Schritte

Tragen Sie zunächst RPO, RTO und Verantwortlichen für Ihre zehn wichtigsten Systeme ein und führen Sie dann eine zeitlich gemessene Wiederherstellung des größten Systems durch.

Wenn Sie Backup-Ziele aufbauen oder migrieren, stellt Vonahost dedizierte Server mit lokalem NVMe oder Netzwerk-Blockspeicher bis 1 PB in der Region Ihrer Wahl bereit, und die Managed Cloud von Vonahost umfasst Backups. Jedes Angebot nennt Konfiguration, Standort, Zuständigkeiten und Monatspreis in US-Dollar, sodass klar ist, welche Teile des Wiederherstellungsplans Sie selbst betreiben und welche der Anbieter.