Wie testen wir regelmäßig Unternehmenssicherungen?

An einem Montagmorgen startet das Verwaltungssystem nicht. Aufgrund eines Serverfehlers, eines fehlerhaften Updates oder eines Ransomware-Angriffs sind Bestell-, Bestands- und Rechnungsdaten 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 man Unternehmens-Backups regelmäßig testet, damit im Ernstfall der Geschäftsbetrieb tatsächlich wiederhergestellt werden kann.

In vielen Organisationen ist das Backup eine technische Aufgabe, die im Hintergrund läuft. Das System erstellt es täglich, der Hosting-Anbieter bestätigt es, und ein grüner Haken erscheint auf der Überwachungsoberfläche. In der Zwischenzeit überprüft niemand, ob die Daten geöffnet werden können, ob sie zusammenpassen und ob ein nutzbares Geschäftssystem daraus wiederhergestellt werden kann. Das ist der gleiche Unterschied, wie wenn es eine Prozessbeschreibung gibt, das Team aber noch nie unter realen Bedingungen geübt hat.

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

Der Backup-Test ist eigentlich eine Geschäftsprozessübung

Technischer Erfolg und geschäftlicher Erfolg sind nicht immer dasselbe. Möglicherweise kann eine Datenbank wiederhergestellt werden, aber der Webshop ist nicht mit dem aktuellen Bestand verbunden. Möglicherweise ist der Inhalt des Dateiservers vorhanden, aber die Berechtigungen fehlen, sodass die Mitarbeiter nicht auf die benötigten 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, der Status der offenen Bestellungen jedoch ungewiss ist.

Daher sollte das Ziel des Tests nicht formuliert werden als „Konnte das Backup erfolgreich zurückgespielt werden“. Das Ziel ist vielmehr: Kann ein bestimmter Geschäftsprozess innerhalb einer akzeptablen Zeitspanne mit akzeptablem Datenverlust wieder funktionieren?

In einem Handelsunternehmen könnte dies bedeuten, dass die eingehende Webshop-Bestellung in das Verwaltungssystem aufgenommen wird, das Lager die Kommissionieraufgabe sieht und die Rechnung erstellt werden kann. In einem Produktionsunternehmen, dass der aktuelle Produktionsauftrag, die Produktstruktur und die Produktionsdaten verfügbar sind. In einem Dienstleistungsunternehmen, dass die Verträge, Kundendaten und laufenden Fälle 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. Dies ist ein notwendiger Ausgangspunkt, aber für die Entscheidungsfindung der Führung nicht ausreichend.

Es ist sinnvoll, von Geschäftsprozessen auszugehen. Was passiert, wenn keine Bestellungen angenommen werden können? Wie lange kann die Lagerausgabe stillstehen? Was sind die Folgen, wenn das Finanzsystem einen ganzen Arbeitstag nicht verfügbar ist? In welchem System befinden sich Daten, die nicht manuell wiederhergestellt werden können?

Daraus ergeben sich zwei Schlüsselwerte. Der eine ist das Ziel für die Wiederherstellungszeit: Wie lange darf es dauern, bis ein Prozess wieder funktioniert. Der andere ist der akzeptable Datenverlust: Wie viel Zeit an Daten darf maximal fehlen. Wenn das Unternehmen Bestellungen kontinuierlich entgegennimmt, mag ein Backup von der letzten Nacht technisch in Ordnung sein, geschäftlich jedoch einen zu großen Ausfall bedeuten.

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 dem Zusammentreffen dieser beiden Perspektiven.

Wie testen wir regelmäßig die Unternehmens-Backups?

Regelmäßigkeit bedeutet nicht, dass jeden Monat die gleiche vollständige 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 Folgen 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. Dies ist ein schneller Hinweis, aber kein Beweis für die Wiederherstellung.

Die nächste Ebene ist der regelmäßige Wiederherstellungstest. Dabei wird in einer separaten 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, Produktionsauftrag oder Dokument.

Die dritte Ebene ist die umfassendere Geschäftsprozessübung. Diese sollte typischerweise jährlich, in kritischen Umgebungen sogar häufiger durchgeführt werden. Hier geht es nicht um die Wiederherstellung einer einzelnen Komponente, sondern um den Test einer realen Geschäftskette. Aus dem Ergebnis ergibt sich am häufigsten, 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 separaten Umgebung durchgeführt werden

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

Die wiederhergestellte Umgebung muss nicht immer die gleiche Größe der 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 einzeln 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 noch nicht erscheint, kann nach der Wiederherstellung eine doppelte Erfüllung, ein fehlerhafter Bestand oder eine unklare Abrechnungssituation entstehen.

Es sollte ein Beweis sein, nicht nur eine Erinnerung

„Wir haben es letztes Jahr einmal ausprobiert“ ist keine Kontrolle. Jeder Test erfordert ein kurzes, nachvollziehbares Protokoll: 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 hat das Ergebnis genehmigt.

Dies ist keine administrative Last um der Last willen. Mit der Zeit werden 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 Abnahme 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 die gleiche 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.

Es ist auch häufig, dass nur an den zentralen Server gedacht wird. Dokumente, die in der Cloud verwaltet werden, Exporte von SaaS-Systemen, Konfigurationen, Einstellungen von Netzwerkgeräten, Integrationsschlüssel oder hochgeladene Dateien für individuelle Anwendungen werden ausgelassen. Für die Wiederherstellung eines Systems benötigt man oft nicht nur die Datenbank, 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 umstrukturierten Lagerprozess gibt 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 Rechnungsstellung 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?“ -, ist die nachgewiesene Wiederherstellungsfähigkeit kein technisches Detail, sondern ein Handlungsspielraum für die Führungskräfte.