In den meisten Unternehmen, die wir besuchen, „existiert" ein Backup formal. Eine grüne Lampe leuchtet, jemand hat irgendwann einmal in der Konsole geklickt, die Lizenzrechnung kommt jedes Jahr. Dann kommt ein Freitag, an dem Ransomware die Festplatten verschlüsselt oder jemand versehentlich die Produktionsdatenbank löscht — und es stellt sich heraus, dass die letzte Kopie, die sich tatsächlich wiederherstellen lässt, drei Monate alt ist.
Ein Backup ist keine Kopie. Ein Backup ist eine erfolgreiche Wiederherstellung. Alles davor ist nur ein Versprechen.
Dieser Text geht nicht darum, welches Produkt du kaufen sollst. Er geht um die eine Sache, die fast kein KMU regelmäßig macht und die im Ernstfall buchstäblich Firmen rettet: den Restore-Test.
Ein Backup, das nie wiederhergestellt wurde, ist kein Backup
Die Regel ist brutal und kurz. Wenn in den letzten 12 Monaten niemand in deiner Firma eine Datei, eine Datenbank oder eine virtuelle Maschine aus dem Backup wiederhergestellt hat — dann hast du kein Backup. Du hast die Hoffnung, ein Backup zu haben. Das sind zwei verschiedene Dinge.
Wir haben Konfigurationen gesehen, in denen jede Nacht ein hübsch benannter Job lief, die Mail-Berichte „success" sagten, und in Wirklichkeit hat das System acht Monate lang einen leeren Netzwerkpfad gesichert, weil jemand die Daten auf einen neuen Server verschoben und vergessen hatte, den Pfad zu aktualisieren. Die Konsole konnte das nicht wissen. „Grün" hieß nur, dass der Prozess durchgelaufen ist — nicht, dass er irgendetwas Wertvolles gerettet hat.
Was meistens kaputt ist
Bei Restore-Tests bei Kunden kommen meistens dieselben vier Sachen heraus. Keine davon ist exotisch. Alle sind banal — und genau deshalb hat sie niemand geprüft.
- Fehlende Quellen. Das Backup deckt Server A und B ab, aber nicht Server C, auf den vor einem Jahr ein wichtiges Verzeichnis verschoben wurde. Niemand hat die Policy aktualisiert.
- Veraltete Passwörter und Schlüssel. Die Kopie ist da, aber der Schlüssel zur Entschlüsselung lag bei einem ehemaligen Admin oder steckt in einer Datei, auf die niemand mehr Zugriff hat. Ohne den Schlüssel ist eine verschlüsselte Kopie nur Müll.
- Backup im selben Netzwerk wie die Produktion. Ransomware kommt ins Unternehmen, verschlüsselt die Server und gleich auch das Share, auf dem das Backup liegt — weil das Backup einfach eine weitere Festplatte ist, die aus einem Domain-Konto erreichbar ist. Die ganze Kopie geht zusammen mit dem Original unter.
- Kein Restore-Test der Datenbank. Die SQL-Dateien liegen vor, aber beim Versuch, sie wiederherzustellen, sind die letzten vier Snapshots inkonsistent (kaputte Transaktion, fehlende Log-Data-Beziehung), und kein Alarm hat das bemerkt.
Jede dieser Situationen kommt in 30 Minuten Test heraus. Jede kostet im echten Krisenfall mehrere Tage Stillstand und manchmal unangenehme Gespräche mit Kunden.
Der einfache monatliche Drill
Du brauchst keinen separaten DR-Plan für 200 Tausend. Du brauchst eine monatliche Gewohnheit. So einfach, dass jemand aus deinem Team (oder einem externen Partner) sie zwischen Kaffee und Mittagessen erledigt.
- Wähle zufällig einen Datensatz aus der Backup-Policy aus — eine Datei, einen Ordner, eine Datenbank oder eine ganze VM.
- Stelle ihn in einer separaten, isolierten Umgebung wieder her (überschreibe nicht die Produktion — das Ziel ist ein Test, keine Wiederherstellung).
- Prüfe, dass sich der wiederhergestellte Datensatz öffnen lässt, dass die Daten konsistent sind und dass sie auf dem Stand vom Tag vor dem Test sind.
- Miss die Zeit. Notiere: Datum, Datensatz, RTO (Wiederherstellungszeit), RPO (wie alt die Daten sind), Bemerkungen.
- Wiederhole nächsten Monat mit einem anderen Datensatz.
Nach einem Jahr hast du zwölf erfolgreiche Wiederherstellungen (oder, was wertvoller ist, eine Liste von Problemen, die du entschärft hast, bevor sie wirklich auftraten). Du hast außerdem belastbare RTO- und RPO-Werte, die du in Kundenverträge schreiben kannst, statt sie zu raten.
Was ein Test allein nicht ersetzt
Ein Restore-Test ist eine Handlung. Eine Strategie ist eine separate Sache. Die einfachste, die wir KMU empfehlen, ist die klassische 3-2-1-Regel, leicht modernisiert.
- 3 Kopien der Daten — Produktion plus mindestens zwei Backups.
- 2 verschiedene Medien oder Technologien — z. B. ein lokales NAS-Backup plus ein Cloud-Backup. So reduziert sich das Risiko, dass ein einziges Problem (Hardware-Defekt, Software-Bug) beide auf einen Schlag erwischt.
- 1 Kopie außerhalb des Produktionsnetzes — am besten immutable oder offline. Damit ein Konto, das von Ransomware übernommen wird, sie technisch nicht löschen kann.
Genau dieser letzte Punkt zählt heute. Die meisten Ransomware-Angriffe der letzten zwei Jahre, die wir aus der Nähe gesehen haben, haben gezielt nach dem Backup gesucht und es vor dem Verschlüsseln der Produktion gelöscht. Ein Backup, das mit gewöhnlichen Domain-Admin-Zugängen erreichbar ist, schützt vor nichts Ernstem.
Wie geht es weiter
Beginne mit drei Fragen an dein IT-Team (intern oder extern):
- Wann habt ihr zuletzt irgendetwas kalt aus dem Backup wiederhergestellt, ohne Vorankündigung?
- Ist das Backup physisch aus einem Konto erreichbar, das Ransomware über die Domain übernehmen könnte?
- Was ist das dokumentierte RTO und RPO für die ERP-Datenbank — und wann wurde es zuletzt gemessen statt geschätzt?
Wenn die Antworten „weiß ich nicht mehr", „glaube schon" oder „müsste ich nachschauen" sind — keine Panik, aber nimm es als Einladung, diesen Monat einen einfachen ersten Test zu machen. Wenn du nicht weißt, wie du ihn planen sollst, helfen wir KMU regelmäßig, das in seine Bestandteile zu zerlegen. Das erste Gespräch ist kostenlos und dauert eine halbe Stunde.
Ein Backup, das du nie wiederhergestellt hast, ist kein Backup. Es ist ein Vertrag, den keine Seite unterschrieben hat.