Interview mit „Mr. Backup“ W. Curtis Preston Was ist der Unterschied zwischen einem Snapshot und einer Kopie?

Redakteur: Nico Litzel

W. Curtis Preston, unabhängiger Backupexperte, erklärt im Gespräch mit Storage-Insider.com den Unterschied zwischen Kopien und Snapshots und erläutert, für welche Backup-Szenarien beide Verfahren jeweils geeignet sind.

Firmen zum Thema

W. Curtis Preston, auch bekannt als „Mr. Backup“
W. Curtis Preston, auch bekannt als „Mr. Backup“
( Archiv: Vogel Business Media )

Storage-Insider.com: Worin unterscheiden sich Kopien von Snapshots?

Preston: Snapshots und Datenkopien unterscheiden sich insofern voneinander, dass die einen virtuell und die anderen physisch sind. Ein Snapshot ist eine virtuelle Kopie, also ein Foto oder eine Momentaufnahme der Daten.

Unter einer Kopie versteht man hingegen eine physische Kopie der Daten, die auch Business Continuance Volume, kurz BCV, oder Split Mirror genannt wird, da die Daten zunächst gespiegelt und dann für die Kopie gesplittet werden. Snapshots und Kopien belegen auch unterschiedlich viel Speicherkapazität. Ein Snapshot belegt im Moment seiner Erstellung überhaupt keinen Platz, er wächst im Laufe der Zeit. Da eine Kopie jedoch physischer Natur ist, steigen Ihre Speicheranforderungen mal eben um das Doppelte, wenn Sie eine Kopie Ihrer Daten erstellen wollen.

Storage-Insider.com: Sind Snapshots für jedermann geeignet? Was muss ich tun, wenn ich dieses Verfahren in meiner IT-Umgebung einsetzen möchte?

Preston: Meiner Meinung nach sind Snapshots für jeden geeignet – allerdings müssen Anwender hierbei einiges beachten. Administratoren, die Snapshots in ihrer Backup-Umgebung einsetzen möchten, müssen einige Herausforderungen meistern, die im Zusammenhang mit Snapshots auftreten können. So muss etwa der richtige Snapshot-Typ verwendet werden und die Daten sollten zunächst in den richtigen Zustand versetzt werden, ehe Snapshots erstellt werden. Außerdem braucht man etwas, mit dem man den Snapshot-Prozess kontrollieren und konfigurieren kann und mit dem man Berichte erstellen kann.

Storage-Insider.com: Welche Herausforderungen können bei der Datensicherung per Snapshot auftreten?

Preston: Die erste Herausforderung besteht darin, dass viele nicht begreifen, dass Snapshots eine virtuelle Kopie sind und dann versuchen, von diesen nach einem Ausfall einen Restore zu machen. Nehmen wir beispielsweise mal an, dass Sie ein RAID-5 Array haben und in diesem zwei Festplatten ausgefallen sind. Dann nehmen Sie Ihren Snapshot und machen anhand dessen einen Restore. Allerdings ist dieser hierfür ungeeignet, da er sich ja auf das ursprüngliche Storage-Array bezieht.

Weiter mit: Snapshot ist nicht gleich Snapshot

Preston: Die zweite Herausforderung ist, dass Snapshot nicht gleich Snapshot ist. Man muss sich zwischen zwei Haupttypen von Snapshots entscheiden: Copy on Write und Redirect on Write. Beide Verfahren haben jeweils ihre Vor- und Nachteile. Bei Copy on Write braucht man ein eigenes Laufwerk für die History-Daten der Snapshots, während bei Redirect on Write das gleiche Laufwerk für die History-Daten verwendet wird. Da bei Copy on Write die History-Daten auf einem eigenen Volume liegen, muss man nur ein paar Snapshots löschen, wenn das Snapshot-Laufwerk voll ist. Wenn man hingegen bei Redirect on Write das Laufwerk mit Snapshot-History-Daten anfüllt, dann wirkt sich das auch auf das primäre Laufwerk aus.

Ein weiterer großer Unterschied zwischen Copy und Redirect on Write ist die Performance. Redirect-on-Write-Snapshots haben eine deutlich bessere Performance, wenn man viele von ihnen erstellt. Copy-on-Write-Snapshots werden am besten dazu verwendet, eine stabile virtuelle Kopie von dem Laufwerk zu erstellen, das man sichern möchte. Sie müssen sich immer den eingesetzten Typ von Snapshots bewusst machen, wenn Sie Überraschungen vermeiden möchten. Wenn Sie Daten jeweils über Wochen oder Monate hinweg aufbewahren möchten, dann sollten Sie lieber Redirect-on-Write-Snapshots verwenden.

Die dritte Herausforderung, die im Zusammenhang mit Snapshots auftreten kann, ist auf die Daten selbst zurückzuführen. Man sollte nicht von solchen Daten ein Snapshot ziehen, die nicht bereit sind, fotografiert zu werden. Sie müssen zunächst dafür sorgen, dass Ihre Daten für das Foto stillstehen. Das ist kein großes Problem bei den unstrukturierten Daten, wohl aber bei strukturierten. Man muss zunächst jede Datenbank in den Backup-Modus versetzen, ehe man einen Snapshot erstellt. Wenn Sie das nicht machen, so werden zwar die meisten Backups und die meisten Restores funktionieren, aber bisweilen kann es vorkommen, dass Ihre Datenbank einen Restore erhält, den sie nicht erfolgreich wiederherstellen kann. Wenn Sie keinen Snapshot erstellen, werden Sie Ihre Anwendung dazu zwingen, in den Crash-Recovery-Modus zu gehen, was allerdings nicht immer funktioniert. Schließlich müssen Sie die Daten an einen anderen Ort kopieren, was bedeutet, dass Sie ausreichend Bandbreite sowie ein weiteres Speichersystem brauchen werden.

Weiter mit: In welchen Bereichen könnte man noch Snapshots einsetzen?

Storage-Insider.com: Gemeinhin wird angenommen, das Erstellen von Snapshots ist eine Funktion von Speichersystemen. Das ist allerdings nur ein mögliches Einsatzgebiet. In welchen Bereichen könnte man noch Snapshots einsetzen?

Preston: Das ist eine Glaubenssache, würde ich mal sagen. Die meisten erstellen Snapshots auf ihren Speichersystemen und hier hatten sie auch den größten Erfolg. Aber wie auch bei RAID und Volume Managers, so kann man Snapshot-Funktionen im Speicherarray machen, einem Virtualisierungssystem, das in einem SAN zwischen Storage Array und dem Host sitzt, oder innerhalb der Volume Management Software im Host. Wo werden Snapshots am besten erstellt? Diese Frage werden wir nicht beantworten können. Das ist echt eine Virtualisierungsfunktion, von daher stellt sich eher die Frage, an welcher Stelle sich das Unternehmen entschieden hat, zu virtualisieren.

Storage-Insider.com: Wenn Snapshots so fantastisch sind, warum haben sie dann bisher das Backup nicht revolutioniert?

Preston: Zunächst einmal würde ich sagen, dass sie das Backup für viele revolutioniert haben. Schauen Sie sich beispielsweise EMC und NetApp an. Wenn man mit NetApp spricht, dann sind Snapshots fantastisch und sie verkaufen einem mit Nachdruck, dass Tape Backups oder selbst traditionelle Backups alt sind, und ich tendiere dazu, dem zuzustimmen. Wenn man NetApps Kurs und dem vergleichbarer Hersteller folgt, so wird man ihre Erfolgsgeschichten rund um Snapshots und Datenreplizierung zu hören kriegen, und von daher braucht man keine herkömmlichen Backups mehr. Wenn man allerdings EMC und andere Hersteller betrachtet, so werden diese eine ganz andere Geschichte erzählen, da sie die Copy-on-Write-Technik verwenden. Sie können Snapshots nicht im gleichen Maße einsetzen. Man kann Snapshots zwar auch in EMC-Systemen verwenden und wirksam einsetzen, aber nicht in dem Maße wie bei NetApp. Das ist Teil des Problems – hier gibt es Widersprüche und nicht jeder kann auch die Snapshots erstellen, von denen ich spreche.

Ein weiterer Grund, warum Snapshots das Backup noch nicht revolutioniert haben, ist, dass Fortschritt im Bereich Backup und Recovery im Schneckentempo abläuft. Leute, die für das Backup verantwortlich sind, sind von Natur aus paranoid. Sie bewahren von allem eine Kopie auf und sind eher etwas langsam, wenn es darum geht, neue Verfahren einzusetzen. Zwar verstehe und respektiere ich das, aber irgendwann muss mal jemand die neuen Verfahren auch unter die Lupe nehmen und sagen, „Hey, wir müssen unsere Backupsysteme revolutionieren und sie nicht nur weiterentwickeln“. Das könnte dann allerdings bedeuten, den Speicherhersteller wechseln zu müssen. Das kann auch bedeuten, dass man eine Menge Arbeit im Voraus hat, das zu testen. Das ist aber kein Sprung ins kalte Wasser, die Zeit ist reif. Das sind die Hauptgründe, warum Snapshots das Backup bisher noch nicht revolutioniert haben. Man darf aber nicht vergessen, dass sie bereits vieles verändert haben. Viele haben ihre herkömmlichen Backup-Systeme ausgemustert und durch Snapshots für ihre Speichersysteme sowohl inner- als auch außerhalb des Rechenzentrums ersetzt und dabei kein Tape angerührt.

Artikelfiles und Artikellinks

(ID:2047062)