Wie teste ich die Datensicherung? Ist mein Backup ok?

Inhalt in Kürze

• Ein Backup gilt erst dann als Backup, wenn der Restore dokumentiert funktioniert hat. Alles andere ist Hoffnung.
• Vier Test-Arten gehören in jedes Konzept: File-Restore, VM-Restore, Bare-Metal-Wiederherstellung, vollständige DR-Übung.
• Rhythmus aus unserer Praxis: File-Restore wöchentlich, VM monatlich, Bare-Metal quartalsweise, DR-Übung jährlich.
• NIS-2 und BSI IT-Grundschutz CON.3 fordern dokumentierte Wiederherstellungstests — „läuft grün” reicht weder rechtlich noch technisch.

Wir sehen das jede Woche bei Neukunden in Hamburg: Das Backup-Log meldet seit Monaten „erfolgreich”, die externe Festplatte wird brav täglich gewechselt — und wenn der Geschäftsführer dann einen konkreten Restore-Test möchte, ist nichts darauf. Oder der Tape-Roboter läuft leer. Oder das verschlüsselte Backup-Archiv gehört einer Krypto-Trojaner-Variante, die seit sechs Wochen mitsichert. Ein Backup ohne Restore-Test ist keine Datensicherung — es ist ein Placebo.

Warum Backup-Tests Pflicht sind — nicht Kür

Ein Backup testen heißt: Sie spielen Daten aus dem Backup zurück und prüfen, ob sie vollständig, lesbar und nutzbar sind. Das ist keine Fleißaufgabe, sondern der einzige Beweis, dass Ihre Datensicherung funktioniert. Wir nennen das in der internen Checkliste „Schröders Regel” — nach einem Kunden aus Hamburg-Wandsbek, der nach einem Ransomware-Vorfall zu uns kam und sagte: „Das Backup war grün. Es war trotzdem nichts darauf.” Seitdem fragen wir bei jedem IT-Check als erstes: „Wann haben Sie zuletzt aus dem Backup tatsächlich Daten zurückgespielt?”

Die Lage ist ernst: Der BSI-Lagebericht weist seit Jahren steigende Ransomware-Zahlen aus, und Bitkom meldet, dass der Schaden durch Cyberangriffe in Deutschland jährlich über 200 Milliarden Euro liegt — Datenverlust und Betriebsunterbrechung sind dabei die teuersten Einzelposten. Wer in diesem Umfeld ein ungetestetes Backup fährt, fährt ohne Airbag.

Die vier Test-Arten — und wann Sie welche brauchen

Nicht jeder Test ist gleich aufwändig. Für den Alltag im Hamburger Mittelstand teilen wir Backup-Tests in vier Stufen. Jede Stufe beantwortet eine andere Frage.

Der Fehler in vielen KMU: Man beschränkt sich auf File-Restores, weil die einfach sind — und schließt daraus, dass das Backup „in Ordnung” ist. In Wahrheit sagt ein gelungener Word-Restore nichts darüber aus, ob Sie nach einem Server-Ausfall Ihre ERP-Datenbank wieder hochbekommen. Sie brauchen alle vier Stufen — in unterschiedlicher Frequenz.

Häufigkeit: Wie oft testen Sie welches Backup?

Die zweite Frage nach „welcher Test” ist „wie oft”. Hier gilt: Je kritischer das System, desto häufiger der Test. Für ein typisches KMU-Setup in Hamburg mit Fileserver, ERP, Mail und Microsoft 365 hat sich bei uns folgender Rhythmus bewährt.

Das Tägliche ist reine Software: Jeder ordentliche Backup-Job schreibt eine Checksumme und prüft die Integrität der Daten — das ist der Minimal-Standard. Das Wöchentliche und Monatliche lässt sich bei uns über die Backup-Lösung für Unternehmen automatisiert aufsetzen. Das Quartalsweise und Jährliche braucht einen Menschen, der den Test plant, durchführt und dokumentiert.

Wir sehen es jede Woche: Backups, die seit Monaten nicht geprüft wurden. Alle denken, es läuft — bis der Ernstfall kommt und nichts wiederherstellbar ist. Deshalb testen wir Backups regelmäßig und schriftlich. Nicht weil wir paranoid sind, sondern weil wir genug Kunden gesehen haben, bei denen „das Backup war grün" der Anfang eines dreimonatigen Totalausfalls war.

Jens HagelGeschäftsführer, hagel IT-Services GmbH

Test-Protokoll: So führen Sie einen Restore-Test durch — Schritt für Schritt

Der Unterschied zwischen einem „guten Gefühl” und einem belastbaren Backup-Test ist die Dokumentation. So läuft ein sauberer File- und VM-Restore-Test ab, wie wir ihn bei unseren Managed-Backup-Kunden in Hamburg fahren.

1. Schritt 1 — Test-Scope definieren: Welches System, welcher Zeitpunkt, welche Daten? Beispiel: „Fileserver FS01, Stand gestern 22:00 Uhr, Ordner /Projekte/2026."
2. Schritt 2 — Test-Umgebung vorbereiten: Isolierter Test-Host oder Sandbox-VM. NIE ins Produktivnetz zurückspielen — ein infiziertes Backup würde Live-Systeme re-infizieren.
3. Schritt 3 — Backup auswählen und mounten: Das gewünschte Restore-Point aus der Backup-Konsole picken. Moderne Systeme wie Veeam oder Acronis mounten Backup-Archive wie ein Laufwerk — kein kompletter Full-Restore nötig.
4. Schritt 4 — Daten zurückspielen: Einzelne Dateien oder die gesamte VM in die Test-Umgebung restoren. Zeit messen — das ist Ihr RTO (Recovery Time Objective).
5. Schritt 5 — Inhalt validieren: Öffnen Sie die wichtigsten Files. SQL-Datenbank? Dann einloggen und eine Test-Query laufen lassen. Word-Dokument? Öffnen und prüfen. ERP? Login und Stammdaten-Check.
6. Schritt 6 — Konsistenz prüfen: Fehlen Dateien? Stimmen Zeitstempel? Sind alle Berechtigungen wieder da? Gerade NTFS-ACLs gehen bei schlechten Backup-Systemen gerne verloren.
7. Schritt 7 — Dokumentieren: Datum, Tester, System, Restore-Point, Dauer, Ergebnis, Auffälligkeiten — schriftlich. Bei uns fließt das in ein Ticket-System, bei Ihnen reicht erstmal ein Excel.
8. Schritt 8 — Test-Umgebung löschen: Test-VM abschalten, Test-Daten sicher entsorgen. Datenschutz-Pflicht — auch Test-Restores enthalten echte Personendaten.

Automatisiertes Testen: Veeam SureBackup, Acronis Advanced, Hyper-V Replicas

Der Teil, den kein Mensch manuell schaffen will: wöchentliche VM-Restores in isolierte Labs. Hier helfen automatisierte Backup-Verifikationen, die führende Backup-Systeme eingebaut haben.

• Veeam SureBackup startet die Backup-VM in einer isolierten Virtual Lab ohne Netzverbindung zum Produktivnetz, prüft Boot-Status, führt definierte Tests aus (HTTP-Check, Ping, SQL-Query) und erzeugt einen Report. Läuft als nächtlicher Job im Hintergrund.
• Acronis Cyber Protect bietet „Advanced Backup Validation” — VM startet in Sandbox, Boot-Test, Malware-Scan (!) und Reporting. Für Unternehmen mit höherem Security-Bedarf sehr stark.
• Hyper-V Replica / VMware SRM prüft über regelmäßige Test-Failovers, ob die Replikat-VMs tatsächlich bootfähig sind — ohne den Live-Betrieb zu stören.

Wir richten das bei Managed-Backup-Kunden so ein, dass SureBackup jede Nacht die zehn kritischsten VMs prüft und einen Report in unser Monitoring schiebt. Fällt ein Test durch, generiert das System ein Ticket — noch bevor der Admin morgens im Büro ist.

Klaus’ Fall ist der Klassiker: Ein Ransomware-Angriff verschlüsselt die Primär-Backups mit, weil sie am Netz hängen. Nur die Offline-Platte überlebt — und die wurde seit Monaten nicht auf Lesbarkeit geprüft. Hätte Klaus das Offline-Medium einmal pro Quartal getestet, wäre das Risiko eines unbrauchbaren Rettungs-Backups deutlich geringer gewesen. Test-Backup heißt: auch die Offline-Kopie gehört in den Rhythmus.

NIS-2 und die Pflicht zum getesteten Backup

Seit Inkrafttreten der NIS-2-Richtlinie auf EU-Ebene und der kommenden deutschen Umsetzung gilt: Wer unter NIS-2 fällt — das sind laut BSI rund 29.500 Unternehmen in Deutschland — muss „angemessene Maßnahmen zur Datensicherung und Wiederherstellung” nachweisen. „Nachweisen” ist das Schlüsselwort: Kein Nachweis ohne Dokumentation. Keine Dokumentation ohne Test.

Konkret heißt das aus unserer Praxis bei NIS-2-Beratungen:

• Test-Rhythmus schriftlich festlegen — intern oder im Dienstleistervertrag.
• Restore-Tests protokollieren — Datum, Scope, Ergebnis, Verantwortlicher.
• RTO und RPO messen — Wie lange braucht die Wiederherstellung, wie viele Daten sind maximal weg?
• Offline-/Air-Gapped-Backups vorhalten und testen — für Ransomware-Resilienz Pflicht.
• Jährliche DR-Übung mit Geschäftsführung durchführen und dokumentieren.

Wer hier die Dokumentation nicht liefert, riskiert unter NIS-2 Bußgelder bis zu 10 Mio. € oder 2 % des weltweiten Jahresumsatzes — plus die persönliche Haftung der Geschäftsführung. Auch für KMU, die nicht direkt unter NIS-2 fallen, ist der BSI-Grundschutz-Baustein CON.3 Datensicherungskonzept der Gold-Standard — und verlangt ebenfalls regelmäßige Wiederherstellungstests.

Mehr zum Thema DSGVO, NIS-2 und Backup-Pflichten in unserem Pillar-Artikel Backup und Wiederherstellung — und wer einen strukturierten Wiederanlaufplan braucht, findet in unserer Anleitung Disaster Recovery Plan erstellen die passende Vorlage.

Die sieben häufigsten Backup-Test-Fehler in Hamburger KMU

Aus über 20 Jahren IT-Dienstleistung in Hamburg — das sind die Fehler, die wir immer wieder sehen:

• „Das Log ist grün, also läuft's." Job-Erfolg heißt nur, dass Daten geschrieben wurden — nicht, dass sie wiederherstellbar sind.
• Nur File-Restores getestet, nie Full-VM. Die Einzel-Datei geht zurück — aber kann die ERP-DB auch booten? Völlig andere Frage.
• Test auf dem Produktivserver. Katastrophal. Ein defekter Restore überschreibt Ihre Live-Daten. Immer Sandbox.
• Keine Offline-Kopie getestet. Online-Backups können mitverschlüsselt werden. Die Offline-Platte rettet Sie — aber nur wenn sie lesbar ist.
• Restore-Dauer nicht gemessen. RTO ist messbar. Wenn Sie nicht wissen, ob es 4 Stunden oder 4 Tage dauert, haben Sie kein Notfallkonzept — Sie haben Hoffnung.
• Microsoft 365 nicht gesichert. Microsoft garantiert die Verfügbarkeit, nicht die Wiederherstellbarkeit Ihrer Mails. Ohne M365-Backup sind Daten nach 30 Tagen endgültig weg.
• Keine Dokumentation. „Ich habe getestet" ohne Protokoll ist im Audit-Fall wertlos. Und im Versicherungs-Schadenfall auch.

Checkliste: Ihr Backup-Test-Konzept auf einen Blick

• Verify-Option aktiviert. Jeder Backup-Job prüft Checksummen automatisch.
• File-Restore wöchentlich. Zufällige Datei aus dem aktuellen Backup zurückholen und öffnen.
• VM-Restore monatlich. Kritische VM in Sandbox zurückspielen und booten lassen.
• Bare-Metal-Test quartalsweise. Ersatz-Hardware bereitstellen, Full-Restore fahren.
• DR-Übung jährlich. Komplettausfall simulieren, RTO und RPO messen.
• Offline-Kopie getestet. Air-Gapped-Medium ist lesbar und vollständig.
• Microsoft 365 separat gesichert. Eigenes M365-Backup (z.B. Veeam, Skykick) getestet.
• Dokumentation vollständig. Test-Datum, Scope, Ergebnis, Verantwortlicher — schriftlich.
• RTO-/RPO-Ziele definiert. Geschäftsführung hat diese genehmigt.
• Jährliche Review mit IT-Dienstleister. Konzept an aktuelle Bedrohungslage anpassen.

Was Sie heute tun können

Nicht im Kalender wälzen — heute direkt. Drei Schritte, dreißig Minuten:

1. Öffnen Sie die Backup-Konsole und sehen Sie nach, wann der letzte Restore-Test stattgefunden hat. Bei den meisten unserer Neukunden lautet die Antwort: „Noch nie” oder „vor anderthalb Jahren”.
2. Führen Sie einen einzelnen File-Restore durch. Irgendeine Datei aus dem gestrigen Backup auf den Test-Rechner. Öffnen Sie sie. Wenn das nicht in 15 Minuten klappt, haben Sie ein Problem.
3. Rufen Sie uns an. Wir schauen in 15 Minuten gemeinsam auf Ihr Konzept und sagen Ihnen ehrlich, ob Sie im Ernstfall sicher aus dem Wasser kommen — oder ob wir reden müssen.

Managed-Backup mit getesteten Restores ist Teil unserer Cybersecurity-Leistungen in Hamburg und Bestandteil jedes unserer Managed-IT-Verträge ab ca. 50 € pro Arbeitsplatz/Monat — inklusive Test-Dokumentation, Monitoring und jährlicher DR-Übung. Wir sind als IT-Systemhaus in Hamburg seit über 20 Jahren für mittelständische Unternehmen in Hamburg und Norddeutschland da.

Fazit

Ein ungetestetes Backup ist das gefährlichste Sicherheitsinstrument im Unternehmen — es vermittelt Sicherheit, wo keine ist. Der Wechsel vom „grünes Log-Gefühl” zum dokumentierten Restore-Test ist technisch einfach: Software-Verify-Option aktivieren, wöchentlichen File-Restore einbauen, monatlichen VM-Restore automatisieren, quartalsweise Bare-Metal-Test, jährlich DR-Übung. Fünf Bausteine, jeder für sich klein — zusammen die Differenz zwischen „Betrieb läuft in 4 Stunden wieder” und „Drei Monate Totalausfall, Laden zu”.

Die Frage ist nicht, ob Sie Backups testen sollten. Die Frage ist, ob Sie das selbst auf die Reihe bekommen — oder ob Sie einen Partner dabei haben möchten, der das seit 20 Jahren für Hamburger KMU macht.