Wie testen wir regelmäßig Unternehmens-Backups?

An einem Montagmorgen funktioniert das Verwaltungssystem nicht. Aufgrund eines Serverfehlers, eines fehlerhaften Updates oder eines Ransomware-Angriffs sind Bestell-, Lager- und Abrechnungsdaten nicht zugänglich. "Es gibt ein Backup", sagt jemand aus der IT. Das ist beruhigend, aber es beantwortet nicht die Frage, wann die Arbeit fortgesetzt werden kann. Die eigentliche Frage ist, wie wir Unternehmensbackups regelmäßig testen können, damit im Ernstfall der Geschäftsbetrieb tatsächlich wiederhergestellt werden kann.

In vielen Organisationen ist das Backup eine technische Aufgabe, die im Hintergrund abläuft. Das System erstellt es täglich, der Hosting-Anbieter bestätigt es, und das grüne Häkchen erscheint auf der Überwachungsoberfläche. Währenddessen überprüft niemand, ob die Daten zugänglich sind, ob sie zusammenpassen und ob ein nutzbares Geschäftssystem daraus wiederhergestellt werden kann. Das ist der gleiche Unterschied wie bei einer Prozessbeschreibung, die existiert, aber das Team hat sie noch nie unter realen Bedingungen ausprobiert.

Ein Backup wird nicht durch das Erstellen von Dateien wertvoll. Es wird wertvoll, wenn nachweislich der Betrieb daraus wiederhergestellt werden kann.

Der Backup-Test ist eigentlich ein Geschäftskontinuitätstest

Technischer Erfolg und Geschäftserfolg sind nicht immer dasselbe. Möglicherweise kann eine Datenbank wiederhergestellt werden, aber der Webshop ist nicht mit dem aktuellen Bestand verbunden. Möglicherweise sind die Inhalte des Dateiservers vorhanden, aber die Berechtigungen fehlen, sodass die Mitarbeiter nicht auf die erforderlichen Ordner zugreifen können. Es kann auch vorkommen, dass die ERP-Datenbank und die angehängten Dokumente aus unterschiedlichen Zeitpunkten stammen, sodass das System formal startet, aber der Status der offenen Bestellungen unklar ist.

Deshalb sollte das Ziel des Tests nicht lauten: "Ist es gelungen, das Backup wiederherzustellen?" Das Ziel sollte vielmehr sein: Kann ein bestimmter Geschäftsprozess innerhalb einer akzeptablen Zeitspanne mit akzeptablem Datenverlust wieder funktionieren?

Für ein Handelsunternehmen könnte das bedeuten, dass die eingehende Webshop-Bestellung ins Verwaltungssystem gelangt, das Lager die Kommissionieraufgabe sieht und die Rechnung erstellt werden kann. Für einen Hersteller, dass der aktuelle Fertigungsauftrag, die Produktstruktur und die Produktionsdaten verfügbar sind. Für ein Dienstleistungsunternehmen, dass Verträge, Kundendaten und laufende Vorgänge zugänglich bleiben.

Zuerst muss geklärt werden, was kritisch ist

Nicht jedes System ist gleich dringend. Ein häufiger Fehler ist, dass der Backup-Plan nach technologischen Elementen erstellt wird: Server, Datenbanken, virtuelle Maschinen, Ordner. Das ist ein notwendiger Ausgangspunkt, aber für eine Führungsentscheidung nicht ausreichend.

Es ist sinnvoll, von Geschäftsprozessen auszugehen. Was passiert, wenn keine Bestellungen angenommen werden können? Wie lange kann der Lagerausgang stillstehen? Was sind die Folgen, wenn das Finanzsystem einen ganzen Arbeitstag lang nicht verfügbar ist? In welchem System gibt es Daten, die nicht manuell neu erstellt werden können?

Daraus ergeben sich zwei Schlüsselwerte. Der eine ist die Zielzeit für die Wiederherstellung: Wie lange darf es dauern, bis ein Prozess wieder funktioniert. Der andere ist der akzeptable Datenverlust: Wie viele Daten dürfen maximal fehlen. Wenn das Unternehmen kontinuierlich Bestellungen annimmt, mag ein Backup von letzter Nacht technisch in Ordnung sein, aber geschäftlich bedeutet es möglicherweise einen zu großen Ausfall.

Diese Entscheidungen können nicht allein der IT überlassen werden. Der Betrieb weiß, was wiederhergestellt werden kann und wie lange es dauert. Der Vertrieb, die Finanzen, die Logistik oder die Produktion können jedoch sagen, welcher Ausfall akzeptabel ist. Ein guter Backup- und Wiederherstellungsplan entsteht aus der Begegnung dieser beiden Perspektiven.

Wie testen wir regelmäßig Unternehmensbackups?

Regelmäßigkeit bedeutet nicht, dass jeden Monat dieselbe umfassende Wiederherstellung durchgeführt werden muss. Die richtige Häufigkeit hängt von der kritischen Natur des Systems, der Anzahl der Änderungen und den geschäftlichen Konsequenzen eines Ausfalls ab.

Eine gut funktionierende Praxis besteht aus mehreren Ebenen. Die tägliche automatisierte Überprüfung prüft, ob die Backup-Aufgaben ausgeführt wurden, die Backup-Dateien erstellt wurden und ob es Fehler oder ungewöhnliche Größenänderungen gibt. Das ist ein schnelles Signal, aber kein Beweis für die Wiederherstellung.

Die nächste Ebene ist der regelmäßige Wiederherstellungstest. Dabei wird in einer isolierten Testumgebung ein ausgewähltes System oder eine Datenbank wiederhergestellt und deren Nutzbarkeit überprüft. Es reicht nicht aus, dass der Server startet. Man muss sich anmelden, die relevanten Daten öffnen und einige geschäftlich wichtige Datensätze überprüfen: die letzte Bestellung, Rechnung, Bestandsbewegung, Fertigungsauftrag oder Dokument.

Die dritte Ebene ist die umfassendere Geschäftskontinuitätsübung. Diese sollte typischerweise jährlich, in kritischen Umgebungen sogar häufiger durchgeführt werden. Hier geht es nicht um die Wiederherstellung einer einzigen Komponente, sondern um den Test einer realen Geschäftskette. Aus dem Ergebnis wird am häufigsten ersichtlich, dass eine Integration, ein Zertifikat, eine Berechtigung, eine Netzwerkrichtlinie oder eine Abhängigkeit von einem externen Dienstleister für den tatsächlichen Betrieb fehlt.

Der Test sollte in einer isolierten Umgebung durchgeführt werden

Ein Backup auf ein Live-System zurückzuspielen, ist riskant. Es kann aktuelle Daten überschreiben, Verbindungen unterbrechen oder Nebenwirkungen verursachen, die den normalen Betrieb gefährden. Das Grundprinzip des Testens ist daher die Isolation.

Die wiederhergestellte Umgebung muss nicht immer die gleiche Größe wie die Infrastruktur haben, aber die kritischen Abhängigkeiten müssen authentisch dargestellt werden. Wenn die Anwendung von einer Datenbank, einem Dateispeicher, einem Verzeichnisdienst und einer externen API abhängt, muss der Test dies berücksichtigen. Andernfalls beweisen wir nur, dass eine Backup-Datei existiert, nicht, dass der Dienst wiederhergestellt werden kann.

Integrierte Systeme verdienen besondere Aufmerksamkeit. Der Webshop, das ERP, das Lagersystem und die Kurierverbindung können jeweils gesichert werden, aber die Wiederherstellung der Zustände zwischen ihnen ist eine komplexere Frage. Wenn eine Bestellung in einem System bereits verarbeitet wurde, im anderen jedoch nicht, kann nach der Wiederherstellung eine doppelte Erfüllung, ein falscher Bestand oder eine unklare Abrechnungssituation entstehen.

Es sollte ein Beweis, nicht nur eine Erinnerung sein

"Wir haben es letztes Jahr einmal ausprobiert" ist keine Kontrolle. Für jeden Test ist ein kurzes, nachvollziehbares Protokoll erforderlich: Aus welchem Backup wurde die Wiederherstellung durchgeführt, wann wurde das Backup erstellt, wie lange dauerte die Wiederherstellung, welche Überprüfungen wurden durchgeführt, was funktionierte nicht auf Anhieb und wer genehmigte das Ergebnis.

Das ist keine administrative Last um der Last willen. Mit der Zeit macht es Trends sichtbar. Steigt die Wiederherstellungszeit? Ist nach einem Systemupdate eine neue Abhängigkeit aufgetreten? Aus den dokumentierten Abweichungen können Entwicklungsaufgaben erstellt, Verantwortliche benannt und Fristen gesetzt werden.

Die Tests müssen auch einen Eigentümer haben. Die IT oder ein externer Betreiber kann für die technische Durchführung verantwortlich sein, aber die geschäftliche Akzeptanz muss von dem Bereich kommen, der den Prozess nutzt. Ein Lagerleiter erkennt beispielsweise viel schneller, dass die wiederhergestellten Bestandsdaten unbrauchbar sind, als jemand, der nur sieht, dass die Datenbankverbindung erfolgreich ist.

Die häufigsten Fehler in der Backup-Praxis

Ein typisches Problem ist, dass in dieselbe Umgebung gesichert wird, die auch das ursprüngliche System nutzt. Ein Ransomware-Angriff, ein Berechtigungsfehler oder ein Infrastrukturfehler kann somit auch die Backups betreffen. Das Backup muss physisch und logisch getrennt sein und vor unbefugten Änderungen oder Löschungen geschützt werden.

Häufig wird auch nur an den zentralen Server gedacht. Dokumente, die in der Cloud verwaltet werden, Exporte von SaaS-Systemen, Konfigurationen, Netzwerkeinstellungen, Integrationsschlüssel oder hochgeladene Dateien für benutzerdefinierte Anwendungen bleiben außen vor. Für die Wiederherstellung eines Systems ist oft nicht nur die Datenbank erforderlich, sondern alle Elemente, die den Betrieb des Systems umgeben.

Der dritte Fehler ist das Ignorieren von Änderungen. Nach einem neuen Webshop-Modul, einem neuen Standort, einem geänderten Berechtigungsmodell oder einem umorganisierten Lagerprozess liefert der alte Backup-Test möglicherweise keine realistische Antwort mehr. Der Backup-Plan muss genauso an das Änderungsmanagement gebunden sein wie jeder andere kritische Geschäftsprozess.

Ein gut getestetes Backup ist kein spektakuläres Ergebnis. Es beschleunigt nicht direkt die Abrechnung und reduziert nicht von einem Tag auf den anderen die Verwaltung. Aber wenn bei einem Fehler alle dieselbe Frage stellen - "Wann können wir wieder arbeiten?" -, dann ist die nachgewiesene Wiederherstellungsfähigkeit kein technisches Detail, sondern ein Handlungsspielraum für die Führungskräfte.