DRaaS: Druva Phoenix für die AWS-Cloud

Backup-Anbieter Druva hat über die Jahre seine Software inSync zu einer Cloud-basierten Data-Protection-Lösung weiterentwickelt, die nun als Druva Cloud Platform beziehungsweise als Druva Phoenix erhältlich ist. Damit will der Hersteller Unternehmen ansprechen, die eine Cloud-first-Strategien verfolgen und vor allem Data-Protection-Services nutzen, anstatt Workloads lokal zu sichern. Die Lösung bietet All-in-One-Backups, Disaster Recovery, Archivierung und Analysen. SLAs, RTOs und RPOs sollen sich entsprechend einrichten lassen und laut Anbieter somit die TCO bis um die Hälfte reduzieren.

Druvas Cloud Platform basiert auf Amazon Web Services und das Unternehmen hat derzeit keine Bestrebungen, seine Services auf Microsoft Azure oder Google Cloud Platform auszuweiten. Der Anwender kann eine oder mehrere der geografischen AWS-Regionen auswählen, je nachdem, welche Sicherungsstrategie er verfolgt. Der Anbieter bewirbt sein Angebot damit, dass weder Hardware noch Software benötigt werden, was nicht ganz korrekt ist. Für die Sicherung der Server oder virtuellen Maschinen wird ein Agent benötigt, der zwar verhältnismäßig klein dimensioniert ist, aber eben nicht völlig softwarefrei ist. Nutzer bestellen eine AWS Snowball Edge Appliance, die mit dem Phoenix-Agenten vorinstalliert ist.

Mit Phoenix lassen sich unterschiedliche Workloads in die sichern, beispielsweise physische Dateiserver und/oder NAS-Systeme und Datenbanken, virtuelle Maschinen und hybride Umgebungen wie VMware Cloud auf AWS-VPC. Interessant ist, dass an Hypervisoren Microsoft Hyper-V, VMware vSphere und Nutanix AHV unterstützt werden. Für Nutanix ist die Lösung zwar zertifiziert, derzeit aber nur für physische Maschinen, an einer nativen AHV-Lösung wird gearbeitet und diese soll noch in diesem Jahr erscheinen.

Obwohl die Lösung rein AWS-fokussiert ist, ist ein Backup aus anderen Clouds möglich, wenn auch in limitierten Maße. So lassen sich Daten aus Google oder Azure sichern, aber eben keine vollständigen virtuellen Maschinen. Da Druva hier keinen Zugriff auf Host-Level-Ebene hat, können Sie nur die Daten selbst in anderen Cloud-Umgebungen adressieren.

Um Bandbreite und Speicherplatz zu sparen werden nur rein inkrementelle Backups durchgeführt, selbst das erste Full Backup wird mittels der globalen Deduplizierung minimiert. Die Lösung setzt eine „Forever-Incremental“-Strategie um, was zwar alle Vorteile eines inkrementellen und deduplizierten Backups mit sich bringt, aber eben auch die Nachteile. Der größte Nachteil dieser Sicherungsform liegt darin, dass für ein Recovery das letzte Voll-Backup sowie alle inkrementellen Backups wiederhergestellt werden müssen. Das dauert deutlich länger als die Rücksicherung eines Voll-Backups. Die Deduplizierung erfolgt auf Block-Level-Ebene. In Kombination soll der Anwender so 30 Prozent weniger an Ressourcen benötigen, laut Aussage des Anbieters.

Alle Daten werden 90 Tage auf schnellem Speicher vorgehalten, danach auf langsameren und günstigen Speicher – in diesem Falle Glacier – abgelegt. Der Datentransfer nach 90 Tagen ist in „hard code“ und lässt sich dementsprechend nicht ändern. Nach der Verschiebung können die Daten trotzdem über eine zentrale Steuerung eingesehen werden. Im Falle einer Datenwiederherstellung aus Glacier muss der Anwender etwa vier Stunden in Kauf nehmen. Alle Informationen, die jünger sind als 90 Tage, lassen sich – je nach Bandbreite – sofort wiederherstellen.

Ältere, sogenannte „kalte Snapshots“ müssen für ein Restore quasi erst „aufgetaut“ werden und stehen dann für drei Tage zur Verfügung, bevor sie wieder „eingefroren“ werden. Darüber hinaus nutzt die Plattform einen so genannten Cloud Cache. Dieser hält die Daten von fünf Tagen vor, damit diese schneller abgerufen werden können. Druva gibt hier 820 GByte/h pro Thread an.

Gesicherte Daten können auf Dateiebene wiederhergestellt werden. Für das Restore virtueller Maschinen gibt der Hersteller einen RPO von einer Stunde und einen RTO von Minuten an. Ein Failover sollte demnach, je nach Datenvolumen und Speicherort, auch nur Minuten in Anspruch nehmen. Da Druva auf AWS aufbaut, entsprechen die Service Level Agreements auch den Möglichkeiten, die mit der Cloud-Plattform einher gehen. Für die Beständigkeit garantiert der Anbieter elf Neunen (99,999999999) und fünf Neunen für die Verfügbarkeit (99,999) mit drei Verfügbarkeitszonen. Allerdings sollten Anwender hier kritisch nachfragen, da AWS nur drei Neunen (99,9) für die Verfügbarkeit garantiert.

Neue Funktionen werden in regelmäßigen Abständen durch Updates hinzugefügt. Berechnet werden nur die wirklich abgelegten Daten, weswegen die Inkrement- und Dedup-Technologie hier helfen, die Kosten zu minimieren. Phoenix ist DSGVO-zertifiziert und die Daten werden natürlich verschlüsselt. Das Management der Schlüssel bleibt dem Anwender vorbehalten.

Ältere Backups können derzeit nicht inkludiert werden und auch für Container gibt es keine Pläne, letzteres aber eher aus der Tatsache heraus, dass es hier kaum Anfragen gibt. Darüber hinaus lassen sich auch Analyse-Tools nutzen. Die unterschiedlichen Services sind quasi modular erhältlich; je mehr Services genutzt werden, desto höher die Endrechnung.

Es gibt vier unterschiedliche Preismodelle:

• Data Center (Preis pro wirklich genutztem TByte)
• SaaS Application (ab 4 US-Dollar pro Nutzer und Monat)
• Endpoints (ab 4 US-Dollar pro Nutzer und Monat)
• AWS Infrastructure (ab 79 US-Dollar pro Monat)