Ein Backup ist erst gut, wenn der Restore funktioniert

Backup und Recovery beantworten unterschiedliche Fragen

Ein Backup-Job zeigt, dass Daten geschrieben wurden. Ein Recovery-Test zeigt, ob das Unternehmen diese Daten unter realistischen Bedingungen wieder verwenden kann. Genau dieser Unterschied wird bei vielen Backup-Konzepten unterschätzt.

Ein einzelner erfolgreicher Datei-Restore ist hilfreich, beweist aber noch nicht, dass eine virtuelle Maschine, Datenbank oder komplette Anwendung innerhalb der benötigten Zeit wieder zur Verfügung steht.

RPO: Wie viel Datenverlust ist akzeptabel?

Das Recovery Point Objective beschreibt den maximal akzeptierten Datenverlust. Wird eine Datenbank nur alle 24 Stunden gesichert, kann im ungünstigsten Fall fast ein Arbeitstag fehlen. Bei einem RPO von einer Stunde muss die Sicherungs- oder Replikationsstrategie entsprechend dichter arbeiten.

RPO sollte pro System festgelegt werden. Ein Archiv kann andere Anforderungen haben als Warenwirtschaft, Fileserver oder Domänencontroller.

RTO: Wie lange darf der Dienst ausfallen?

Das Recovery Time Objective beschreibt die maximale Wiederanlaufzeit. Dabei reicht es nicht, die reine Rücksicherungsgeschwindigkeit zu betrachten. Ersatzhardware, Netzwerk, Hypervisor, Zugangsdaten, DNS, Zertifikate und Applikationsabhängigkeiten können den tatsächlichen Wiederanlauf bestimmen.

Wenn ein Unternehmen vier Stunden RTO fordert, muss dieser Zeitraum praktisch erreichbar sein – nicht nur theoretisch aus der Datenrate des Backup-Repositories berechnet werden.

Eine Kopie muss der Produktivumgebung entkommen

Ransomware und kompromittierte Admin-Konten können erreichbare Backups gefährden. Eine robuste Strategie trennt deshalb mindestens eine Kopie technisch oder organisatorisch von der Produktivumgebung. Mögliche Bausteine sind Immutable Storage, Object Lock, Offline-Medien, getrennte Backup-Administratoren und separate Zugangsdaten.

Wichtig ist die tatsächliche Trennung. Ein „separater Backupserver“ im gleichen Netz mit identischen Adminrechten ist nur begrenzt unabhängig.

Restore-Tests sollten abgestuft sein

Ein sinnvoller Testplan kann mehrere Ebenen kombinieren:

regelmäßige automatisierte Integritätsprüfungen,
stichprobenartige Datei- und Objekt-Restores,
vollständige VM-Wiederherstellungen in isolierter Umgebung,
applikationsbezogene Tests mit Datenbank und Abhängigkeiten,
wiederkehrende Notfallübungen für die wichtigsten Dienste.

Für jeden Test sollten Dauer, Probleme und notwendige manuelle Schritte dokumentiert werden. Daraus entsteht mit der Zeit ein realistischer Wiederanlaufplan.

Microsoft 365 und andere SaaS-Dienste

Cloud-Verfügbarkeit ist nicht identisch mit einem unabhängigen Backup. Anforderungen an versehentlich gelöschte Daten, langfristige Aufbewahrung, granulare Wiederherstellung oder unabhängige Kopien sollten getrennt bewertet werden. Ob ein zusätzliches Backup erforderlich ist, hängt vom konkreten Schutzbedarf und den vorhandenen Plattformfunktionen ab.

Backup-Fenster und Änderungsrate

Nicht nur die Gesamtmenge zählt. Eine Umgebung mit 20 TB Daten kann problemlos sicherbar sein, wenn sich täglich nur wenig ändert. Eine deutlich kleinere Datenbank mit hoher Änderungsrate kann wesentlich anspruchsvoller sein. Für Repository und WAN-Verbindungen sind tägliche Änderungsrate, Kompression, Deduplizierung und Aufbewahrung wichtig.

Praktische Checkliste

Kritische Systeme und Reihenfolge für den Wiederanlauf festlegen.
RPO und RTO je System dokumentieren.
Mindestens eine getrennte oder unveränderbare Kopie vorsehen.
Backup-Administrationskonten vom normalen Adminbetrieb trennen.
Wiederherstellung regelmäßig messen und dokumentieren.
Abhängigkeiten wie DNS, Identität, Zertifikate und Netzwerk einbeziehen.
Aufbewahrung und Speicherbedarf mit realen Änderungsraten berechnen.

Fazit

Die Qualität eines Backups zeigt sich nicht am grünen Status des letzten Jobs, sondern an einem reproduzierbaren Restore. Wer RPO, RTO und reale Wiederherstellungsdauer kennt, kann Produkte und Speichertechnik anschließend deutlich fundierter auswählen.