Backup-Konzept fürs ERP: Sicherungsarten, Ziele und Aufbewahrung

Je nach ERP liegen die Buchung einer Rechnung, das PDF dazu und das Druckformular in getrennten Speichern: Buchung in der Datenbank, PDF in einer Dateiablage, Formular in der Konfiguration; ebenso kann das ERP die Dokumente innerhalb der Datenbank ablegen. Sind die Speicher getrennt, ergibt eine Sicherung, die nur einen umfasst, nach dem Zurückspielen keinen zusammenhängenden Stand.

Was Sie vorab brauchen

eine Liste der Sicherungsobjekte mit Speicher- und Änderungsvolumen sowie den Zeitpunkten, an denen sich die Daten ändern (CON.3.A1)
je Objekt den maximal zulässigen Datenverlust (Recovery Point Objective, RPO) und die geforderte Wiederanlaufzeit (Recovery Time Objective, RTO)
die Wiederherstellungsanleitung Ihres Herstellers für Datenbank und Anwendung, passend zu Ihrer Release-Version
eine Liste Ihrer eigenen Anpassungen: Druckformulare, Berichte, Auswertungen, Schnittstellenmodule
Speicherorte nach der 3-2-1-Regel; für verschlüsselte Sicherungen den getrennt aufbewahrten Schlüssel (CON.3.A13)

Schritt für Schritt: Sicherungsplan für Ihr ERP

Schritt 1: Sicherungsobjekte trennen

Die Datenbank trägt Buchungen und Stammdaten, die Dokumentablage die Dateien dazu, die Konfiguration Ihre Formulare, Berichte und Schnittstellenmodule, das Systemumfeld Betriebssystem, Datenbanksoftware, Lizenzen und Installationsmedien. Legt Ihr ERP die Dokumente innerhalb der Datenbank ab, entfällt die separate Dokumentablage; andernfalls brauchen alle vier eigene Regeln: Die Dokumentablage wächst mit jedem Beleg, Anpassungen ändern sich mit jedem neuen Formular oder Bericht, das Systemumfeld mit jedem Update.

CON.3.A1 des BSI-IT-Grundschutzes verlangt, diese Rahmenbedingungen je System und Anwendung zu erheben: zu sichernde Daten, Speicher- und Änderungsvolumen, Verfügbarkeits- und Vertraulichkeitsanforderungen. Der IT-Grundschutz ist eine Methode des Bundesamts für Sicherheit in der Informationstechnik; verpflichtend wird er, wo eine Regelung oder ein Vertrag ihn festschreibt.

Schritt 2: RPO und RTO je Objekt festlegen

Der RPO ist der Datenverlust, den Sie hinnehmen: Er sagt, wie weit der wiederhergestellte Stand höchstens hinter dem Ausfallzeitpunkt liegen darf (BSI-Standard 200-4 nennt ihn den maximal zulässigen Datenverlust). Der RTO misst die Zeit vom Ausrufen des Notfalls bis zu dem Zeitpunkt, an dem die Notfalllösung nach dem Plan laufen muss; bei einem IT-System gehört das Zurücksetzen auf den letzten gesicherten Zustand dazu. Der RTO muss kürzer sein als die maximal tolerierbare Ausfallzeit des Geschäftsprozesses (BSI-Standard 200-4, Version 1.0, Stand Mai 2023, Kapitel 7).

Für die Häufigkeit folgt daraus die Rechnung: Wie alt die Daten höchstens sein dürfen, bestimmt, wie oft gesichert werden muss; der RPO ist damit die Grundlage der Sicherungszyklen. Rechnen Sie je Objekt durch, wie viel Arbeit der Verlust von zwei Stunden, einem halben Tag oder einem Tag bedeutet. Wie Sie Ausfallkosten in Euro rechnen: RTO, RPO und Ausfallkosten; Kurzdefinitionen im Glossar unter RPO und RTO.

Schritt 3: Sicherungsart je Objekt wählen

NIST Special Publication 800-34 Rev. 1 nennt in Abschnitt 5.1.2 drei Arten von Dateisicherungen; die Veröffentlichung ist eine Leitlinie für US-amerikanische Behördensysteme und wird hier nur verbindlich, wo eine Regelung oder ein Vertrag sie festschreibt:

Sicherungsart	Was sie erfasst	Was ein Restore braucht
Vollsicherung	alle Dateien des gewählten Bereichs	nur diese eine Sicherung
inkrementelle Sicherung	alles, was seit der letzten Sicherung beliebigen Typs neu oder geändert ist	die letzte Vollsicherung und jede folgende inkrementelle Sicherung
differenzielle Sicherung	alles seit der letzten Vollsicherung	die letzte Vollsicherung und die letzte differenzielle Sicherung

Eine Vollsicherung lässt sich am einfachsten zurückspielen, braucht aber am meisten Zeit und Platz. Inkrementelle Sicherungen sind klein, dafür hängt ihr Restore von einer lückenlosen Kette ab; fehlt ein Zwischenstand, bleibt der Datenstand unvollständig.

Führt Ihr Datenbanksystem ein Transaktionsprotokoll und brauchen Sie Zwischenstände zwischen zwei Vollsicherungen, kommt dessen laufende Sicherung hinzu. BSI APP.4.3.A9 verlangt regelmäßige System- und Datensicherungen des Datenbanksystems und sieht wiederherstellbare Transaktionen vor (SOLLTE), ohne jedem System eine eigene Protokollsicherung vorzuschreiben. NIST SP 800-53 Rev. 5 nennt in der Anforderung CP-10(2) für transaktionsbasierte Systeme Transaktions-Rollback und Transaktions-Journaling als Mechanismen der Wiederherstellung. Ob und wie fein Sie Protokolle sichern, steht in der Wiederherstellungsanleitung Ihres Herstellers. Führt Ihr Datenbanksystem kein Protokoll, genügt eine konsistente Vollsicherung, deren Intervall und Wiederherstellung die festgelegten Ziele erfüllen; NIST SP 800-34 Rev. 1 lässt die Kombination der Verfahren ausdrücklich von Systemkonfiguration und Wiederherstellungsanforderungen abhängen.

Von einem Sicherungsplan, der nur Beleg- und Tagesabschlussdaten umfasst, unterscheidet sich dieser Plan in zwei Punkten: der Sicherung von Zwischenständen, wo das Datenbanksystem ein Protokoll führt und Sie sie brauchen, und dem gemeinsamen Konsistenzpunkt.

Schritt 4: Häufigkeit und Konsistenzpunkt festlegen

Verknüpfen Sie Datenbank, Dokumentablage und Konfiguration zu einem gemeinsamen Konsistenzpunkt. Ohne ihn fehlen nach dem Restore die Dateien zu den Buchungen oder die Anpassungen zur Datenbankversion. CON.3.A4 verlangt, im Plan festzulegen, welche Daten durch welche Sicherung erfasst werden und in welcher Reihenfolge System und Anwendungen wiederhergestellt werden.

Wie Sie den gemeinsamen Zeitpunkt herstellen, steht in der Dokumentation Ihres Datenbanksystems, Ihrer Speicher- oder Ihrer Virtualisierungslösung. CON.3.A2 nennt Snapshot-Mechanismen als ergänzende Möglichkeit, in virtuellen Umgebungen und für Storage-Systeme schnell wiederherstellbare Zwischenversionen zwischen den Vollsicherungen zu erstellen. Dass ein Snapshot mehrere Datenträger in einem Zug erfasst, garantiert aber keinen anwendungskonsistenten Stand: Nach SYS.1.5, Gefährdung 2.4, können offene Dateien, Dateitransfers oder Datenbanktransaktionen zum Zeitpunkt des Snapshots inkonsistente Daten erzeugen. Prüfen Sie die Konsistenz daher über die Wiederherstellungsanleitung Ihres Herstellers und einen Restore-Test (CON.3.A15), bevor Sie den Stand als Konsistenzpunkt verwenden.

Schritt 5: Speicherorte nach der 3-2-1-Regel wählen

Die 3-2-1-Regel steht in der US-amerikanischen Veröffentlichung Data Backup Options (US-CERT, 2012), abrufbar bei der heutigen Sicherheitsbehörde CISA: drei Kopien einer wichtigen Datei, zwei verschiedene Medientypen, eine Kopie außer Haus. Die Publikation ist eine Faustregel und kein Gesetzestext; verbindlich wird sie, wo Sie oder ein Auftraggeber sie zum Standard erklären.

Für ein ERP heißt das: eine Kopie am System, eine zweite auf einem anderen Medientyp, eine dritte an einem anderen Ort. NIST SP 800-34 Rev. 1 nennt in Abschnitt 3.4.2 die Aufbewahrung außer Haus als bewährte Praxis. CON.3.A12 verlangt, die Speichermedien räumlich getrennt von den gesicherten Systemen aufzubewahren, möglichst in einem anderen Brandabschnitt.

Trennen Sie zusätzlich den Schreibzugriff: CON.3.A14 fordert, Sicherungen vor unbefugtem Zugriff und vor unbeabsichtigtem Überschreiben zu schützen; Schreibzugriff soll nur für autorisierte Sicherungen und Administrationsarbeiten möglich sein. Wie Sie Sicherungen unveränderlich halten: Unveränderliche Sicherung. Für eine Kopie im Online-Speicher soll der Vertrag nach CON.3.A9 Speicherort, Dienstgüte, Authentisierung und Verschlüsselung auf dem Speicher und beim Transport regeln; Prüffragen: Cloud-ERP: Sicherung durch den Anbieter.

Schritt 6: Aufbewahrung und Löschung regeln

CON.3.A4 verlangt, dass der Sicherungsplan festhält, wie lange Sicherungen aufbewahrt werden. Legen Sie die Fristen aus zwei Richtungen fest.

Aus dem Bedarf: Wie weit zurück müssen Sie einen Stand wiederherstellen können? Angenommen, ein falsch gebuchter Monatslauf fällt erst nach vier Wochen auf: Dann brauchen Sie eine Sicherung aus der Zeit vor dem Fehler. Ein Beispiel für ein Generationenschema sind 14 Tagessicherungen, 8 Wochensicherungen, 12 Monatssicherungen und je eine Sicherung nach Abschluss eines Geschäftsjahres. Das sind Beispielannahmen; Ihre Fristen folgen aus RPO, Prüfbedarf und Speicherplatz.

Aus den Grenzen: Ein Sicherungsstand Ihres ERP enthält personenbezogene Daten von Kundschaft, Lieferanten und Mitarbeitenden; prüfen Sie deshalb, welche Lösch- und Aufbewahrungsregeln dafür gelten. CON.6 Löschen und Vernichten ist laut CON.3 für Datensicherungen zu berücksichtigen; der Baustein weist darauf hin, dass Aufbewahrungsfristen ein frühes Löschen verbieten und Datenschutzvorgaben zugleich zeitnahes Löschen verlangen können.

Sicherungen ersetzen kein Langzeitarchiv: CON.3 grenzt sich gegen die Langzeitspeicherung ab und verweist auf den Baustein OPS.1.2.2 Archivierung, der unter anderem verlangt, Format, Dateisystem und Lesbarkeit über den gesamten Aufbewahrungszeitraum zu prüfen. Welche Aufbewahrungsfristen für Bücher und Belege gelten, ist in Deutschland, Österreich und der Schweiz unterschiedlich und hängt von der Unterlagenart ab; klären Sie die Fristen mit Ihrer Steuerberatung und notieren Sie sie im Plan. Für Deutschland: Löschkonzept und Aufbewahrung in Deutschland.

Schritt 7: Verantwortliche benennen und den Plan schützen

CON.3.A4 legt fest, was der Plan mindestens beschreiben muss: erfasste Systeme und Daten je Sicherung, Reihenfolge der Wiederherstellung, Verfahren zum Sichern und Zurückspielen, Aufbewahrungsdauer, Schutz vor Zugriff und Überschreiben, Parameter sowie Hard- und Software.

Benennen Sie je Aufgabe eine Rolle: wer sichert, wer prüft, wer spielt zurück. CON.3.A5 verlangt, dass alle Mitarbeitenden über die Regelungen zur Datensicherung und über ihre eigenen Aufgaben dabei informiert sind.

Bewahren Sie den Plan so auf, dass er ohne das ausgefallene System verfügbar ist. CON.3.A6 (Standard-Anforderung) sieht vor, dass das Sicherungskonzept selbst in einer Datensicherung liegt und die Wiederherstellungsinformationen auch dann verfügbar sind, wenn das Sicherungssystem ausfällt; der Baustein nennt als Gefährdung, dass eine rein digitale Wiederherstellungsdokumentation bei einem Großschaden verloren gehen kann. Ein zweiter Ablageort mit dem Betriebshandbuch fürs ERP hilft dabei. Für verschlüsselte Sicherungen sieht CON.3.A13 für erhöhten Schutzbedarf vor, die verwendeten Schlüssel mit einer getrennten Datensicherung zu schützen.

Der Sicherungsplan als Vorlage

Die Tabelle zeigt einen möglichen Aufbau. Alle Intervalle und Fristen sind Beispielannahmen; Ihre Zahlen folgen aus RPO, RTO und Prüfbedarf.

Datenbereich	Sicherungsart	Intervall (Beispielannahme)	Aufbewahrung (Beispielannahme)	Wiederherstellung
Datenbank (Buchungen, Stammdaten)	Vollsicherung; dazu laufende Sicherung des Transaktionsprotokolls, sofern das Datenbanksystem eines führt und Sie Zwischenstände zwischen zwei Vollsicherungen brauchen	Vollsicherung wöchentlich, Protokoll alle 15 Minuten	12 Vollsicherungen, Protokolle 30 Tage	Vollsicherung plus Protokolle bis zum gewünschten Zeitpunkt; Zwischenstände nur, soweit die Wiederherstellungsanleitung des Herstellers sie vorsieht
Dokumentablage (Rechnungen, Belege als Dateien)	inkrementell täglich, Vollsicherung wöchentlich	täglich 23:00 Uhr	14 Tagessicherungen, 8 Wochensicherungen, 12 Monatssicherungen	im Verbund mit der Datenbanksicherung desselben Konsistenzpunkts
Konfiguration und eigene Anpassungen (Formulare, Auswertungen, Schnittstellenmodule)	Vollsicherung nach jeder Änderung plus wöchentlich	auslösebezogen und wöchentlich	12 Monatssicherungen	Stand passend zur gesicherten ERP-Version auswählen
Systemumfeld (Betriebssystem, Datenbanksoftware, Lizenzen, Installation)	Vollsicherung vor jedem Update	vor jedem Update	bis zum Ende des Supports der Version	Installation und Lizenzen wieder verfügbar machen
Sicherungsplan, Schlüssel, Zugangsdaten	Ablage am zweiten Ort, Papierausdruck	bei jeder Änderung	jeweils gültige Fassung	Wiederherstellung ohne Zugriff auf das ausgefallene System

So prüfen Sie das Ergebnis

Der Plan nennt je Datenbereich Sicherungsart, Intervall, Aufbewahrung und die Reihenfolge der Wiederherstellung (CON.3.A4); Speichermedien und ihre Aufbewahrung sind nach CON.3.A2 festgelegt.
Das Intervall jedes Objekts reicht für seinen RPO; die Summe der Wiederherstellungsschritte passt in seinen RTO.
Die Sicherungsart jedes Objekts folgt seiner Wiederherstellungsanleitung; Zwischenstände aus dem Transaktionsprotokoll sind nur eingeplant, wo System und Anleitung sie vorsehen.
Eine Sicherung wurde mindestens einmal vollständig zurückgespielt, Dauer und Ergebnis stehen im Protokoll (CON.3.A15, Restore-Test fürs ERP).
Der Schlüssel jeder verschlüsselten Sicherung liegt getrennt und ist auffindbar (CON.3.A13).
Der Plan liegt auch außerhalb des gesicherten Systems, und jeder offene Punkt hat eine zuständige Person und eine Frist.

Prüfen Sie den Plan nach jeder Änderung an ERP-Version, Speicherort oder Anpassung erneut: Ein Plan, der zu einem alten Systemzustand passt, beschreibt einen Restore, den Sie so nicht mehr brauchen.

Wenn etwas nicht klappt

Symptom	Ursache	Umgang
Die Sicherung bricht ab, weil das Zeitfenster zu kurz ist	Datenmenge gewachsen, Sicherung läuft in die nächste hinein	inkrementelle Sicherung oder kürzere Protokollintervalle planen, Kapazität prüfen (CON.3, Gefährdungen 2.7 und 2.9)
Nach dem Restore fehlen Dokumente zu den Buchungen	Datenbank- und Dateisicherung stammen aus verschiedenen Zeitpunkten	gemeinsamen Konsistenzpunkt festlegen und beide Sicherungen daraus verwenden (CON.3.A2, CON.3.A4)
Verschlüsselte Sicherung lässt sich nicht öffnen	Schlüssel oder Passwort liegt nur im ausgefallenen System	getrennt aufbewahrten Schlüssel verwenden und seine Ablage in den Plan aufnehmen (CON.3.A13)
Die Sicherung ist verschlüsselt, obwohl sie niemand angefasst hat	Schadsoftware hat Schreibzugriff auf das Sicherungsmedium bekommen	Schreibzugriff auf autorisierte Sicherungen begrenzen oder Medien nur dafür verbinden (CON.3.A14, Gefährdung 2.10)
Der Plan ist im Notfall nicht auffindbar	Dokumentation liegt nur digital im ausgefallenen System	Papierausdruck oder Ablage am zweiten Ort (CON.3, Gefährdung 2.4)

Wann Sie Hilfe holen sollten

Holen Sie Ihre Datenbank- oder ERP-Betreuung hinzu, wenn die Wiederherstellungsanleitung für Ihre Release-Version fehlt oder nicht beschreibt, welchen Zustand ein Snapshot erfasst und ob dieser Stand anwendungskonsistent ist. Für die RPO- und RTO-Werte Ihrer Kerngeschäftsprozesse gehört der Fachbereich an den Tisch; ohne ihn bleiben die Zahlen Annahmen. Aufbewahrungs- und Löschfristen klären Sie mit Ihrer Steuerberatung. Und wenn Ihr ERP länger ausfallen kann, als Ihr RTO erlaubt, ist der nächste Schritt der Notfallplan für den ERP-Ausfall.