Backup ist kein Restore: Warum ungetestete Sicherungen im Ernstfall wertlos sind

Lesezeit: 4 Minuten | Autor: Michał Wołczyński

Viele Unternehmen und Schulen investieren Tausende Euro in teure Backup-Lösungen. Jeden Morgen leuchtet im Dashboard ein beruhigender grüner Haken: "Backup erfolgreich". Doch wenn der Ernstfall eintritt – sei es durch Ransomware oder einen Hardware-Defekt – folgt das böse Erwachen. Der Grund? Ein Backup zu haben, ist nicht dasselbe wie ein System wiederherstellen zu können.

Die Illusion des grünen Hakens

Ein erfolgreich geschriebenes Backup bedeutet lediglich, dass Datenkopien auf einem Speichermedium abgelegt wurden. Es garantiert jedoch nicht, dass:

• die Datenbanken konsistent und startbar sind.
• die Entschlüsselung im Notfall reibungslos funktioniert.
• Ihr Team weiß, in welcher Reihenfolge die Server (z.B. zuerst der Domain Controller, dann der Dateiserver) hochgefahren werden müssen.

Wer seinen Restore-Prozess nie testet, betreibt kein Backup-Management, sondern spielt russisches Roulette mit seinen Unternehmensdaten.

RPO und RTO: Die Metriken, die wirklich zählen

In der professionellen IT-Infrastruktur sprechen wir nicht von "wir machen nachts ein Backup", sondern wir definieren klare Geschäftsziele:

• RPO (Recovery Point Objective): Wie viel Datenverlust können wir uns leisten? Ein Tag? Eine Stunde? Bei kritischen ERP-Systemen reicht das nächtliche Backup oft nicht aus. Hier setzen wir auf inkrementelle Sicherungen im 15-Minuten-Takt.
• RTO (Recovery Time Objective): Wie lange darf es dauern, bis das System wieder läuft? Wenn Sie 5 Terabyte Daten aus der Cloud herunterladen müssen, steht Ihr Betrieb für mehrere Tage still. Ein lokaler Proxmox Backup Server (PBS) ermöglicht hingegen den Start einer VM direkt aus dem Backup-Storage in wenigen Minuten (Live-Restore).

Die 3-2-1-1-0 Regel und Immutable Backups

Die klassische 3-2-1 Backup-Regel (3 Kopien, 2 Medien, 1 Offsite) reicht im Zeitalter von Ransomware oft nicht mehr aus. Moderne Erpressungstrojaner suchen gezielt nach Backup-Servern im Netzwerk und verschlüsseln diese gleich mit.

Deshalb implementieren wir Immutable Backups (unveränderbare Backups). Einmal geschriebene Sicherungspunkte können für einen definierten Zeitraum weder von Administratoren noch von Schadsoftware gelöscht oder überschrieben werden. Kombiniert mit strikter Netzwerksegmentierung (VLANs), bei der der Backup-Server im Management-Netz völlig isoliert arbeitet, entsteht echte Resilienz.

Disaster Recovery Runbooks: Planen für das Chaos

Wenn am Montagmorgen alle Bildschirme rot leuchten und die Erpresser-Nachricht aufpoppt, ist keine Zeit für Improvisation. Ein Disaster Recovery (DR) Runbook ist eine Schritt-für-Schritt-Anleitung, die genau definiert:

• Wer wird zuerst informiert?
• Welche Netzwerkkabel werden physisch gezogen, um die Ausbreitung zu stoppen?
• In welcher genauen Reihenfolge werden die virtuellen Maschinen aus dem sicheren Backup-Storage wiederhergestellt?

Fazit

Hören Sie auf, sich auf ungetestete Backups zu verlassen. Führen Sie mindestens einmal im Quartal einen dokumentierten Restore-Test durch. Bauen Sie ein isoliertes Test-Netzwerk auf und stellen Sie den Domain Controller sowie die kritischste Anwendung aus dem Backup wieder her. Nur wenn sich die Benutzer dort erfolgreich anmelden können, haben Sie wirklich ein Backup.