Disaster Recovery
Disaster Recovery bezeichnet die geplante Wiederherstellung von IT-Systemen und Daten nach einem schweren Ausfall – etwa durch Serverdefekt, Ransomware, Brand oder Rechenzentrumsstörung. Ziel ist es, ein System wie das ERP innerhalb einer vorher festgelegten Zeit und mit möglichst geringem Datenverlust wieder betriebsfähig zu machen.
Disaster Recovery (deutsch: Notfallwiederherstellung, kurz DR) bezeichnet die Gesamtheit aller Verfahren, Pläne und Ressourcen, mit denen ein Unternehmen seine IT-Systeme und Daten nach einem schwerwiegenden Ausfall wieder in einen betriebsfähigen Zustand bringt. Ein solcher „Disaster“ ist nicht die alltägliche Störung, sondern ein Ereignis, das den regulären Betrieb ganz oder in großen Teilen lahmlegt: ein Hardwaredefekt am Server, ein Verschlüsselungsangriff durch Ransomware, ein Brand oder Wasserschaden im Rechenzentrum, ein grober Bedienfehler oder der Ausfall eines Cloud-Standorts. Disaster Recovery beantwortet die Frage, wie schnell und mit welchem Datenstand die Systeme danach wieder laufen.
Im ERP-Kontext ist Disaster Recovery besonders kritisch, weil das ERP-System das operative Nervenzentrum eines Unternehmens ist: Aufträge, Bestände, Rechnungen, Buchhaltung und Kundendaten liegen dort. Fällt es aus, steht schnell der gesamte Geschäftsbetrieb still – es kann nicht kommissioniert, fakturiert oder verbucht werden. Eine belastbare DR-Strategie legt deshalb vorab fest, welche Systeme mit welcher Priorität wiederhergestellt werden, wie lange das dauern darf und wie viel Datenverlust im schlimmsten Fall verkraftbar ist.
Auf einen Blick
- Disaster Recovery = geplante Wiederherstellung von IT und Daten nach einem schweren Ausfall
- Zwei Kennzahlen steuern alles: RPO (maximal tolerierbarer Datenverlust) und RTO (maximal tolerierbare Ausfalldauer)
- DR ist mehr als ein Backup: Es umfasst Plan, Zielumgebung, Wiederanlauf und regelmäßige Tests
- Für das ERP entscheidend, weil dort Aufträge, Bestände und Buchhaltung zusammenlaufen
- Bei SaaS-/Cloud-ERP liefert der Anbieter DR mit – Verantwortung und Fristen stehen im SLA
Was gehört zu einer Disaster-Recovery-Strategie?
Disaster Recovery ist kein einzelnes Werkzeug, sondern ein abgestimmtes Bündel aus Technik, Prozessen und Verantwortlichkeiten. Kernbestandteile sind ein dokumentierter Wiederherstellungsplan (Disaster-Recovery-Plan), eine ausreichend entfernte Zweitkopie der Daten, eine Ziel- oder Ausweichumgebung, in der die Systeme wieder anlaufen können, sowie klare Rollen: Wer entscheidet im Ernstfall, wer stellt wieder her, wer informiert Kunden und Behörden. Ohne diese organisatorische Seite bleibt selbst die beste Technik im Notfall wirkungslos.
Eine gute DR-Strategie ordnet die Systeme zudem nach Priorität. Nicht alles muss gleich schnell zurück sein: Das ERP und die Auftragsabwicklung stehen meist ganz oben, während etwa ein internes Wiki längere Ausfälle verträgt. Diese Priorisierung entsteht aus einer Business-Impact-Analyse, die für jeden Prozess abschätzt, welcher Schaden pro Stunde Stillstand entsteht.
RPO und RTO: die zwei zentralen Kennzahlen
Jede DR-Planung dreht sich um zwei Zielgrößen. Der Recovery Point Objective (RPO) beschreibt, wie viel Datenverlust maximal hinnehmbar ist – also den Zeitraum zwischen der letzten gesicherten Datenkopie und dem Ausfall. Ein RPO von einer Stunde bedeutet: Im schlimmsten Fall gehen die Daten der letzten Stunde verloren, entsprechend muss mindestens stündlich gesichert werden.
Der Recovery Time Objective (RTO) legt fest, wie lange die Wiederherstellung höchstens dauern darf, bis ein System wieder produktiv ist. Ein RTO von vier Stunden heißt, dass das ERP spätestens vier Stunden nach dem Ausfall wieder nutzbar sein muss. Beide Werte bestimmen unmittelbar die Kosten: Sehr kurze RPO und RTO verlangen aufwendigere Technik wie Spiegelung in Echtzeit, während großzügigere Ziele mit einfachen Backups auskommen.
Wie Disaster Recovery in der Praxis funktioniert
Technisch beruht Disaster Recovery darauf, dass Daten und Systemzustände redundant an einem zweiten, räumlich getrennten Ort vorgehalten werden. Das reicht von regelmäßigen, ausgelagerten Sicherungen über kontinuierliche Replikation bis hin zu einem vollständigen zweiten Rechenzentrum, das im Notfall einspringt. Entscheidend ist die räumliche Trennung: Liegt die Zweitkopie im selben Serverraum, hilft sie bei Brand oder Diebstahl nicht.
Ein bewährtes Grundprinzip ist die 3-2-1-Regel: drei Kopien der Daten, auf zwei verschiedenen Medientypen, davon eine an einem externen Standort. Gegen Ransomware kommt oft eine unveränderbare, vom Netz getrennte Kopie (Immutable- bzw. Offline-Backup) hinzu, damit Angreifer nicht auch die Sicherung verschlüsseln können.
Der eigentliche Ernstfall folgt dann dem Wiederanlaufplan: Das Zielsystem wird bereitgestellt, der jüngste unversehrte Datenstand eingespielt, die Anwendung gestartet und geprüft, bevor Anwender wieder zugelassen werden. Weil sich in der Theorie vieles einfacher liest als im Stress des Ernstfalls, gehört zu jeder ernsthaften DR-Strategie der regelmäßige Test – ein simulierter Ausfall, bei dem die Wiederherstellung tatsächlich durchgespielt und die Zeit gestoppt wird.
Disaster Recovery vs. Backup vs. Hochverfügbarkeit
Disaster Recovery wird häufig mit benachbarten Begriffen verwechselt, die jedoch Unterschiedliches leisten. Die sauberen Abgrenzungen helfen, die eigene Absicherung richtig zu dimensionieren.
Backup ist nur ein Baustein
Ein Backup ist die reine Datensicherung – eine Kopie, aus der sich Dateien oder Datenbanken zurückholen lassen. Disaster Recovery umfasst dagegen den kompletten Weg zurück in den Betrieb: Plan, Ausweichumgebung, Wiederanlauf und Test. Ein Backup ohne DR-Plan beantwortet die Frage „Sind die Daten da?“, aber nicht „Wie läuft das ERP in vier Stunden wieder?“. Backups sind notwendig, aber allein kein Disaster Recovery.
Hochverfügbarkeit verhindert, DR repariert
Hochverfügbarkeit (High Availability) zielt darauf, Ausfälle gar nicht erst spürbar werden zu lassen – etwa durch redundante Server, die bei einem Defekt unterbrechungsfrei übernehmen. Sie wird oft über eine Verfügbarkeits-SLA zugesichert. Disaster Recovery setzt einen Schritt später an: Es greift, wenn ein Ausfall trotzdem eingetreten ist und ganze Systeme oder Standorte wiederhergestellt werden müssen. Beide ergänzen sich – HA gegen den Alltagsdefekt, DR gegen die große Katastrophe.
Disaster Recovery im ERP-System
Für das ERP hat Disaster Recovery besondere Bedeutung, weil hier Warenwirtschaft, Vertrieb und Finanzen an einem Punkt zusammenlaufen. Ein längerer Ausfall bedeutet nicht nur stillstehende Prozesse, sondern potenziell auch inkonsistente Daten: Bestellungen, die während des Ausfalls über den Shop eingingen, Bestandsbuchungen aus dem Lager oder Zahlungseingänge müssen nach der Wiederherstellung sauber nachgezogen werden. Deshalb spielt bei ERP-DR nicht nur der Datenstand des ERP selbst eine Rolle, sondern auch die Synchronität mit angebundenen Systemen über die jeweiligen Schnittstellen.
Wie DR konkret umgesetzt wird, hängt stark vom Betriebsmodell ab. Bei einem Cloud- bzw. SaaS-ERP betreibt der Anbieter die Infrastruktur und liefert Disaster Recovery als Teil des Dienstes mit – inklusive georedundanter Rechenzentren, automatischer Backups und zugesicherter Wiederanlaufzeiten. Der Kunde muss dann vor allem prüfen, welche RPO- und RTO-Werte im Vertrag stehen und wie er seine exportierten Daten zusätzlich sichert. Bei einem On-Premise-ERP liegt die volle Verantwortung beim Unternehmen selbst: Sicherung, Ausweichstandort, Plan und Tests muss es eigenständig oder über einen Dienstleister organisieren.
DACH-Besonderheiten: DSGVO, Aufbewahrung und Verantwortung
Im deutschsprachigen Raum ist Disaster Recovery nicht nur eine technische, sondern auch eine rechtliche Frage. Die DSGVO verlangt in Artikel 32 ausdrücklich die Fähigkeit, „die Verfügbarkeit und den Zugang zu personenbezogenen Daten bei einem physischen oder technischen Zwischenfall rasch wiederherzustellen“ – Disaster Recovery ist damit für Unternehmen mit personenbezogenen Daten faktisch Pflicht, nicht Kür. Kommt es zu einem Datenverlust, kann zudem eine Meldepflicht bei der Aufsichtsbehörde greifen.
Hinzu kommen steuerliche Aufbewahrungspflichten: Buchungsrelevante Daten aus dem ERP müssen über viele Jahre revisionssicher und wiederherstellbar vorgehalten werden – ein Aspekt, der DR und Archivierung eng verzahnt. Wer Teile des Betriebs an einen Cloud-Anbieter auslagert, bleibt datenschutzrechtlich verantwortlich und sollte den Serverstandort, die Zertifizierung (etwa ISO 27001) und die vertraglich zugesicherten Wiederherstellungsfristen prüfen. Eine dokumentierte DR-Strategie ist damit zugleich Teil der Nachweis- und Sorgfaltspflichten.
Praxisbeispiel
Beispiel: Ransomware trifft einen Onlinehändler
Ein mittelständischer E-Commerce-Händler mit rund 400 Bestellungen am Tag betreibt sein ERP auf einem eigenen Server. An einem Montagmorgen sind alle Systeme verschlüsselt – ein Ransomware-Angriff hat auch die reguläre Backup-Platte im selben Netz erfasst. Weil das Unternehmen jedoch zusätzlich ein tägliches, vom Netz getrenntes Offline-Backup fährt (RPO 24 Stunden) und einen dokumentierten Wiederanlaufplan besitzt, greift die DR-Strategie.
Das IT-Team spielt den unversehrten Datenstand vom Vortag auf einen bereitgestellten Ersatzserver ein und startet das ERP nach knapp fünf Stunden wieder – innerhalb des zuvor definierten RTO. Die Bestellungen des Angriffstags werden anschließend aus Shop und Marktplatz über die Schnittstellen nachimportiert. Ohne die ausgelagerte, unveränderbare Sicherung wären sämtliche Auftrags- und Bestandsdaten verloren gewesen und der Betrieb tagelang stillgestanden.
Häufige Fragen
Passende ERP-Systeme
Passende Leistungen
Quellen
Fragen zu Disaster Recovery in deinem ERP-Projekt?
Wir beraten herstellerunabhängig – und setzen es auf Wunsch selbst um.