Disaster-Recovery-Strategie für Unternehmen
Datenkatastrophen vermeiden
Im Idealfall arbeitet die Unternehmens-IT reibungslos vor sich hin. Denn wer rechnet stets mit dem Schlimmsten? Doch Störfälle können immer wieder auftreten. IT-Verantwortliche sollten daher stets einen Disaster-Recovery-Plan parat haben - denn vor allem ein Datenverlust kann Unternehmen unter Umständen vor existenzielle Probleme stellen. Ein solcher Plan muss jedoch individuell auf die Geschäftsprozesse angepasst sein. Für Unternehmen gibt es effektive Maßnahmen, um die Auswirkungen von Ausfällen möglichst gering zu halten.
Der erste Schritt eines Disaster-Recovery-Plans besteht in der Bestandsaufnahme aller vom Unternehmen genutzten IT-Ressourcen. Eine umfassende Übersicht über Server, Storage, Anwendungen, Daten, Netzwerk-Switches, Access Points oder Netzwerkgeräte ist die Grundlage dafür, dass sich im Schadensfall eine umfassende Analyse durchführen lässt. Dazu gehört auch die Information über Anbindung, Ort und Abhängigkeiten der entsprechenden Komponenten.
Als nächstes muss der IT-Verantwortliche jedes dieser Elemente auf Risiken überprüfen und mögliche interne und externe Bedrohungen erfassen. Dabei hilft es, ein Worst-Case-Szenario zu entwerfen und die zu prüfenden Komponenten in diesem Kontext zu bewerten. Ein solches Szenario muss nicht nur reine IT-Ausfälle abbilden, auch externe Einflussfaktoren wie etwa der Wegfall der Stromversorgung oder ein Gebäudebrand gehören dazu. Diese Risiken sollte das IT-Team gemäß ihren Wahrscheinlichkeiten bewerten.
Danach muss es sämtliche Daten und Anwendungen näher betrachten und abhängig davon bewerten, wie kritisch sie für den Geschäftsablauf sind. Auf Basis dessen kann die IT-Abteilung in der Folge ein entsprechendes Ranking erstellen. Hier ist es wichtig, eine Einteilung nach Bedeutung, Anpassungshäufigkeit und den Sicherungsrichtlinien vorzunehmen. Sie sollte - etwa bei mittelständischen Unternehmen - drei bis fünf Klassen beziehungsweise Unterteilungen für die Wiederherstellung enthalten und keinesfalls granularer ausfallen. Schließlich muss im Notfall ein einheitliches Vorgehen bei vergleichbaren Anwendungen und Daten erfolgen, damit der Notfallplan weniger komplex ausfällt und damit eine schnellere Reaktion möglich ist.
Aktionen definieren
Ist erst einmal der Ist-Zustand bekannt, widmet sich der nächste Schritt der Definition von Wiederherstellungszielen im Schadensfall. So können bestimmte Anwendungen wie etwa im E-Commerce eine höhere Priorität bei der Schadensbehebung erhalten, da sie für den laufenden Betrieb wichtiger sind, ältere interne Systeme mit weniger Datenbewegungen darf man hingegen im ersten Schritt vernachlässigen. Bei der Festsetzung der Prioritäten beziehungsweise Klassen für die Rücksicherung sollten unbedingt die jeweiligen Fachabteilungen hinzugezogen werden, um die Geschäftsanforderungen möglichst genau zu berücksichtigen.
Für die Berechnung der Gewichtung von Systemen und Anwendungen eignet sich die Recovery Time Objective (RTO) als Kennzahl. Sie berechnet sich aus den Kosten, die ein Ausfall eines Systems in einer einheitlich definierten Zeiteinheit verursacht. Abhängig von dieser Kennzahl lassen sich kritische Komponenten über eine hostbasierte Replikation oder ein Disk-basiertes Backup mit kontinuierlichen Datenschutzfunktionen absichern, während für weniger kritische ein Restore aus einem Bandlaufwerk ausreicht.
Eine weitere Kennzahl, die Recovery Point Objective (RPO) bezeichnet den maximalen akzeptablen Datenverlust, der im Schadensfall auftreten darf. Bei einer hohen Toleranz ist eine Sicherung der Daten nur im Zeitraum von einigen Stunden notwendig. Sind die Daten allerdings kritisch für den Geschäftsverlauf, beträgt der RPO nur einige Sekunden. Die Kennzahl hängt auch davon ab, wie die Aktualisierungsrate der Daten im Verlauf einer vordefinierten Zeit ist. Findet der Ausfall bei weniger kritischen Daten beispielsweise eine halbe Stunde später als die letzte Sicherung statt, sind die in den letzten 30 Minuten erfolgten Änderungen verloren - bei täglich aktualisierten Daten ist dies aber weniger problematisch als etwa bei Shop-Systemen, die Kunden ständig für ihre Bestellungen nutzen.
Die Wahl der passenden Lösung
Bei der Wahl der passenden Disaster-Recovery-Lösung sollten IT-Verantwortliche in den richtigen Dimensionen denken und das für sie passende Schutzniveau wählen. Maximaler Schutz, der für den sicheren Betrieb des Unternehmens nicht notwendig ist, kann das Budget übermäßig belasten. Ist das Schutzniveau zu niedrig, könnte das wichtige Funktionen des Unternehmens gefährden. Die IT-Abteilung kann bei Systemen mit niedriger Priorität einen geringeren Schutz wählen, damit die dabei generierte Ersparnis in den Schutz kritischer Systeme fließen kann, beispielsweise durch eine Continuous Data Protection (CDP), die allerdings den Overhead für Produktions-Server und Storage-Kosten erhöht.
Außerdem ist es für Unternehmen ratsam, gesicherte Daten zusätzlich abseits des primären Rechenzentrumstandorts vorzuhalten, damit sie bei größeren Ereignissen, etwa einem Brandfall, nicht verloren gehen. Die dezentrale Sicherung sollte sich dabei jedoch in einer definierten und akzeptablen Zeit rücksichern lassen. Diese Sicherung kann entweder über ein Cloud-Backup oder mittels physischer Datenträger erfolgen. Um sicher zu gehen, dass die extern aufbewahrten Sicherungsdaten nicht von denselben Einflüssen, die den Schaden im Rechenzentrum verursachen, betroffen sind, empfiehlt sich eine Entfernung von mindestens 40 Kilometern vom Hauptstandort. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) spricht sich seit neuestem sogar für einen Abstand von 200 Kilometern aus. Da im Ernstfall Mitarbeiter eventuell verhindert sind - durch Evakuierungsmaßnahmen beispielsweise - sollten Restore-Prozesse automatisiert vonstattengehen können, um Ausfallrisiken weiter zu minimieren. Außerdem schließt eine Automatisierung menschliches Versagen weitgehend aus.
Übung macht den Meister
Ein Disaster-Recovery-Plan ist allerdings nur so gut, wie er tatsächlich implementiert wird. Dazu gehört die Mitwirkung aller Interessensgruppen in den jeweiligen Abteilungen, die die IT-Abteilung bereits in der Planungsphase hinzuziehen sollte. Um auch die Geschäftsführung für den Plan zu sensibilisieren, ist es ratsam, dort einen Verantwortlichen zu ernennen, der federführend an Konzeption und Implementierung mitwirkt. Ein Disaster-Recovery-Plan ist keinesfalls eine auf die Unternehmens-IT beschränkte Maßnahme. Nach Implementierung der Maßnahmen muss sie in regelmäßigen Tests und Simulationen auf Herz und Nieren geprüft werden - nur so können IT-Verantwortliche sicherstellen, dass ein Ausfall der IT nicht gleichzeitig auch den Ausfall des Unternehmens bedeutet.
Lesen Sie mehr zum Thema
