Mit Snapshot-Backups traditionelle Backups ablösen
Snapshot-Backups können nur bedingt traditionelle Backup-Systeme ersetzen. Aber indem beide Technologien zusammenarbeiten, lassen sich Vorteile für die IT erreichen.
Snapshot-basierte Backup-Systeme können die Spielregeln für alle ändern, die sie als ihre hauptsächliche Methode für Backup und Restore kritischer Daten benutzen wollen.
Snapshots liefern deutlich einfachere und schnellere Backups als jedes traditionelle Backup-System – mit Recovery Time Objectives (RTOs) und Recovery Point Objectives (RPOs), die mit einem traditionellen Backup-System niemals zu erreichen sind, das Ordner in ein Backup-Format umwandelt und dann das Format auf Band oder Festplatte ablegt.
Doch nicht alle Snapshot-Systeme sind gleich, und nicht alle von ihnen verfügen über das, was es braucht, um ein Backup-System komplett zu ersetzen. Mit diesem Artikel wollen wir zum Verständnis der Vor- und Nachteile von Snapshot-Backups beitragen, so dass Anwender ihre eigenen Entscheidungen darüber treffen können, ob sie diese Form von Backups für ihr Unternehmen einsetzen wollen oder nicht.
Es gibt Missverständnisse über Snapshot-basierte Backup-Systeme. Das hauptsächliche Missverständnis besteht darin, dass Storage-Snapshots eigentlich keine Backups sind – sie sind dagegen „Point-in-Time“-Kopien, Kopien zu einem bestimmten Zeitpunkt. Manche glauben, wenn eine Kopie von Daten nicht ihre Form ändert – zum Beispiel indem sie in einen Behälter oder ein Image gepackt wird –, dann ist dies kein Backup. Es ist nicht klar, woher diese Idee stammt, aber die Änderung der Form ist kein Erfordernis eines Backups.
Wie sind Snapshot-Backups definiert?
Die SNIA (Storage Networking Industry Association) definiert Backup auf diese Art: „Eine Kollektion von Daten, gespeichert auf einem (in der Regel entfernbaren) nicht-flüchtigem Speichermedium für Zwecke der Wiederherstellung, falls die ursprüngliche Kopie der Daten verloren geht oder nicht mehr zugänglich ist – auch eine Backup-Kopie genannt. Um für eine Wiederherstellung tauglich zu sein, muss ein Backup so gemacht werden, dass das Image der Quelldaten kopiert wird, wenn sich diese in einem konsistenten Zustand befinden.“ Der einzige Teil dieser Definition, mit dem Snapshot-basierte Backups ein Problem haben könnten, ist die Beschreibung als „in der Regel entfernbar“, aber dies verdankt sich einfach der Tatsache, dass einige Backups offensichtlich auf Tapes abgelegt werden.
Die Definition der SNIA betont einen wichtigen Aspekt von Snapshot-Backups: Ein Snapshot ist solange kein richtiges Backup, bis es nicht auf ein anderes Speichersystem repliziert ist. Das ist deshalb wichtig, weil ein Snapshot eine virtuelle Kopie der Daten und nicht eine wirkliche Kopie der Daten ist. Wenn etwas mit dem Volume passiert, zu dem ein Snapshot gehört, wird der Snapshot zwecklos sein – außer er wurde per Replikation in ein anderes Volume kopiert.
In einem traditionellen Backup-System sorgen Backup-Software, Festplatten und Tapes dafür, dass man Daten zu verschiedenen Zeitpunkten wiederherstellen kann. Dies stellt eine wesentliche Funktion eines Backup-Systems dar, da es Datenbeschädigung oder andere Faktoren erfordern können, das System zu einem bestimmten Zeitpunkt und nicht zur Zeit des allerletzten Backup wiederherzustellen. In einem Snapshot-basierten Backup-System übernehmen Snapshots diese Funktionalität. Mehrere Snapshots – jeder zu einem anderen Zeitpunkt erzeugt – dienen dazu, mehrere virtuelle Ansichten des File-Systems darzustellen, so wie es zu unterschiedlichen Zeitpunkten existiert hatte.
Eine andere wichtige Funktion eines Backup-Systems besteht darin, für den Fall einer Katastrophe eine Kopie der Daten zur Verfügung zu stellen. Ein traditionelles Backup-System erledigt diese Aufgabe, indem es ein Backup in die Cloud schickt oder Tapes außerhalb des Rechenzentrums bei einem Dienstleister wie zum Beispiel Iron Mountain einlagert. Ein Snapshot-basiertes Backup-System erreicht das gleiche Resultat mit Replikation.
Ein Snapshot-Backup-System kann mehrere Kopien der Daten per Replikation an unterschiedlichen Stellen ablegen. Zum Beispiel können die Wiederherstellungen von Daten auf betrieblicher Rechenzentrumsebene von einem lokalen Speichersystem kommen, das physisch verschieden ist von dem eigentlichen Backup des Speichersystems, während ein Disaster Recovery über ein offsite, also externes Speichersystem abgewickelt wird, das seine replizierten Daten von dem gleichen ursprünglichen System erhält. Dies kann erreicht werden, indem das primäre Speichersystem zu beiden Systemen repliziert oder indem es zuerst zu dem lokalen Speichersystem repliziert, das dann anschließend zu dem sekundären externen Speichersystem repliziert. Bei jedem Ansatz gibt es Vor- und Nachteile.
Der letzte Teil der SNIA-Definition von Backup handelt davon, dass sich die Daten in einem konsistenten Zustand befinden müssen, wenn sie kopiert werden. Bei traditionellen Backup-Anwendungen wird dies in der Regel mit File-Systemen und Datenbankagenten erledigt. Snapshot-basierte Backup-Systeme müssen ebenfalls herausfinden, wie sie die Kopierdaten in einen konsistenten Zustand bringen, damit die Backups auch etwas taugen.
Fehler mit Snapshot-Backups vermeiden
Es ist nicht akzeptabel, einfach einen Snapshot der Datenbank zu machen und später bei einem Crash der Datenbank anzufragen, ob man nicht während des Recovery das Image konsistent machen könne. Der Snapshot muss selbst in einer Art und Weise erzeugt werden, die von der Datenbank-Anwendung unterstützt wird. Ein Beispiel hierzu wären Snapshot-Systeme, die in Microsoft Volume Shadow Copy Service integriert sind, das als Verbindungsglied zwischen einem Snapshot-System und jenen Anwendungen fungiert, die in einen konsistenten Zustand versetzt werden sollen. Bevor man ein Snapshot-basiertes Produkt als Herzstück seines Backup-Systems bestimmt, sollte man sicher sein, dass das Produkt eine ausreichende Antwort auf diese besondere Anforderung besitzt.
Ein anderes Gebiet, auf dem Snapshot-Systeme oft versagen, ist Indexing. Einige Hersteller vermitteln den Eindruck, dass bereits der Befehl cd in irgendeinem Verzeichnis dazu ausreicht, eine bestimmte Datei auszuwählen. Und damit gäbe es keine Notwendigkeit mehr, für irgendeinen zentralen Backup-Katalog oder -Index, so wie ihn traditionelle Backup-Systeme verwenden. Während es stimmt, dass sich ein Snapshot-System irgendwie von selbst indexiert, ist es genauso richtig, dass Anwender manchmal nicht den Ort der Datei wissen, die sie wiederherstellen müssen – ein Backup-Katalog würde hier seine Dienste anbieten. Bei einigen Produkten könnte diese Funktionalität heute durch die Verbindung von einem traditionellen Backup-Produkt mit einem Snapshot-basierten Produkt hergestellt werden. Einige traditionelle Produkte bieten Indexierung von Snapshot-basierten Backups mit dem Network Data Management Protocol an.
Während Snapshots einerseits einen schnellen und leichten Datenzugang liefern und Funktionen wie zum Beispiel Instant Recovery unterstützen, nehmen sie auf der anderen Seite eine Menge an Speicherkapazität in Anspruch.
Sicher stellen, dass das Snapshot-Backup skalieren kann
Konfiguration, Monitoring und Reporting spielen eine wichtige Rolle in einem Snapshot-Backup. Was in einer kleinen Firma mit einem einzigen Speichersystem funktioniert, wird nicht auf die gleiche Weise in einem Unternehmen mit hunderten oder tausenden solcher Systeme funktionieren. Wenn man diese Funktionen und die Fähigkeit zu wachsen überprüft, sollte man sicher sein, welche besonderen Produkte in der Lage sind, entsprechend auf das drastische Wachstum eines Rechenzentrums im Lauf der Zeit zu reagieren. Manche Systeme erfordern es, Snapshot- und Volume-Aufgaben über die Kommandozeile zu organisieren, während andere über ausgefeilte webbasierte graphische Oberflächen verfügen, um einem diese Arbeit abzunehmen.
Die wichtigste Frage, die jeder Backup-Administrator jeden Tag beantworten muss, lautet: Funktionierten die Backup-Systeme? Größere Firmen werden sogar eine Mannschaft von IT-Leuten haben, die die Backups bei ihrer Durchführung beobachten, und kleinere Firmen werden einen einzelnen Mitarbeiter haben, der morgens als erstes die Backups der letzten Nacht kontrolliert. Egal auf welchem Weg dies geschieht, das Monitoring des Backup-Systems muss in der Lage sein, diese Frage schnell und effizient zu beantworten.
Reporting ist etwas unterschiedlich, da es dazu beiträgt, Backup-Trends über längere Zeiträume hinweg zu verstehen. Gibt es bestimmte Volumes, bei denen es Schwierigkeiten gibt, regelmäßig ein Backup durchzuführen? Gibt es genügend Kapazität für Snapshots und produktive Daten? Gibt es bestimmte Snapshots, die deutlich mehr Platz beanspruchen als andere Snapshots? Solche Fragen lassen sich durch die Reporting-Funktionen des Produkts beantworten.
Schließlich muss man auch bedenken, ob man seine traditionellen Backup-Systeme durch ein Snapshot-System ersetzen will, wobei die ersteren meistens Host-basiert und die letzteren meistens Storage-basiert sind. Das signifikante Wachstum an virtuellen Maschinen (VMs) auf Server- und Storage-Ebene steigert die Schwierigkeit, Storage-basierte Backups durchzuführen. In einer Umgebung, in der ein Server sich wie magisch mit einem einzigen Mausklick von einem physischen Server und dem mit ihm verbundenen Storage zu völlig verschiedenen Server- und Storage-Ressourcen bewegen kann, sind Host-basierte Backups der einfachste Weg, damit für den Server – in Wirklichkeit eine VM – ein Backup durchgeführt wird, egal wo er sich auch befindet. Bei Storage-basierten Backups muss für so einen Fall ein Account aufgemacht werden.
Unter bestimmten Umständen ist es möglich, ein Backup-System und seine ganzen Funktionen vollständig durch ein Snapshot-basiertes System zu ersetzen. Allerdings sollte man abklären, ob alle Aufgaben, die ein Backup-System heute übernimmt, von einem Snapshot-System in gleicher Weise ausgeführt werden können.
Kommentar: Snapshots als Backup-Ersatz?
Es ist wichtig zu betonen, dass es nach der ursprünglichen Veröffentlichung dieses Artikels zahlreiche Stellungnahmen zum Thema Snapshots gegeben hat und dass sie kein angemessener Ersatz für Backup-Systeme seien. Einige Experten haben argumentiert, dass Snapshots eine gute Ergänzung zu Backup sind und in den allgemeinen Prozess von Data Protection integriert werden sollten.
Während Snapshots einerseits einen schnellen und leichten Datenzugang liefern und Funktionen wie zum Beispiel Instant Recovery unterstützen, nehmen sie auf der anderen Seite eine Menge an Speicherkapazität in Anspruch, was zu Lasten der Performance gehen kann. Ein Snapshot ist keine vollständige Kopie von Daten, wodurch er kein komplettes Abbild in einer Recovery-Situation liefert. Ein Snapshot hängt außerdem von den Quelldaten ab, womit er im Fall eines Datenverlusts nicht richtig funktionieren könnte – obwohl der Einsatz von Replikation bei diesem Problem helfen kann.
Der Storage-Experte George Crump betont, dass es keinen global gültigen Snapshot-Standard gibt, so dass der Snapshot eines Herstellers unter Umständen nicht kompatibel mit dem eines anderen Herstellers ist. Das kann beim Managing von Snapshots zu vermehrten Workloads führen.
Crump gibt auch zu bedenken, dass die Suche über mehrere Snapshots hinweg kompliziert sein kann. Das sollte man mit den top Backup-Produkten von heute vergleichen, die über umfassende Such- und Indexierungs-Tools verfügen.
Jedoch können Snapshots und Backup mindestens gut zusammenarbeiten als Teil einer übergreifenden Plattform für Data Protection.
