Zehn Fehler, die Sie beim Disaster-Recovery-Plan vermeiden sollten

In diesem Beitrag finden Sie die zehn häufigsten Fehler, die bei der Planung von Disaster Recovery (DR) immer wieder auftauchen, aber vermeidbar sind.

Dieser Artikel behandelt

Sichere Datenspeicherung

Machen Sie sich den Planungs-Prozess von Disaster Recovery nicht noch schwerer als dieser ohnehin schon ist, indem Sie zu viele Kompromisse eingehen. Nur eine gute Planung ist die Basis für eine gute Wiederherstellung.

Am Anfang eines jeden neuen Jahrs leiten IT-Abteilungen und möglicherweise auch der eine oder andere Business-Manager Schritte ein, um Unterbrechungen zu vermeiden und sich auf die unvermeidbaren angemessen vorzubereiten. Kurz gesagt wird es ernst in Sachen Daten-Sicherheit und Disaster-Recovery-Planung für die IT-Abteilungen.

Warum die Disaster-Recovery-Planung so schwer sein kann

DR-Planung (Disaster Recovery) ist eine komplizierte und zeitraubende Aufgabe, wenn diese angemessen durchgeführt wird. Das erklärt auch, warum laut diverser Umfragen die Anzahl der Firmen mit Continuity-Plänen stetig sinkt. In einer jährlichen Studie von PricewaterhouseCoopers hat sich der Prozentsatz an Unternehmen mit einem DR-Plan von 50 Prozent im Vorjahr auf 39 Prozent verringert. Von den Firmen mit einem angegebenen DR-Plan haben die wenigsten diesen in der Regel auch getestet. Das lässt Zweifel aufkommen, wie vorbereitet diese Firmen wirklich sind, wenn sie zwar einen dokumentierten, aber ungetesteten Plan besitzen.

Auch die Planungsaktivitäten an sich sind gesunken. Firmen lassen sich davon täuschen, ob diese Pläne auch tatsächlich notwendig und wertvoll sind. Es ist scheinbar offensichtlich, dass „mehr mit weniger tun“ bedeutet, dass man „mehr mit Computern erledigt“ und dafür beim Personal spart. Mitarbeiterkürzungen machen die Unternehmen noch abhängiger von stets funktionierenden und ununterbrochenen Systembetrieb und Automatiserungs-Prozessen. Zudem verringert es die Systemtoleranz gegenüber Unterbrechungen enorm. Der Zusammenhang zwischen diesen Fakten und einer krisenfesten und hochverfügbaren Automatisierung wird oft nicht wahrgenommen.

Geld ist immer eine Hürde und wird immer eine bleiben. Manager können sich leicht mit Investitionen identifizieren, die tatsächlich Geld für die Firma einbringen. Hier gibt man das Geld wesentlich lieber aus als für eine Continuity-Option, die man unter Umständen niemals braucht. Erschwerend kommt die Unsicherheit der Märkte in der heutigen Zeit hinzu. Dadurch wird der Fokus stärker verzerrt und man will lieber in etwas investieren, das auch Umsatz und somit Profite garantiert. Das geht meist auf Kosten der reinen Risiko-Prävention.

DR ist eine Investition

Der gesunde Menschenverstand, hinsichtlich der DR-Planung Budget, Ressourcen und Zeit zu investieren, wird durch Marketing-Behauptungen sowie Technologie-Hypes wie um Server-Virtualisierung, Daten-Deduplizierung, Cloud und Ähnliches vernebelt.

In den letzten Jahren haben Anbieter ziemlich viel Aufwand betrieben, um die Anwender zu überzeugen, dass diese Technologien zusätzliche Vorteile haben. Dazu gehören verbesserte und erhöhte Sicherheit für die Daten und den allgemeinen Betrieb. In einer Broschüre eines Hypervisor-Anbieters ist zu lesen „High Availabilty sticht Disaster Recovery aus“. „Tape Sucks. Move On“ war bei einer Messe auf Aufklebern eines Herstellers von Deduplizierungs-Appliances zu lesen. „Clouds bieten Tier-1-Daten-Sicherheit“ behauptete eine PowerPoint-Präsentation eines Service-Providers. All diese Aussagen lassen vermuten, dass die Planung von Disaster Recovery eine veraltete Praxis ist. Heutzutage setzt man auf Unverwüstlichkeit und Verfügbarkeit, die in die modernen Produkte integriert sind. Allerdings sind diese Behauptungen schlichtweg falsch oder nur unter Vorbehalten zutreffend.

1.  Glauben Sie nicht, dass High Availability (Hochverfügbarkeit) mit DR gleichzusetzen ist

Den Anbietern zu glauben, DR-Planung sei irrelevant, ist der erste und möglicherweise größte Fehler, den es in Bezug auf das Planen von Disaster Recovery zu vermeiden gilt. Natürlich sind in Sachen HA-Technologie (High Availabilty) Verbesserungen eingeflossen. Allerdings ändert dies absolut nichts hinsichtlich der Notwendigkeit einer Continuity-Planung. HA war schon immer eine Alternative, wenn man eine Wiederherstellung nach einem Desaster realisieren musste. Eingeschränkt wurden diese HA-Strategien allerdings in der Regel immer durch das Budget. HA, also das Failover zwischen geclusterten Komponenten, ist normalerweise teurer als die Alternativen. Für Workloads und Daten, die nicht dauerhaft verfügbar sein müssen, ist die Technologie unangemessen. Bei den meisten Firmen fallen vielleicht zehn Prozent der Workloads in die Kategorie „dauerhaft verfügbar“.

2. Versuchen Sie nicht, alle Applikationen mit dem gleichen DR-Ansatz zu verarzten

Ein zweiter häufiger Fehler bei der DR-Planung ist dem ersten relativ ähnlich, nämlich alle Daten mit der selben Strategie abzusichern. Aus dem gleichen Grund, warum Failover-Clustering nicht für alle Workloads geeignet ist, benötigen nicht alle Daten Standort-übergreifende Disk-to-Disk-Replikation. Das gilt auch für Disk-to-Disk-Spiegelung, kontinuierliche Daten-Replikation via Snapshots oder andere Methoden. In Wahrheit lassen sich die meisten Daten effizient mithilfe von Datenbändern sichern und wiederherstellen. Festplatten für alles zu verwenden, inklusive Daten-Backups, scheint weniger komplex zu sein, ist aber oft wesentlich kostspieliger und weit weniger widerstandsfähig. Man muss sich nur die Bedrohungen in Bezug auf das Festplatten-Storage ansehen und die Probleme der Herstellerabhängigkeit beim Spiegeln und Replizieren zwischen unterschiedlichen Arrays. Ebenso erzeugt das WAN Kosten, bringt potenzielle Latenzen und mögliche Aussetzer mit sich. Es sind an dieser Stelle noch einige andere Faktoren im Spiel. Aus diesem Grund ist die Datensicherheit mit Disk-to-Disk-Methoden möglicherweise nicht ausreichend, um Ihre unersetzlichen Informationen ausreichend zu schützen. Datenbänder liefern zumindest Stabilität und Portabilität, die Festplatten nicht bieten können. Planen Sie „über den Tellerrand hinaus“.

3. Versuchen Sie nicht, alles zu sichern

Ein weiterer häufiger Fehler ist die Annahme, alle zu sichernden Daten müssten in einem einzelnen Backup-Prozess untergebracht sein. In der Realität sind viele Daten eine Mischung aus 40 bis 70 Prozent an Archivdaten. Wir sprechen hier von wichtigen, aber sich nicht mehr ändernden Daten, die man vom produktiven Storage auf eine Archiv-Plattform verschieben sollte. Ähnlich verhält es sich mit Datenmüll wie zum Beispiel Duplikate, die man überhaupt nicht mehr im Storage haben will. Lediglich 30 Prozent der sich auf dem Storage befindlichen Daten benötigen häufige Backups oder Replikation, um die täglichen Änderungen festzuhalten. Die anderen 70 Prozent erfordern wenn überhaupt eine wesentlich seltenere Sicherung. Sie können in Sachen Daten-Sicherheit jede Menge Geld und auch wertvolle Stunden bei einer Wiederherstellung sparen, indem Sie die Archiv-Daten von den produktiven trennen. Ein positiver Nebeneffekt ist, dass Sie wertvollen Platz in der teuren, produktiven Storage-Umgebung sparen. Das wirkt sich auch auf die jährlichen Anschaffungs-Kosten aus, die für eine Erweiterung des Storage notwendig wären. Möglicherweise sparen Sie sogar so viel Geld, dass Sie die damit die gewünschte Datensicherheitsstrategie finanziell abdecken können.

4. Übersehen Sie nicht die Daten, die nicht zentral abgelegt sind

Ausgelagerte Daten-Repositories übersieht man allzu gerne. Nicht alle wichtigen Daten liegen zentral auf einem Enterprise-SAN oder komplex hochskalierten NAS-Boxen (Network Attached Storage). Unternehmensentscheidende Daten befinden sich unter Umständen in Zweigstellen, auf Desktop-Rechnern, Notebooks, Tablets und immer häufiger Smartphones. Kürzlich durchgeführte Umfragen von TechTargets Storage Media Group haben gezeigt, dass sich Firmen nicht wirklich gut um Außenstellen oder PCs in ihren Daten-Sicherheits-Programmen gekümmert haben. Das war auch schon vor dem BYOD-Trend (Bring Your Own Device) der Fall. In einer weiteren Studie aus diesem Jahr lässt sich ablesen, dass 46 Prozent von 211 Unternehmen aus Europa zugegeben haben, noch nie Client-Geräte erfolgreich gesichert zu haben. Durch die BYOD-Welle ist hier eine enorme Gefahr an Daten-Verlusten gegeben. Diese Sicherheitslücke sollte unbedingt geschlossen werden. Dafür eignen sich Cloud-Backup-Services, allerdings muss hier dann eine angemessene Backup-Cloud ausgewählt werden.

5. Managen Sie Daten und Infrastruktur nicht falsch

Einen weiteren Fehler, den Neulinge in Sachen DR-Planung immer gerne machen, ist, die auslösenden Ursachen eines Desasters zu ignorieren, die meist aus schlechtem Daten-Management oder fehlerhafter Infrastruktur resultieren. Klassifizieren Sie die Daten falsch, wirkt sich das schnell negativ auf die Kosten einer  Disaster-Recovery-Planung aus. Haben Sie keine Kenntnisse darüber, welche Daten besonders wichtig sind, müssen Sie alle mit den gleichen teuren Techniken schützen. Im Hinblick auf die Infrastruktur gilt, dass Sie nicht schützen können, was Sie nicht sehen. Haben Sie keine Monitoring- und Reporting-Techniken für die Infrastruktur im Einsatz, können Sie nicht pro-aktiv auf aufkeimende Hardware-Ausfälle oder Leitungsmissstände reagieren. Somit ließe sich ein Desaster im Vorfeld nicht verhindern. Diese Lücken können Sie adressieren, indem Sie Klassifizierungs-Tools für Daten und Archive einsetzen, um diese besser zu managen. Für die Verwaltung der Infrastruktur sind Ressourcen-Management-Tools zuständig. Außerdem sollten Sie Ihrem Hardware-Anbieter klar machen, dass Sie seine Produkte nicht mehr länger kaufen, wenn sich diese nicht effizient mit der von Ihnen gewählten Infrastruktur-Management-Software verwalten lassen. Der positive Nebeneffekt ist, dass sich die normalen IT-Betriebskosten dadurch verringern lassen.

6. Versuchen Sie nicht, alle Konfigurationen am Recovery-Standort zu duplizieren

Einige versuchen, die komplette produktive Umgebung am Wiederherstellungs-Standort zu spiegeln. In der Regel müssen Sie nur einen Teil an Applikationen und Daten nach einer Störung wiederherstellen. Deswegen brauchen Sie keine Recovery-Umgebung, die ihrer produktiven aufs Haar gleicht. MECs (Minimum Equipment Configurations) helfen, die Kosten in der DR-Umgebung zu reduzieren. Außerdem ist das Testen dadurch einfacher. Oftmals gibt es die Möglichkeit, Server-Virtualisierungs-Technologien zu benutzen, um Applikationen in der Recovery-Umgebung zu hosten, die sie normalerweise nicht auf einem virtuellen Server vorhalten würden. Ausgiebige Tests sind der Schlüssel für eine nahtlose Übertragung, sei es vom physischem Host zum MEC-Host oder von physisch auf virtuell.

7. Vergessen Sie nicht, die WAN-Verbindungen zu verstärken

Fehler Nummer Sieben auf unserer Liste ist, den WAN-Verbindungen zu viel Vertrauen zu schenken und ihren negativen Einfluss auf ein die Wiederherstellungszeit zu unterschätzen. WANs (Wide Area Networks) sind Services, die angemessen konfiguriert und bemessen sein müssen. Weiterhin müssen diese Leitungen mit höchster Effizienz arbeiten, um die Daten-Wiederherstellung erledigen zu können. Das gilt auch für den Zugriff auf die Remote-Applikationen, die sich entweder in einer Firmen-eigenen Außenstelle oder einer Cloud-Hosting-Umgebung befinden. Es kommt nicht auf die Leistungs-Verträge (SLAs) an, die Ihnen der Cloud-Host- oder Cloud-Backup-Service zugesichert hat, sondern auf das WAN. Vergessen Sie an dieser Stelle nicht, Redundanzen zu gewährleisten. Wir sprechen hier von einem zusätzlichen WAN-Service, der anders an das Unternehmen angebunden ist. Das ist für den Fall gedacht, bei dem Ihr primäres WAN vom gleichen Desaster wie die produktive Umgebung betroffen ist. Beachten Sie außerdem, dass das über WAN verbundene Recovery-Gebäude oder der entsprechende Backup-Datenspeicher mindestens 80 Kilometer von Ihrer produktiven Umgebung entfernt ist. Somit können Daten nicht durch eine Katastrophe von großem geographischen Ausmaß zerstört werden. Die meisten MANs (Metroploitan Area Network) sind günstig und bieten MLPS-Verbindungen (Multiprotocol Label Switching) mit hohen Bandbreiten an. Diese sind aber nicht weitflächig verteilt, um Wirbelstürme, schmutzige Bomben oder andere flächendeckende Desaster zu überleben.

8. Schenken Sie Ihrem Cloud-Provider nicht zu viel Vertrauen

Nicht so bekannt wie andere Stolperfallen, ist der Umstand, dem Cloud-Provider für die Bereitstellung von Applikations-Hosting im Falle eines Ausfalls zu viel Vertrauen  zu schenken. Das gilt auch für die Wiederherstellungen der Daten nach einer Katastrophe. Nutzen Sie einen Online-Backup-Provider, haben Sie Daten wahrscheinlich Stück für Stück in die Backup-Cloud übertragen. Sie würden verblüfft sein, wie viele Daten sich im Laufe der Zeit beim Service-Provider angesammelt haben und wie lange es mit wie vielen Ressourcen  dauern würde, um diese Daten zurück in eine Recovery-Umgebung zu spielen. Um beispielsweise zehn TByte über ein T1-Netzwerk transportieren, so dauert dies mehr als 400 Tage. Möchten Sie Applikationen bei einem Cloud-Infrastruktur-Provider betreiben und diesen zum Beispiel als „Hot Site“ benutzen, sollten Sie die Anlagen des Cloud-Anbieters unbedingt persönlich unter die Lupe nehmen. Im Jahre 1970 wurden erstmals die so genannten „Hot Site Facilities“ eingeführt. Damals gab es einen Geschäftsmann, der Abonnements für einen nicht existierenden Ausweich-Ort verkaufte. Als der Betrug aufgedeckt wurde, flüchtete er vor einer Festnahme in ein Land ohne Auslieferungs-Vertrag. Sollten Sie einen Cloud-Anbieter für das Hosting Ihrer Recovery-Umgebung nutzen wollen, stellen Sie zumindest sicher, dass auch alles Angepriesene tatsächlich vorhanden ist. Dazu gehört auch das Tier-1-Data-Center.

9. App-Designs sollten den DR-Plänen keinen Strich durch die Rechnung machen

Fehler Nummer neun ist verfahrenstechnischer Natur: Die IT-Verantwortlichen dürfen nicht mehr länger akzeptieren, dass DR-Planung eine passive Aktivität ist. Sie müssen nicht mit den Karten spielen, die man Ihnen zugewiesen hat. Soll Business-Continuity vollständig realisiert werden, müssen Widerstandsfähigkeit und Wiederherstellbarkeit in die Applikationen und auch in die Infrastruktur von Anfang an integriert sein. Allerdings werden selten DR-Experten hinzugezogen, wenn die Applikationen entworfen werden und man die entsprechenden Infrastrukturen spezifiziert. Das muss sich in Zukunft ändern. Banal gesagt werden in diesem Moment schlechte Designs konzipiert, die dem potenziellen Recovery-Prozess der Firma in der Zukunft in die Quere kommen. Dazu gehört das Vorhalten von Applikationen und Daten auf proprietären Server-Hypervisoren oder Storage-Plattformen sowie Applikations-Codes mit unsicheren Funktionen. Auch übermäßig viel Caching kann schädlich sein da im Falle eines Ausfalls oder einer Störung in diesem Fall eine beachtliche Menge an Daten verloren gehen kann. Zieht man DR-Planer rechtzeitig mit hinzu, lassen sich bessere Entscheidungen hinsichtlich des Designs treffen. Die gesamten IT-Infrastruktur lässt sich somit einfacher wiederherstellen und das spart natürlich auch immense Kosten.

10. Vergessen Sie nicht, dem Geld zu folgen

Das Management ist für den Geldbeutel verantwortlich. Somit ist es eher ein Fehler, den Business-Wert des DR-Plans nicht herauszustellen und stattdessen mit technischen Fachausdrücken um sich zu werfen. Sie müssen der Geschäftsleitung klar machen, dass Sie alles tun, um die Kosten in Sachen Continuity so gering wie möglich zu halten, ohne die Wirksamkeit des Plans zu opfern. Sie müssen außerdem die Investition bezüglich der Risikoeindämmung hervorheben und die durch den Plan verbesserte Produktivität. Somit stellen Sie heraus, dass DR sehr wohl einen Wert für das Geschäft hat. Nur dann können Sie das Management überzeugen, Geld für eine Sache auszugeben, die im besten Fall niemals zum Einsatz kommt.

Es sei erwähnt, dass die größten Ausgaben im Hinblick auf DR-Planung nicht die Kosten für Datensicherheit, Wiederherstellung der Applikations-Instanzen oder das Umleiten des Netzwerks sind, sondern die ausgiebigen und langwierigen Tests. Deswegen sollten Sie eine Möglichkeit finden, wie Sie das Szenario als Teil des Tagesgeschäfts testen können. Somit lindern Sie die Last der offiziellen Test-Ablaufpläne. Letztere sollten als logistische Generalproben und nicht als Tests dienen, um herauszufinden, ob sich Daten tatsächlich wiederherstellen lassen.

Über den Autor:

Jon William Toigo blickt auf 30 Jahre Erfahrung im IT-Bereich zurück. Er ist CEO und Managing Principal von Toigo Partners International sowie Vorsitzender des Data Management Institute.

Artikel wurde zuletzt im Juli 2014 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Sichere Datenspeicherung

0 Kommentare

Älteste Beiträge 

Passwort vergessen?

Kein Problem! Tragen Sie Ihre E-Mail-Adresse unten ein. Wir werden Ihnen eine E-Mail mit Ihrem Passwort schicken.

Ihr Passwort wurde an die folgende E-Mail-Adresse gesendet::

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchNetworking.de

SearchEnterpriseSoftware.de

SearchDataCenter.de

Close