Es gibt immer ein Zurück: vier Disaster-Recovery-Lösungen

Ein Problem bei gewöhnlicher Backup-Software ist die Tatsache, dass die Anwendungen offline sein müssen, um eine Sicherung durchführen zu können. Das ist in Ordnung, wenn ein Unternehmen nur zu den üblichen Geschäftszeiten arbeitet, aber in vielen Fällen müssen die Systeme rund um die Uhr laufen, weshalb es keine Möglichkeit zum Herunterfahren der Anwendungen gibt.

Um dieses Problem zu umgehen, gibt es neue inkrementelle beziehungsweise Snapshot-Backup-Technologien, die Datei- oder Block-basiert sind und im Hintergrund laufen, während das System voll funktionsfähig bleibt. Die Idee dabei ist, dass im Falle von Änderungen an Daten nur diese Änderungen gespeichert werden.

Die Snapshots können zum Beispiel im Abstand von 15 Minuten erfolgen, so dass man im schlimmsten Fall die Daten der letzten 15 Minuten verliert. Einige Anbieter bieten „Echtzeit“-Snapshots der Daten an, sobald Änderungen vorgenommen werden; solche Snapshots sind alle mit einem Zeitstempel versehen – tritt ein Problem auf, kann man einfach zurückgehen bis zum letzten Schritt vor Eintritt des Problems. Das ist zum Beispiel bei bösartigen Virus-Attacken sehr praktisch, da man den genauen Zeitpunkt feststellen kann, zu dem der Virus das System befallen hat, um so bis zu den nicht infizierten Daten zurückgehen zu können.

Wie erstellt man Komplettsicherungen oder auch Snapshots von Anwendungen, die nicht heruntergefahren werden können?

Eine einfache Lösung besteht in einer Spiegelung der Anwendung. Während die Anwendung auf einem Datenträger läuft, kann der gespiegelte Datenträger offline gehen, um von ihm eine Sicherung zu erstellen. Geht die Spiegelanwendung wieder online, muss sie natürlich anhand der gespiegelten Version synchronisiert werden. Da man für die Synchronisierung von 1 TByte an Daten rund 16 Stunden benötigt, kann das zu erheblichen Wartezeiten führen. Allerdings kann auch eine kleine „Resync“-Datei erstellt werden, die einfach nur die Änderungen verfolgt, die auftreten, während der Spiegel offline ist. So kann der Spiegel in einem Bruchteil der Zeit aktualisiert werden.

Sowohl Datei- als auch Block-basierte inkrementelle Sicherungen haben gewisse Vor- und Nachteile. Datei-basierte Sicherungen sind von ihrer Art her größer als Block-basierte Backups, aber das Aufspielen eines Datei-basierten Backups ist in der Regel weniger aufwändig und kann zuweilen schneller gehen, wenn man nur eine bestimmte Datei benötigt.

Testkriterien

Interoperabilität:
Ist die Software in der Lage, Backups von verschiedenen Betriebssystemen, Datenbanken und sonstigen Anwendungen zu erstellen?

Zukunftsfähigkeit:
Ist die Software erweiterungsfähig, so dass sie sich an wachsende Umgebungen anpassen kann?

ROI:
Rechtfertigt der Zugewinn an Produktivität durch den Einsatz der Software deren Preis?

Service:
Welche Optionen stehen für Service und Support zur Verfügung und wie viel kosten diese?

Themenseiten: Security-Praxis

Fanden Sie diesen Artikel nützlich?
Content Loading ...
Whitepaper

Artikel empfehlen:

Neueste Kommentare 

2 Kommentare zu Es gibt immer ein Zurück: vier Disaster-Recovery-Lösungen

Kommentar hinzufügen
  • Am 5. Februar 2004 um 22:46 von cst

    Es gibt immer ein Zurück: vier Disaster Recovery Lösungen
    man hat beim Lesen der Artikel absolut nicht den Eindruck das der Autor von dem Thema wirklich etwas versteht, geschweige denn Ahnung von den am Markt erhältlichen Produkten hat.

  • Am 6. Februar 2004 um 16:16 von Gilbert Diedrichs

    Disaster Recovery Lösungen
    Nur auf der letzte Seite geht der Autor auf die Besonderheit "Disaster" ein, insgesamt ist die Betrachtung noch zu idealistisch.
    Es beginnt damit, dass ein Unternehmen ohne Not keinen leistungsfähigen Server in Reserve vorhält – die Lieferzeit für vernünftige Server liegt ohne besonderen Vertrag im Bereich von Tagen. Dann muss ein Notfall-Szenario davon ausgehen, dass mehr als nur ein Server nicht verfügbar ist, evtl. das gesamte RZ oder Gebäude. Also muss auch das Datensicherungslaufwerk neu beschafft werden, bei Tapes mit dem gleichen Formfaktor!
    Wenn nur ein einzelner Server ausfällt entstehen bei den üblichen vernetzten Applikationen Inkonsistenzen durch die Recovery eines einzelnen Systems.
    Als Faustregel gilt, dass alles, was nicht in einem echten vollständigen Test überprüft wurde, nicht funktioniert. Aus meiner Praxis weiss ich, dass viele Datensicherungen auf Band nicht nutzbar sind, weil Dateien oder ganze Bänder nicht lesbar sind, bzw. neuere Dateien nicht in den Backup-Plan aufgenommen wurden. Das heisst, ein Notfallplan muss umfassend sein, vom GAU ausgehen und jedes Jahr mindestens einmal im Test simuliert werden.
    Insgesamt ist die Ausfallzeit selbst bei kleinen Notfällen erheblich länger als man sich vorstellt und echte Notfälle in Firmen ohne Notfallplanung führen in mehr als der Hälfte der Fälle zum Untergang des Unternehmens. innerhalb von 12 Monaten (Versicherungsaussagen).

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *