Die Statusanzeige ist grün, der nächtliche Backup-Job wurde ohne Fehler beendet und die Daten liegen auf einem zweiten System. Klingt beruhigend. Bis tatsächlich eine Datenbank, ein virtueller Server oder mehrere Terabyte an Projektdateien wiederhergestellt werden müssen – und aus dem vermeintlich kurzen Ausfall ein ganzer Arbeitstag wird.

Das Problem liegt selten darin, dass überhaupt kein Backup vorhanden ist. Viel häufiger wurde nur der Sicherungsvorgang geplant, nicht aber der Ernstfall. Wer eine belastbare Backup-Strategie aufbauen will, sollte deshalb nicht bei der Frage „Wie viele Terabyte brauchen wir?“ anfangen, sondern bei zwei anderen Größen: Wie viele Daten dürfen verloren gehen und wie lange darf die Wiederherstellung dauern?

RPO und RTO: Zwei Abkürzungen, die über den Aufwand entscheiden

Das Recovery Point Objective, kurz RPO, beschreibt den maximal akzeptablen Datenverlust. Wird eine Anwendung einmal pro Nacht gesichert, können im schlechtesten Fall fast 24 Stunden Arbeit fehlen. Bei einem Online-Shop, einer Warenwirtschaft oder einer produktiven Datenbank wäre das meist kaum vertretbar.

Das Recovery Time Objective, kurz RTO, legt fest, wie schnell ein System nach einem Ausfall wieder verfügbar sein muss. Ein Archiv darf vielleicht zwei Tage offline bleiben. Beim zentralen Dateiserver oder einer geschäftskritischen virtuellen Maschine können bereits zwei Stunden zu lang sein.

Aus diesen beiden Werten ergibt sich, welche Backup-Software, Netzwerkanbindung und Hardware benötigt werden. Auch die Auswahl geeigneter Storage-Systeme sollte nicht allein nach der nominellen Kapazität erfolgen. Controller, Laufwerkstypen, verfügbare Schnittstellen, Erweiterbarkeit und Redundanz beeinflussen maßgeblich, wie schnell große Datenmengen im Notfall tatsächlich zurückkopiert werden können.

Die versteckte Schwachstelle: Zu wenig Restore-Leistung

Beim täglichen Backup werden meist nur neue oder veränderte Daten übertragen. Ein vollständiger Restore funktioniert anders: Plötzlich müssen mehrere Terabyte gelesen, geprüft, über das Netzwerk geschickt und auf das Zielsystem geschrieben werden.

Ein einfaches Rechenbeispiel zeigt die Größenordnung. Bei einer effektiven Übertragungsrate von 250 MB/s dauert die Wiederherstellung von 8 TB theoretisch knapp neun Stunden. In der Praxis kommen Dateisystem-Overhead, Prüfungen, viele kleine Dateien und konkurrierende Zugriffe hinzu. Aus neun Stunden werden schnell zwölf oder mehr.

Besonders tückisch sind Systeme, deren Backup-Fenster problemlos eingehalten wird, deren Restore-Durchsatz aber nie gemessen wurde. Eine schnelle Produktionsumgebung mit NVMe-Laufwerken lässt sich nicht in wenigen Minuten aus einem langsamen NAS mit ausgelasteter Gigabit-Anbindung wiederherstellen.

Wer ein RTO von zwei Stunden verspricht, muss deshalb rückwärts rechnen:

  • Wie groß ist der wiederherzustellende Datenbestand?
  • Welcher reale Lesedurchsatz ist am Backup-Ziel möglich?
  • Wie schnell schreibt das Ersatz- oder Produktivsystem?
  • Ist das Netzwerk schnell genug?
  • Können mehrere Wiederherstellungen parallel laufen?
  • Müssen Daten vor dem Restore noch entschlüsselt oder dekomprimiert werden?

Die langsamste Komponente bestimmt am Ende die Wiederherstellungszeit.

RAID schützt vor einem Defekt – nicht vor Datenverlust

Kaum ein Satz hält sich in kleinen IT-Umgebungen so hartnäckig wie „Wir haben RAID, also sind die Daten sicher“. RAID kann den Ausfall einzelner Laufwerke abfangen. Es hilft jedoch nicht, wenn Dateien versehentlich gelöscht werden, Schadsoftware Daten verschlüsselt oder ein fehlerhaftes Update Inhalte beschädigt.

Auch ein defekter Controller, ein Brand oder ein Einbruch kann mehrere Laufwerke gleichzeitig betreffen. RAID verbessert die Verfügbarkeit eines Speichersystems, ersetzt aber keine getrennte Sicherung mit eigener Versionshistorie.

Snapshots sind ebenfalls kein vollständiges Backup, solange sie ausschließlich auf demselben System liegen. Sie eignen sich hervorragend, um versehentlich geänderte Dateien schnell zurückzuholen. Fällt jedoch das gesamte Storage aus oder erhält ein Angreifer administrative Rechte, können auch die Snapshots verloren gehen.

Die 3-2-1-1-0-Regel als brauchbarer Ausgangspunkt

Die bekannte 3-2-1-Regel empfiehlt drei Kopien der Daten auf zwei unterschiedlichen Medien, von denen eine Kopie außerhalb des eigenen Standorts aufbewahrt wird. Für heutige Bedrohungen lohnt sich eine Erweiterung zur 3-2-1-1-0-Regel:

  • drei Kopien der relevanten Daten,
  • zwei unterschiedliche Speichermedien oder Speicherplattformen,
  • eine Kopie an einem anderen Standort,
  • eine unveränderbare oder physisch getrennte Kopie,
  • null ungeprüfte Fehler nach einem Backup-Test.

Der zusätzliche Schutz vor Veränderungen ist vor allem bei Ransomware wichtig. Möglich sind beispielsweise Object Lock, schreibgeschützte Snapshots, WORM-Speicher oder ein Medium, das nach der Sicherung vom Netzwerk getrennt wird. Welche Variante passt, hängt vom Datenvolumen und vom geforderten RTO ab. Ein Offline-Medium bietet hohen Schutz, ist aber nicht automatisch die schnellste Lösung für einen dringenden Restore.

Nicht alle Daten benötigen denselben Schutz

Eine einheitliche Backup-Richtlinie für sämtliche Systeme klingt übersichtlich, verursacht aber entweder unnötige Kosten oder unzureichenden Schutz. Sinnvoller ist eine Einteilung nach Bedeutung.

Produktive Datenbanken und zentrale Geschäftsanwendungen benötigen meist kurze Sicherungsintervalle sowie eine schnelle lokale Restore-Möglichkeit. Arbeitsdateien lassen sich je nach Änderungsrate stündlich oder täglich sichern. Bei Archiven steht dagegen häufig die langfristige Aufbewahrung im Vordergrund, während die Wiederherstellung länger dauern darf.

Diese Klassifizierung verhindert, dass selten genutzte Daten teuren Hochleistungsspeicher belegen. Gleichzeitig wird sichtbar, welche Anwendungen bei einem Totalausfall zuerst wiederhergestellt werden müssen. Denn auch mit schneller Hardware lassen sich nicht immer alle Systeme gleichzeitig zurückholen.

Ein Restore-Test muss mehr prüfen als eine einzelne Datei

Eine Testwiederherstellung von drei PDF-Dateien beweist lediglich, dass drei PDF-Dateien wiederhergestellt werden können. Für einen belastbaren Test sollte mindestens einmal ein vollständiger, repräsentativer Dienst zurückgeholt werden – etwa eine virtuelle Maschine samt Anwendung und Datenbank.

Dabei gehören folgende Werte ins Protokoll:

  • Start- und Endzeit der Wiederherstellung,
  • tatsächlich erreichter Durchsatz,
  • benötigte manuelle Schritte,
  • Integrität der wiederhergestellten Daten,
  • Funktionsprüfung der Anwendung,
  • Abweichung vom festgelegten RTO,
  • verantwortliche Personen und Zugangsdaten.

Gerade der letzte Punkt wird gern übersehen. Ein technisch perfektes Backup hilft wenig, wenn im Notfall niemand das Passwort für das verschlüsselte Repository findet oder nur ein abwesender Administrator den Ablauf kennt.

Kapazität mit Reserve planen

Backups wachsen nicht nur mit dem produktiven Datenbestand. Aufbewahrungsfristen, mehrere Versionen, Snapshots und temporäre Daten während einer Wiederherstellung benötigen zusätzlichen Platz. Deduplizierung und Komprimierung können den Bedarf reduzieren, sollten aber nicht als garantierte Größen behandelt werden.

Als Planungsgrundlage eignen sich reale Änderungsraten aus mehreren Wochen. Hinzu kommen Reserven für Wachstum, Rebuild-Vorgänge und unerwartet große Sicherungen. Wird ein Storage dauerhaft bis an seine Kapazitätsgrenze gefüllt, können Leistung und Wiederherstellbarkeit leiden. Außerdem fehlt dann ausgerechnet während einer Migration oder eines Notfalls der benötigte Spielraum.

Der unangenehme Test ist der wertvollste

Ein guter Restore-Test darf ruhig Schwächen aufdecken. Vielleicht ist die Netzwerkverbindung zu langsam, die Dokumentation veraltet oder das Wiederherstellen einer Datenbank komplizierter als gedacht. Solche Ergebnisse sind kein Scheitern, sondern der eigentliche Zweck der Übung.

Die entscheidende Frage lautet daher nicht, ob die Backup-Software jede Nacht ein grünes Häkchen zeigt. Entscheidend ist, ob sich ein kompletter Ausfall innerhalb der vereinbarten Zeit beherrschen lässt. Erst wenn diese Frage praktisch beantwortet wurde, ist aus einer Datensicherung eine echte Wiederherstellungsstrategie geworden.

Avatar-Foto

Markus

Markus ist der Spezialist für Infrastruktur und Code bei Addis Techblog. Er übernimmt dort, wo Plug-and-Play aufhört. Mit seinem fundierten Hintergrund in der Netzwerktechnik dekonstruiert er komplexe Routing-Probleme, entwickelt effiziente Docker-Umgebungen (wie Nextcloud oder Pi-hole) und schreibt smarte Skripte für nahtlose Smart-Home-Integrationen. Seine Tutorials zeichnen sich dadurch aus, dass sie selbst anspruchsvollste Netzwerk-Protokolle strukturiert, sicher und praxisnah für den Homelab-Betrieb übersetzen.