Vorteile und Risiken von Data Protection mit Management
Die Backup-Daten können heute direkt für andere, mehr produktive Zwecke verwendet werden. Das bringt viele Vorteile. Anwender müssen jedoch auch mögliche Risiken bedenken.
Man stelle sich vor, man hätte Zugang zu allen produktiven Daten ohne jede Beeinträchtigung der Performance der produktiven Anwendungen und man könnte diesen Datenzugang auch für Reporting, Planungszwecke oder für das Testen von Upgrades oder Änderungen verwenden.
Moderne Produkte für Data Protection verfügen auch über Daten-Management-Funktionen, die den Unternehmen Zugang zu den gespeicherten Backup-Daten erlauben. Sobald von einem Computer – einer virtuellen Maschine oder einem physischem Server – ein Backup erstellt wurde, kann eine Kopie von diesem Backup einem anderen Computer zur Verfügung gestellt werden – egal für welchen Zweck. Dieser sekundäre Zugang ist unabhängig von dem produktiven Server und hat keinen Einfluss auf die laufende Anwendung. Die sekundäre Kopie kann für die Erzeugung von Reports oder zu Teständerungen von Anwendungen oder Infrastruktur-Upgrades verwendet werden.
Ältere Produkte erwarten, dass die Daten an einem anderen Ort wiederhergestellt werden, bevor die Reports oder Tests beginnen können. Die moderneren Systeme für Data Protection erlauben den Datenzugriff direkt vom Backup aus, ohne dass Zeit für das Restore vergeht oder zusätzliche Kosten für primären Storage entstehen, um die wiederhergestellten Daten aufzunehmen.
Wo ist der Unterschied?
Eine der bedeutenden Änderungen beim Data Protection besteht in der Kombination von SSDs und Festplatten beim Backup-Speicher.
Traditionell wurde Backup-Speicher für billige Kapazitäten gebaut, und Performance spielte nur insofern eine Rolle, als große Block-Writes für schnelle Backups benötigt wurden. Bei diesen festplattenbasierten Systemen ist die Read/Write-Performance gering, einschließlich von Metadaten-Prozessen wie dem Managing von Backups und Restores. Mit dem Hinzufügen von Solid-State-Storage können kleine I/O-Prozesse extrem schnell sein, was auch für das Erfassen von Metadaten zutrifft, die nicht mehr kleindimensioniert sein müssen, um per RAM bewältigt zu werden.
Schnelle Metadaten erlauben zügigen Zugang zu deduplizierten Daten und zu vielen Restore-Punkten, und das möglichst gleichzeitig. Mit schnellen kleinen I/O-Prozessen können Anwendungen direkt aus dem Backup-Speicher heraus gestartet werden, ohne dass vorher ein Restore zu einem primären Speicher durchgeführt werden müsste. High-Performance-Backup-Storage erlaubt virtuelle Restores, bei denen die Daten nicht zu einem Restore-Ort kopiert werden, sondern direkt aus dem Backup-Speicher heraus dargestellt werden. Indem Solid-State-Storage zu einem Data-Protection-System hinzugefūgt wird, profitieren die Anwender von einer größeren Transaktions-Performance.
Gleichzeitig zu dieser Entwicklung haben wir die Verbreitung von DevOps-Methodologien gesehen, bei denen die Infrastruktur durch Automatisierung und weniger durch manuelles Eingreifen kontrolliert wird. Moderne Plattformen für Data Protection bieten APIs zur Kontrolle aller ihrer Arbeitsschritte an.
Eine Kopie der produktiven Daten in ein Testsystem einzubauen, erfordert nur ein paar Programmierzeilen und kann in DevOps-Workflows für automatisierte Tests von Software integriert werden. Systeme für Data Protection in automatisierten DevOps-Workflows zu benutzen, erfordert allerdings bei einer großen Anzahl von Restores hohe Transaktions-Performance – ohne dass die Daten wieder kopiert werden. Nur so erhält die wiederhergestellte Anwendung ebenfalls eine ausreichende Performance.
Der entscheidende Unterschied besteht darin, dass einige der neueren Produkte über eine Scale-Out-Architektur verfügen, mit der Kapazität und Performance in derselben Weise durch Hinzufügen von Hardware-Appliances erweitert werden können, wie dies bei hyper-converged Infrastruktur-Plattformen passiert. Die Plattform für Data Protection und Management kann klein anfangen und mit der Zeit wachsen, je nachdem, in welchem Ausmaß ihre Benutzung zunimmt oder mehr Kapazität erfordert wird.
Eine Scale-Out-Architektur sorgt auch für mehr Performance in dem Maß, wie die Kapazität ansteigt. Damit vermeidet man mit Scale-Out auch eventuelle Bottlenecks bei der Performance. Und Scale-Out kann schließlich auch anfallende Ausgaben in die Zukunft verschieben, indem man gerade genügend Kapazität für die Gegenwart anschaffen muss und erst dann mehr Kapazität hinzukauft, wenn sie wirklich gebraucht wird.
Welche Resultate erzielt man?
Die Backup-Daten sind in der Regel periodisch, statt jeweils in Echtzeit in einem Data-Protection-System erfasst. Das bedeutet, diese Daten sind immer etwas veraltet. Mit neueren Backup-Systemen ist es möglich, Backups in kürzeren Abständen als bei älteren Systemen durchzuführen. Die Daten sind dann nur Minuten oder Stunden alt, anstatt von Tagen oder Wochen wie in den klassischen Backup-Architekturen. Sobald die Daten in der Protection-Plattform angekommen sind, kann eine virtuelle Kopie für nicht-produktive Zwecke mit einer fast ursprünglichen Performance verwendet werden.
Die Backup-Daten sind in der Regel periodisch statt jeweils in Echtzeit in einem Data-Protection-System erfasst. Das bedeutet, diese Daten sind immer etwas veraltet.
Mit SSDs sind Daten sogar innerhalb von Sekunden verfügbar, besonders wenn sie in automatisierten Workflows wie bei DevOps verwendet werden. Ein einziger Backup-Prozess kann die Basis für mehrere Arbeitskopien abgeben, und es muss nicht für jede Wiederverwendung eine eigene neue Kopie gezogen werden. Das kann so einfach sein, wie einen Datenbank-Server zur Erstellung von Reports zu verwenden. Reports auf Backup-Basis können jetzt mit den Daten von gestern erstellt werden, ohne dass dadurch das produktive System in Mitleidenschaft gezogen würde. Es könnte sogar häufiger geschehen, wobei Live-Daten in einen kontinuierlichen Prozess von Integration und Implementierung von detailgetreuen Softwaretests einbezogen werden. Einige dieser neuen Datenplattformen schließen sogar eine Art Reinigungsverfahren ein, mit dem private Informationen bei Softwaretests unleserlich gemacht werden.
Werden Backups produktiv?
Es gibt ein signifikantes Risiko, wenn man sein Data-Protection-System mit irgendeiner Business-Funktion wie zum Beispiel DevOps-basierter Softwareentwicklung oder geschäftskritischem Reporting zusammenschließt. Das Ziel einer separaten Backup-Plattform besteht ja gerade darin, die möglichen Fehlerquellen zu isolieren, so dass ein Ausfall im Backup-System nicht die produktiven Anwendungen tangiert und ein Zusammenbruch eines produktiven Systems durch ein Recovery auf Basis des Backup-Systems behoben werden kann.
Wenn man aber damit beginnt, das Backup-System als einen integralen Bestandteil der Business-Anwendungen und der IT-Infrastruktur zu verwenden, dann wird es effektiv zu einem produktiven System. Dann stellt sich die Frage, wie sieht es mit einem Recovery für diese Entwicklungsfunktion der Software aus, wenn das Backup-System ausfällt. Wann ist das Zeitfenster für Wartungsarbeiten, wenn die Backup-Plattform für geschäftskritisches Reporting eingesetzt wird? Dies ist jedoch kein unüberbrückbares Problem: Alle modernen Plattformen bieten die Replikation hin zu einem anderen Ort oder zu einer Cloud an. Auf jeden Fall müssen hier Vorkehrungen getroffen werden, wenn man seine Data-Protection-Plattform für mehr als nur Backups einsetzen will.
Seit einigen Jahren ist es möglich, Backup und Data Protection miteinander zu verbinden. Mit dem Aufkommen von kostengünstigem Solid-State Storage und Scale-Out Hardware-Architekturen sind nützlichere Produkte entstanden. Die Kombination von Data Protection und Data Management bringt besonders viel für die Anwender, wenn dabei Automatisierung und APIs für Reporting und DevOps eingesetzt werden. Anwender sollten sich auf jeden Fall auch mögliche Konsequenzen klar machen, wenn sie ihr Data-Protection-System für produktive Aktivitäten einsetzen. Und man sollte dabei nicht die Business Continuity vergessen.
