Traditionelle Backup-Software und Lösungen für Backups über Snapshots

Fast-kontinuierliche Datensicherung Near-CDP funktioniert über Volume-Snapshots. Der Volume Shadow Copy Service (VSS) bietet die notwendige Technik.

Ihre Prozesse für Daten-Backups zu steuern, als traditionelle Software für Backup und Wiederherstellung. Auch bekannt als fast-kontinuierliche Datensicherung (Near-CDP), sind Snapshot-Backups eine gute Sache, wenn Ihre Recovery Point Objectives (RPOs) in Sekunden oder Minuten gemessen werden.

In diesem Tutorial über Backup-Software mit Snapshots erklären wir Near-CDP und Snapshots, „redirect-on-write“-Snapshots und wie sich Snapshot-Daten wiederherstellen lassen.

TUTORIAL ÜBER BACKUP-SOFTWARE MIT SNAPSHOTS: INHALT

  • Near-CDP: Snapshots und Replikation
  • CDP vs. Near-CDP
  • Nicht alle Snapshots sind gleich
  • Zwei Schwierigkeiten mit „redirect-on-write“-Snapshots
  • Diese Pose bitte halten
  • Wiederherstellung von Snapshot-Daten

Near-CDP: Snapshots und Replikation

Systeme für fast-kontinuierliche Datensicherung kümmern sich um Snapshots und Backups auf der Basis von Replikation. Sie sind sehr effizient, denn wie echte CDP-Systeme übertragen und speichern sie nur neue Daten-Blöcke. Die Änderungen („Deltas“) lassen sich leicht auf dem Primär-System speichern und für Backup-Zwecke auf ein sekundäres System replizieren.

Der eigentliche Wert von Near-CDP zeigt sich bei einer Wiederherstellung. Ihr RPO, also der maximal mögliche Zeitraum, aus dem Daten verloren sind, lässt sich in Minuten messen. Das Recovery Time Objective (RTO) wiederum hängt hier davon ab, wie lange es dauert, betroffene Anwendungen vom primären Storage-System auf das sekundäre umzustellen.

CDP vs. Near-CDP

Wann ist kontinuierlich nicht wirklich kontinuierlich? In der echten Welt ist diese Definition recht einfach, aber bei der Unterscheidung zwischen CDP und Near-CDP wird es etwas verschwommen. Die Storage Networking Industry Association (SNIA), ein wichtiger Verband der Storage-Branche, bietet eine Definition von CDP an:

„Kontinuierliche Datensicherung (CDP) ist eine Verfahrensweise, bei der Daten-Modifikationen kontinuierlich erfasst oder nachverfolgt werden; Änderungen werden unabhängig von den primären Daten gespeichert, was beliebige Zeitpunkte in der Vergangenheit als Recovery Points zulässt.“

Ein echtes CDP-System erfasst jede Änderung an jedem Datenstück, sobald sie auf ein Laufwerk geschrieben wird und repliziert sie sofort auf ein anderes System. Near-CDP hat eine ähnliche Funktion, arbeitet aber nur periodisch, also etwa alle 15 oder 30 Minuten – nicht wirklich kontinuierlich. Allerdings sind RTOs und RPOs trotzdem sehr nah an dem, was CDP bietet, also wird hier gern von Near-CDP gesprochen. Offiziell ist die Bezeichnung von der SNIA aber nicht anerkannt.

Nicht alle Snapshots sind gleich

Wenn Sie eines der führenden Software-Produkte für Backups verwenden, sollten Sie dessen Hersteller fragen, wie er mit der Near-CDP-Funktionalität umgeht. Bei manchen ist sie vollständig im Produkt enthalten. Meistens aber wird sie erreicht, indem auf die Möglichkeiten für Snapshot-Replikation von Systemen für Storage oder Virtualisierung zugegriffen wird.

Wenn Sie sich bei der Aufbewahrung historischer Daten komplett auf Snapshots verlassen, müssen Sie darauf achten, dass Dutzende oder Hunderte von Snapshots die Performance Ihres Storage-Systems nicht beeinträchtigen. Die Sinnhaftigkeit eines Snapshot-basierten Backup-Systems hängt damit stark davon ab, welche Art von Snapshots Ihr Storage-System zu bieten hat.

Der verbreitetste Snapshot-Typ sind „copy-on-write“-Snapshots. Dabei wird ein Block vor dem Überschreiben erst einmal kopiert. Meist wird die vorige Version eines Blocks komplett auf ein anderes Volume kopiert, mit dem Vorteil, dass die Struktur des Quell-Volumes unverändert bleibt. Man könnte meinen, dass dies Performance-Vorteile hätte, doch das Gegenteil ist der Fall, denn jeder Schreib-Vorgang erfordert dann drei separate I/O-Operationen: Lesen des alten Blocks, Schreiben des alten Blocks und dann Schreiben des neuen Blocks.

Mit der Zeit kann dies zu erheblichem Nachlassen der Performance des primären Storage-Systems führen. Aus diesem Grund werden „copy-on-write“-Snapshot-Systeme für diesen Zweck nur extrem selten eingesetzt. Meist werden sie nur benutzt, um ein stabiles Image als Quelle für ein anderes Backup-System zu erstellen. Dabei kann es sich zum Beispiel um ein traditionelles Backup-System handeln, mit dem das Snapshot-Volume kopiert wird, oder um ein fortschrittlicheres System, das den Snapshot auf ein anderes Storage-System repliziert.

Wenn die Snapshots repliziert werden, haben Sie die Möglichkeit, nur sehr wenige auf dem primären System zu belassen, weil alle vorigen auf dem sekundären gespeichert sind. Dadurch wird die Performance-Belastung durch Snapshots auf dem primären System minimiert, während für Wiederherstellungen trotzdem die historischen Versionen vorhanden sind. Wenn Sie ein „copy-on-write“-Storage-System verwenden und auf Backups nach dem Prinzip Near-CDP umstellen wollen, sollten Sie die Zahl der Snapshots auf dem primären Volume begrenzen.

Redirect-on-write“ ist ein weniger verbreiteter Snapshot-Typ. Bei diesem wird der neue Block an einen anderen Ort geschrieben, und der alte bleibt an seinem Platz. Der Vorteil dabei: Zur Aktualisierung eines Blocks ist nur ein I/O-Vorgang erforderlich (gegenüber drei bei copy-on-write). Aus diesem Grund können Storage-Systeme nach diesem Snapshot-Prinzip Dutzende oder Hunderte von Snapshots speichern, ohne dass die Performance erkennbar nachlässt. Und genau dieses Feature macht „redirect-on-write“-Snapshots zur besten Methode für die Verwendung in einem Backup-System mit Near-CDP.

Zwei Schwierigkeiten mit „redirect-on-write“-Snapshots

Allerdings haben auch „redirect-on-write“-Snapshots zwei Nachteile. Erstens werden alle Blöcke – aktuelle wie frühere Versionen – auf demselben Volume gespeichert. Mit der Zeit kann das dazu führen, dass die aktuellen Versionen der Blöcke eines Volumes fragmentiert werden. Fragen Sie unbedingt den Anbieter, dessen Produkt Sie in Erwägung ziehen, wie er mit diesem grundlegenden Problem bei solchen Snapshots umgeht.

Der zweite Nachteil von „redirect-on-write“-Snapshots ist deutlich gefährlicher: Durch die historischen Versionen von Blöcken kann die Kapazität des Volumes schlicht erschöpft werden, so dass bis zu einer Korrektur keine weiteren Schreib-Vorgänge mehr möglich sind. „Copy-on-write“-Systeme umgehen dieses Problem, indem sie frühere Versionen auf andere Volumes schreiben. Wenn das historische Volume voll ist, endet nur die Aktualisierung von Snapshots – das Volume mit den aktuellen Versionen bleibt verfügbar.

Durch die Unterbringung von aktuellen und historischen Blocks auf demselben Volume bei „redirect-on-write“-Snapshots kann es dabei aber eben passieren, dass die Kapazität des Volumes durch die historischen Blöcke ausgeschöpft wird. Aus diesem Grund müssen Nutzer dieses Ansatzes darauf achten, zusätzlichen Speicherplatz in Reserve zu halten – und ständig die Volumes daraufhin beobachten, ob sie noch genügend Kapazität für Änderungen haben. Je mehr Blöcke sich ändern und je häufiger, desto mehr Platz werden Sie für Snapshots brauchen.

Anbieter, die keine „redirect-on-write“-Snapshots im Programm haben, nutzen diese Nachteile zur Verbreitung von „Angst, Unsicherheit und Zweifel bei potentiellen Kunden. Glauben Sie dem nicht, sondern verifizieren Sie die Informationen.

Der erste potentielle Nachteil – die Fragmentierung – lässt sich leicht vorab testen: Prüfen Sie die Performance vor und nach der Erstellung von Dutzenden oder Hunderten Snapshots – natürlich erst, nachdem Sie Tausende Blöcke aktualisiert haben.

Der zweite mögliche Nachteil ist durchaus ernst zu nehmen und muss im Auge behalten werden. Wenn Ihnen wegen Ihrer Snapshot-Daten der Platz ausgeht, wird Ihr Volume nicht mehr aktualisiert, und Ihre Anwendung stürzt ab. Wenn Sie keine Erfahrungen mit dieser Art von Snapshots haben, richten Sie sich nach den konservativsten Schätzungen des Technik-Lieferanten zum nötigen Reserve-Platz. Anschließend können Sie beobachten, wie viel Platz die Snapshots tatsächlich erfordern, und so zu einer besseren Abschätzung des Bedarfs in Ihrer Umgebung kommen. Wenn Sie dabei sorgfältig vorgehen, kann Ihnen im Prinzip schlimmstenfalls passieren, dass Sie mehr Snapshot-History löschen müssen, als Sie wollten, um Ihr Volume funktionsfähig zu halten.

Diese Pose bitte halten

Strukturierte Daten jeglicher Art erfordern eine spezielle Behandlung, bevor ein Snapshot des Volumes erstellt werden kann, auf dem sie sich befinden. Ohne diese Besonderheit wird Ihre Anwendung nach einer Wiederherstellung zumindest in den „Crash Recovery“-Modus gehen; möglicherweise wird ein bestimmter Snapshot auch völlig unbrauchbar für eine Wiederherstellung. Beschäftigen Sie sich deshalb genau damit, wie Sie Ihre Anwendung vor dem Anlegen eines Snapshots richtig vorbereiten.

Windows löst dieses Problem mit dem Volume Shadow Copy Service (VSS). Ein Backup-System, das einen Snapshots eines Volumes nehmen möchte, muss diese Absicht dabei nur dem VSS mitteilen (dazu muss es als VSS-Requestor agieren können). VSS stellt dem Requestor dann eine Liste der Anwendungen zur Verfügung, die vor einem Snapshot eine VSS-Intervention erfordern. Anschließend kommuniziert der Requestor mit dem VSS-Writer mit jeder dieser Anwendungen. Wenn diese vorbereitet sind, fordert der Requestor VSS zum Anlegen des Snapshots auf, wofür dann Windows selbst oder eines der oben genannten Systeme für Storage oder Virtualisierung zum Einsatz kommt. Nach der erfolgreichen Snapshot-Erstellung kann der Requestor unterstützte Anwendungen über den VSS-Writer darüber informieren, dass ein Backup erstellt wurde. Dadurch können sie beispielsweise auch ihre Transaktionsprotokolle trunkieren.

Leider gibt es für Unix- oder Linux-Betriebssysteme keine solche VSS-Funktionalität (oder ein gleichwertiges Äquivalent). Wenn Sie also Snapshot bei Unix-Systemen nehmen wollen, brauchen Sie eine Anwendung, die dieselben Schritte erledigt. Oder Sie müssen ein Script schreiben, das direkt mit den Anwendungen kommuniziert.

Wiederherstellung von Snapshot-Daten

Near-CDP-Systeme bieten eine Reihe von Möglichkeiten zur Wiederherstellung. Bei der verbreitetsten werden historische Versionen von Dateien als Unterverzeichnis unter dem Ursprungsverzeichnis zugänglich gemacht. Wenn eine davon gebraucht wird, kann der Nutzer mit seinem Datei-Browser einfach das entsprechende Verzeichnis aufrufen, die Datei lokalisieren und sie dann verwenden.

Eine andere Art der Wiederherstellung kommt zum Einsatz, wenn ein Nutzer eine Datei sucht und nicht recht weiß, wo oder wann er sie zuletzt gesehen hat. Bei traditionellen Backup-Produkten ist das sehr einfach, weil die über eine Datenbank verfügen, in der die Standorte aller Dateien samt ihren früheren Versionen festgehalten sind. Die meisten Storage-Systeme mit Near-CDP jedoch bieten diese Möglichkeit nicht. Das ist einer der Gründe dafür, warum viele Organisationen traditionelle Backup-Produkte nutzen, um ihre Near-CDP-Backups zu steuern und Berichte darüber zu bekommen. Abhängig vom verwendeten Backup-Produkt lässt sich so ein Katalog aller von diesem kontrollierten Snapshots erstellen, den Sie bei Wiederherstellungen durchsuchen können.

Am wertvollsten werden Systeme für Near-CDP, wenn Sie ein komplettes Volume oder ein Verzeichnis mit den virtuellen Festplatten-Volumes von virtuellen Maschinen verlieren. Es ist relativ einfach, NFS- oder CIFS-Clients auf einen anderen Server zu verweisen oder eine VM von einem anderen Speicherort aus einzubinden, auch wenn beides meist manuell erfolgen muss. In solchen Fällen zahlt sich Near-CDP wirklich aus, denn damit können Sie diese „Wiederherstellung“ in wenigen Augenblicken vornehmen statt in mehreren Stunden. Wenn dann das Problem mit dem Produktiv-Volume gelöst ist, können Sie eine umgekehrte Wiederherstellung vom Backup-System auf das primäre machen und anschließend wieder mit dem primären System arbeiten. Wenn Sie einmal erlebt haben, wie einfach das ist, werden Sie nie wieder zurück wollen.

Als letzter Punkt ist es wichtig, dass Sie Erfolge und Scheitern Ihrer Near-CDP-Backups überwachen und in Berichten festhalten. Diese Funktionalität kann von Ihrem Storage-Anbieter kommen, eher aber vom Hersteller der Backup-Software oder dessen Partnern. Dies ist ein weiterer Grund dafür, warum Sie darüber nachdenken sollten, Ihre Near-CDP-Backups über ihre Backup-Software zu steuern – selbst wenn sie dann fast nur als Verkehrspolizist agiert. Denn es ist immer eine gute Sache, die gesamte Backup-Funktionalität an einem Ort zu haben.

Machen Sie sich nicht zu hastig an ein Projekt für Near-CDP. Prüfen Sie die Möglichkeiten der unterschiedlichen Produkte und machen Sie Tests, bevor Sie einen Kaufvertrag unterschreiben. Und denken Sie daran: Ihr bestehendes Backup-System bietet wahrscheinlich eine Reihe von Vorteilen wie zentralisierte Zeitplanung, Katalog-Funktion, Monitoring und Reporting. Sorgen Sie dafür, dass diese nicht verlorengehen, wenn Sie Ihr schickes neues System für Near-CDP installieren.

Über den Autor: W. Curtis Preston ist ein unabhängiger Backup-Experte. Er hat sich intensiv mit Daten-Deduplizierung und anderen System zur Daten-Reduktion beschäftigt. 

Artikel wurde zuletzt im März 2011 aktualisiert

Pro+

Premium-Inhalte

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

Erfahren Sie mehr über Backup-Tools

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchNetworking.de

SearchEnterpriseSoftware.de

SearchDataCenter.de

Close