Wiederherstellung testen: Restore-Test fürs ERP Schritt für Schritt
Kurz gesagt
Sie prüfen es mit einem Restore-Test: Spielen Sie eine Sicherung bekannten Standes in ein isoliertes Testsystem zurück, vergleichen Sie Datenbestand und letzte Belege mit dem Produktivsystem und messen Sie die Dauer. Die BSI-Basis-Anforderung CON.3.A15 (Stand Februar 2023) verlangt, regelmäßig zu testen, ob gesicherte Daten einwandfrei und in angemessener Zeit zurückspielbar sind – gleich für Deutschland, Österreich und die Schweiz.
Das Wichtigste
- Getestet wird in einem isolierten Testsystem mit abgeschalteten Schnittstellen, nie im Produktivsystem.
- BSI CON.3.A15 (Basis-Anforderung, Stand Februar 2023): Es MUSS regelmäßig getestet werden, ob gesicherte Daten einwandfrei und in angemessener Zeit zurückgespielt werden können.
- Der IT-Grundschutz bindet nicht durch Gesetz; er verpflichtet nur, wo Vertrag oder Regelung ihn festschreiben.
- Das Protokollblatt hält fest: Dauer je Phase, Ergebnisse der Datenprüfungen, offene Punkte, Abzeichnung mit Name und Datum.
- Ein fehlgeschlagener Test bleibt dokumentiert; nach der Behebung der Ursache wird der Test wiederholt.
Solange eine Sicherung nicht mindestens einmal zurückgespielt wurde, ist ihre Wiederherstellungsfähigkeit eine Annahme. Der Baustein CON.3 Datensicherungskonzept des BSI-IT-Grundschutzes nennt als eigene Gefährdung die fehlenden Wiederherstellungstests: Regelmäßige Datensicherungen gewährleisten nicht automatisch, dass sich die Daten auch wiederherstellen lassen (Gefährdungslage 2.2, Stand Februar 2023). Zum vollständigen Sicherungskonzept gehört nach der Baustein-Einleitung beides: das Erstellen der Sicherung und das Wiederherstellen auf dem Ursprungssystem. Für ein ERP prüfen Sie das mit einem Test, der dieselben Schritte wie ein echter Notfall durchläuft, aber in einer Umgebung, die nichts Produktives berührt.
Die Basis-Anforderung CON.3.A15 lautet: Es MUSS regelmäßig getestet werden, ob die Datensicherungen wie gewünscht funktionieren, vor allem, ob gesicherte Daten einwandfrei und in angemessener Zeit zurückgespielt werden können. Der IT-Grundschutz ist eine Methode des Bundesamts für Sicherheit in der Informationstechnik (BSI) und bindet nicht durch Gesetz; verpflichtend wird er nur, wo ein Vertrag oder eine Regelung ihn festschreibt. Das BSI entwickelt den Nachfolger Grundschutz++, der IT-Grundschutz bleibt nach Angaben des BSI in der Übergangszeit anwendbar (BSI-Seite zur Grundschutz-Methodik, gelesen am 13. Oktober 2026).
Was Sie vorab brauchen
- eine Sicherung mit bekanntem Stand: Sicherungstyp, Erstellungsdatum und -uhrzeit; bei verschlüsselten Sicherungen auch Schlüssel oder Passwort, getrennt aufbewahrt (dazu CON.3.A13: verwendete Schlüssel SOLLTEN mit einer getrennten Datensicherung geschützt werden)
- die Restore-Anleitung Ihres ERP-Herstellers für Ihre Release-Version, schriftlich oder als Dokument
- ein Testsystem oder eine Testinstanz, die keine Verbindung zur Produktivdatenbank hat: eigener Server oder virtuelle Maschine, eigener Datenbankname
- die Zugänge zu Schnittstellen und Druckern im Testsystem, bewusst abgeschaltet oder auf Testendpunkte umgebogen
- ein Protokollblatt nach der Tabelle unten und eine Uhr, mit der Sie jede Phase stoppen
- zwei Rollen, die abzeichnen: wer den Restore durchgeführt hat und wer die Daten fachlich geprüft hat
Welche Sicherungsart Sie für welche Daten vorsehen, steht im Backup-Konzept fürs ERP; der Test hier setzt voraus, dass ein solcher Plan existiert.
Schritt für Schritt: Restore in das Testsystem
Schritt 1: Testziel festlegen
Notieren Sie vor dem Test, welche Sicherung Sie einspielen (Typ, Erstellungszeitpunkt) und woran Sie Erfolg erkennen. Dazu gehört eine Zahl für die zulässige Gesamtdauer, abgeleitet aus Ihrem Wiederherstellungsziel. Wie Sie eine solche Zahl aus Ausfallkosten herleiten, beschreibt der Artikel zu RTO, RPO und Ausfallkosten.
Schritt 2: Testumgebung isolieren
Bauen Sie das Testsystem auf und prüfen Sie, dass keine Verbindung zur Produktivdatenbank besteht und alle Schnittstellen abgeschaltet sind: Shop-Anbindung, Mailversand, Lagergeräte, Zahlungsverkehr, Drucker. Ein restauriertes ERP, das Auftragsbestätigungen verschickt oder Bestände an den Shop meldet, verursacht im Betrieb doppelte Vorgänge. Ende dieses Schritts: Sie erreichen die Anmeldemaske des Testsystems, und die Schnittstellenlogik zeigt keine ausgehenden Verbindungen.
Schritt 3: Sicherung zurückspielen
Spielen Sie die Sicherung nach der Restore-Anleitung des Herstellers ein und stoppen Sie je Phase die Uhr: Datenbank, Dokumentablage, Konfiguration, eigene Anpassungen wie Druckformulare und Auswertungen. CON.3.A4 verlangt, dass der Sicherungsplan festlegt, in welcher Reihenfolge IT-System und Anwendungen wiederhergestellt werden — halten Sie sich beim Test an genau diese Reihenfolge, sonst testen Sie nicht den geplanten Notfall. Ende: alle Phasen sind ohne Abbruch durchgelaufen, mit Uhrzeit notiert.
Schritt 4: Anwendung starten und Anmeldungen prüfen
Starten Sie das ERP im Testsystem und melden Sie sich mit den Rollen an, die Sie später brauchen: Administration, Buchhaltung, Verkauf, Lager. Ende: jede Rolle kommt bis zu ihrer Startmaske; Meldungen im Protokoll des Systems sind notiert.
Schritt 5: Datenprüfungen durchführen
Führen Sie die Prüfungen der Tabelle im nächsten Abschnitt aus und tragen Sie je Prüfung das Ergebnis ein. Ende: jede Prüfung hat einen Eintrag bestanden oder nicht bestanden mit Wert.
Schritt 6: Dauer auswerten
Bilden Sie die Summe der Phasen und vergleichen Sie sie mit dem Testziel aus Schritt 1. Beispielannahme: Datenbank 55 Minuten, Dokumente 20 Minuten, Konfiguration 15 Minuten, Prüfungen 45 Minuten; die Summe aller vier Phasen liegt damit bei 135 Minuten gegen ein Ziel von 120 Minuten, also 15 Minuten über dem Ziel. Ende: die gemessene Dauer steht im Protokollblatt, mit dem Vergleich zum Ziel.
Schritt 7: Protokoll ausfüllen und abzeichnen
Füllen Sie das Protokollblatt aus, erfassen Sie offene Punkte mit Zuständigem und Frist und lassen Sie es von beiden Rollen abzeichnen. Planen Sie danach das Wegräumen: Die Testdaten sind eine vollständige Kopie Ihrer Unternehmensdaten; halten Sie fest, wer sie wann löscht. Ende: das Protokoll ist abgezeichnet und liegt mit dem Sicherungsplan zusammen, auch in gedruckter Form — die Gefährdung 2.4 des Bausteins CON.3 warnt, dass eine rein digitale Wiederherstellungsdokumentation bei einem Großschaden selbst verloren gehen kann.
So prüfen Sie das Ergebnis
Jede Prüfung vergleicht den Zustand im Testsystem mit einem Wert, den Sie vor dem Test dem Produktivsystem oder dem Sicherungsprotokoll entnehmen. Beispielannahme in der zweiten Spalte.
| Prüfung | Womit verglichen wird (Beispielannahme) | Bestanden, wenn |
|---|---|---|
| Datenumfang | Anzahl Buchungszeilen des letzten abgeschlossenen Monats, aus dem Produktivsystem notiert | die Anzahl im Testsystem stimmt damit überein |
| Letzter Beleg | Nummer und Zeitpunkt des letzten Belegs vor der Sicherung, etwa Lieferschein 4712 vom Vortag 17:42 Uhr | derselbe Beleg ist der letzte im Testsystem |
| Summen | Summe der offenen Posten und der Debitorensalden zum Sicherungsstichtag | Betrag und Anzahl Debitor stimmen überein |
| Dokumentablage | zehn gezogene gespeicherte Dokumente, etwa PDF-Rechnungen | jedes Dokument öffnet sich und gehört zum zugehörigen Vorgang |
| Eigene Anpassungen | Liste Ihrer Druckformulare, Auswertungen und Schnittstellenmodule | jedes Element ist vorhanden und lässt sich aufrufen |
| Anmeldungen | Rollenliste aus Schritt 4 | jede Rolle erreicht ihre Startmaske |
Das Protokollblatt
Das Protokollblatt ist das Ergebnis des Tests. Es braucht keine Software; eine Seite Papier oder eine Tabelle genügt, solange die Felder ausgefüllt werden.
| Feld | Eintrag |
|---|---|
| Testdatum und Testende | Datum, Uhrzeit Beginn und Ende |
| Getestete Sicherung | Typ, Erstellungsdatum und -uhrzeit, Speicherort |
| Testsystem | Umgebung, Releasestand des ERP, Abweichung zum Produktivsystem |
| Dauer je Phase | Datenbank, Dokumente, Konfiguration, Prüfungen, jeweils in Minuten |
| Datenprüfungen | je Prüfung: Vergleichswert, Istwert, bestanden oder nicht bestanden |
| Gemessene gegen geplante Dauer | Summe in Minuten und Zielwert aus dem Testziel |
| Offene Punkte | je Punkt: Beschreibung, Zuständige Person, Frist |
| Abzeichnung | Name und Datum der ausführenden Person und der fachlich prüfenden Person |
Wenn etwas nicht klappt
| Symptom | Mögliche Ursache | Umgang |
|---|---|---|
| Sicherung lässt sich nicht öffnen | Passwort oder Schlüssel fehlt oder ist nicht auffindbar | getrennt aufbewahrten Schlüssel verwenden; dessen Aufbewahrung in den Sicherungsplan aufnehmen |
| Datenbank startet mit Versionsfehler | Releasestand des Testsystems weicht vom Stand zum Sicherungszeitpunkt ab | passendes Release vor dem Restore einspielen; Releasesprung im Sicherungsplan vermerken |
| Dokumente fehlen im Vorgang | Datenbank- und Dateisicherung stammen aus unterschiedlichen Zeitpunkten | konsistentes Paar beider Sicherungen verwenden; den gemeinsamen Zeitpunkt im Plan festschreiben |
| Test-ERP meldet sich bei Schnittstellen | Schritt 2 nicht vollständig | Schnittstellen erneut abschalten, Test mit derselben Sicherung wiederholen |
| Gemessene Dauer übersteigt das Ziel | Engpass beim Einspielen, etwa Sicherung über eine langsame Verbindung | Messung im Protokoll belassen, Engpass benennen und im Sicherungsplan eine Variante mit kürzerer Übertragungszeit vorsehen |
Wann Sie Hilfe holen sollten
Holen Sie Ihren Betreuer oder den Herstellersupport hinzu, wenn der Restore an einer Stelle abbricht, die Sie mit der vorliegenden Anleitung nicht lösen können, oder wenn die Restore-Anleitung Ihres Herstellers lückenhaft ist — die Lücke ist dann selbst ein offener Punkt für den Protokollbogen. Wenn kein Testsystem existiert, klären Sie vor jedem Test im Produktivsystem schriftlich, wer eine Testumgebung bereitstellt und was sie kostet. Wo das Protokollblatt später abgelegt wird, regelt das Betriebshandbuch fürs ERP.