Grundlagen: IT- und Datenwiederherstellung nach der Katastrophe Disaster Recovery im Überblick

Anbieter zum Thema

FAST LTA GmbH

Impossible Cloud GmbH

Immer wieder kann es zu Ausfällen der IT durch Versehen, Versagen oder Sabotage kommen. Dagegen wappnet sich ein Unternehmen mithilfe von RAID 1 (Spiegelung) oder besser noch mit Backups und Recovery. Denn Backups lassen sich mithilfe von Snapshots feingranular einteilen und auf eine beliebige Anzahl von Failover-Sites verteilen. Das klappt alles ganz automatisch, doch sobald es um die Wiederherstellung (Disaster Recovery, DR) beschädigter, manipulierter oder gar verlorener Daten geht, erheben sich einige Hürden.

Jede Dauer des IT-Ausfalls (Downtime) kostet das Unternehmen nicht nur Geschäftstätigkeit und Geld, sondern auch Kundenzufriedenheit und Ansehen. Diese Beschädigung des Rufs hat wiederum Auswirkung auf die Kundenzufriedenheit und vor allem das Vertrauen der Kunden und Geschäftspartner. Die beste Methode, diesen negativen Folgen entgegenzuwirken, ist eine leistungsfähige, funktionierende und vor allem erprobte Disaster-Recovery-Strategie (DR-Strategie). So lässt sich die Downtime auf ein Minimum reduzieren. Mit den richtigen Tools kann diese Recovery Time Objective (RTO) exakt berechnet werden.

Was ist Disaster Recovery?

Neben dem Ersetzen nicht mehr verwendbarer IT-Infrastruktur meint Disaster Recovery (DR) vor allem die Datenwiederherstellung. Datensicherungen oder Backups sichern den Zustand eines kompletten IT-Systems inklusive aller Daten und Files. Snapshots hingegen sichern den Zustand eines Systems zu einem bestimmten Zeitpunkt.

Der Unterschied ist wichtig, denn ein Snapshot kopiert nicht alle Files, sondern nur die Einstellungen und

Metadaten, die nötig sind, um die Datensicherungen im Notfall wiederherzustellen. Die Quelldateien der Snapshots, die Backups, sollten sich an einem anderen Ort befinden als die Snapshots. Wendet man Replikation an, so werden die beiden Lokationen in enger Synchronisation gehalten. Das verkürzt die RTO ungemein.

RTO

Bei der Recovery Time Objective (RTO) handelt es sich um die Zeit, die vom Zeitpunkt des Schadens bis zur vollständigen Wiederherstellung der Geschäftsprozesse (Wiederherstellung von Infrastruktur – Wiederherstellung von Daten – Nacharbeitung von Daten – Wiederaufnahme der Aktivitäten) vergehen darf. Der Zeitraum kann hier von null Minuten (Systeme müssen sofort verfügbar sein) bis zu mehreren Tagen (in Einzelfällen Wochen) betragen.

Ein Snapshot ist in der Regel für kurzfristige Datenspeicherung geeignet, etwa in Entwicklungs- und Testumgebungen, Backups sind für längerfristiges Storage gedacht. Sobald die Speicherkapazität für Snapshots ausgeht, werden die ältesten Snapshots überschrieben. Besser für die zuverlässige Disaster Recovery sind also Backups.

RPO

Recovery Point Objective (RPO) ist die zweite wichtige Kennzahl, die es bei DR zu beachten gilt. Der Nutzer gibt an, wie viel Datenverlust in Kauf genommen werden kann. Bei der Recovery Point Objective handelt es sich um den Zeitraum, der zwischen zwei Datensicherungen liegen darf, das heißt: Wie viele Daten und Transaktionen dürfen zwischen der letzten Sicherung und dem Systemausfall höchstens verloren gehen? Wenn kein Datenverlust hinnehmbar ist, beträgt die RPO null Sekunden.

Drei Arten von Backup/DR

Um diese beiden Ziele zu erreichen, sollte man zwei Alternativen zu einem vollständigen Backup/DR in Betracht ziehen. Ein vollständiges Backup erfordert nicht nur die längste Sicherungsdauer, es beansprucht auch die vorhandenen Speicherkapazitäten maximal und verlängert den Wert für die RTO. Der Restore erfolgt hingegen relativ schnell, je nach Umfang der Backups. Wenn diese auf Tapes vorliegen, kann der DR-Vorgang länger dauern. Full Backup/DR ist also alles andere als ideal für Unternehmen mit geringen RTO/RPO-Vorgaben.

Inkrementelles Backup/DR

Diese Methode sichert Daten inkrementell, also auf Zuwachs. Nach einem ersten vollständigen Backup werden nur Daten gesichert, die seit diesem ersten Backup geändert wurden oder hinzugekommen sind. Auch die Wiederherstellung erfolgt inkrementell. Zunächst muss man die jüngste vollständige Sicherung wiederherstellen und anschließend jedes weitere Inkrement bis zum RPO-Punkt. Das kann eine geraume Zeit in Anspruch nehmen.

Differentielles Backup/DR

Nach einer ersten vollständigen Sicherung werden nur Inkremente mit geänderten Daten gesichert – siehe oben. Die Wiederherstellung erfolgt jedoch schneller, weil dabei „nur“ zwei Dateien nötig sind: das vorhergehende Full Backup und das jüngste differentielle Backup, das sämtliche Änderungen (Differenz) gegenüber dem Full Backup enthält.

DR-Test

Beim DR-Test mithilfe eines DR-Plans prüfen der IT-Admin oder ein Dienstleister (Cloud und so weiter), ob die ungetestete Backup/DR-Infrastruktur ihren Dienst wie vorgesehen versieht. Im negativen Fall muss der Test so lange wiederholt werden, bis alles fehlerfrei funktioniert.

Bei getesteten DR-Architekturen wird der Verantwortliche versuchen, die RTO- und RPO-Kennmarken so zu optimieren, dass sie erstens einen möglichst geringen Datenverlusten in Kauf nehmen und zweitens ein DR in möglichster kurzer Zeit (Downtime kostet) ermöglicht.

Was ist ein DR-Plan?

Ein Disaster-Recovery-Plan (DRP) ist ein durchgehend dokumentierter Ablauf oder eine Reihe von Maßnahmen, der prüfen soll, ob die DR-Prozesse zum Schutz der Daten und der IT-Infrastruktur im Notfall in der Praxis umsetzbar sind – und wie schnell. Nicht nur während eines Notfalls sind diese Maßnahmen zu beobachten, sondern auch vor und nach einem Ernstfall. Die Dokumentation ist von großer Bedeutung, weil Auditoren und Versicherungen danach suchen werden.

Ein Disaster-Recovery-Plan sollte fünf Schritte enthalten:

• 1. Prävention inklusive ordnungsgemäßer Backups und USVs,

• 2. Detektion, ein „Nebenprodukt“ von Routineinspektionen, bei der neue Bedrohungen zutage gefördert werden,

• 3. Beseitigung einer Bedrohung sowie Fehlerkorrektur,

• 4. Nachbesprechung: „lessons learned“,

• 5. Wiederholungen, bis alles reibungslos klappt.

Disaster-Recovery-as-a-Service (DRaaS)

Seit kurzem werden Recovery-Services in der Cloud bereitgestellt. Sie bieten nicht nur skalierbare Speicherkapazitäten, sondern auch die Möglichkeit, einen DRP online zu testen. Es gibt drei Architekturmodelle, die jeweils vom Standort der primären Quelle für eine produktive Anwendung oder allgemein für Quelldaten abhängen.

• 1. Disaster-Recovery-as-a-Service (DRaaS) in die Cloud: Die Quellanwendung befindet sich im primären Rechenzentrum des Nutzers, und die Cloud wird als Backup- und/oder DR-Ziel verwendet.

• 2. In-Cloud-DRaaS: Sowohl die Quelle als auch das Recovery-Ziel befinden sich an Cloud-Standorten.

• 3. DRaaS aus der Cloud: Die primäre oder die produktive Applikation beziehungsweise Datenquelle befinden sich in der Cloud, und das Ziel für ein Backup oder DR liegt in einem privaten Rechenzentrum.

Recovery-Testing mit DRaaS

Der große Vorteil der Cloud besteht in ihrer Skalierbarkeit und der flexiblen Buchung von Cloud-Ressourcen. Das ermöglicht die kostengünstige Nutzung von Sandboxes. Diese sind ein verbreitetes Leistungsmerkmal von DRaaS-Lösungen. Eine DRaaS-Sandbox wird aus Infrastrukturressourcen gebildet, in der eine Testkopie der von DRaaS geschützten Applikation platziert und geprüft werden kann.

Die Sandbox darf nicht auf das Netzwerk zugreifen und ist nur für den System-Admin zugänglich. Sie wird genutzt, um den Recovery-Vorgang der DRaaS-Lösung zu testen, ohne dabei die laufende Anwendung zu stören. Weil sich die Sandbox in der Cloud befindet, lassen sich ihre Ressourcen je nach Bedarf erstellen oder bereitstellen. Sie werden nur während der Nutzung bezahlt und nach Abschluss des Recovery-Tests „abgeschaltet“ beziehungsweise zurückgegeben.

Replikation

Um einen RPO-Wert von null zu erreichen, ist entweder ein hoher Sicherungsaufwand mit Snapshots nötig – oder eine entsprechende Lösung, die synchrone Replikation von Backup/DR-Servern über Netzwerke hinweg und mit Null-RTO unterstützt. Der Failover, nach dem das Replikat für die Disaster Recovery herangezogen werden kann, lässt sich beispielsweise mit Purity ActiveCluster beziehungsweise auf FlashBlade von Pure Storage realisieren. Der geeignete Anwendungsfall ist ein Workload mit sehr vielen Files und Objects. Das Storage-Betriebssystem muss für File- und Object-Storage ausgelegt sein, und das ist bei Purity 3.x der Fall.

Wichtiger Hinweis

Weil Ransomware-Attacken immer häufiger Backups angreifen, ist der ganze Vorgang von Disaster Recovery in Gefahr: ohne Backup keine Wiederherstellung. Die sicherste Methode zum Schutz der Backups ist die Unveränderbarkeit der Backup-Daten (immutable Backup). Ein Anbieter, der dies ermöglicht, ist AWS mit dem Leistungsmerkmal Object Lock.

(ID:47975864)