©Wynn Pointaux/Pixabay

Backup-Anbieter vermarkten mittlerweile „Multi-Cloud“-Lösungen, die meisten bieten jedoch lediglich Cloud-Hosting – worin der Unterschied besteht und warum dies entscheidend ist, wenn Unternehmen tatsächlich Daten wiederherstellen müssen

Jeder Backup-Anbieter auf dem Markt vermarktet mittlerweile Lösungen für Multi-Cloud-Backups. Die Marketingseiten sehen alle ähnlich aus. Die zugrundeliegenden Architekturen unterscheiden sich jedoch erheblich – und diese Unterschiede werden genau im falschen Moment teuer.

Einige Unternehmen mussten dies in den letzten Jahren auf die harte Tour lernen. Ein Anbieter verkauft ihnen „Cloud-natives Multi-Cloud-Backup“. Das Produkt ist eine virtuelle Appliance mit fester Größe, die der Kunde in AWS oder Azure bereitstellt, mit einer im Voraus geschätzten maximalen Kapazität konfiguriert und für die er bezahlt, unabhängig davon, ob er sie nutzt oder nicht. Das ist nicht Cloud-nativ. Das ist das alte Rechenzentrumsmodell, das in einer in der Cloud gehosteten VM läuft. Dies ist eine Art „Cloud-Washing“. Das Produkt des Anbieters hat sich nicht wirklich verändert, das Marketingversprechen schon.

HYCU nennt fünf Merkmale, die ein Backup tatsächlich Cloud-nativ machen

Echtes cloud-natives Backup ist kein Marketingslogan. Es ist eine Architektur, und diese Architektur hat Auswirkungen auf Kosten, Skalierbarkeit und Wiederherstellung. Fünf Merkmale sind entscheidend.

  • Es skaliert elastisch mit der Cloud: Neue VMs werden automatisch durch API-Erkennung geschützt. Alte VMs verursachen keine Backup-Last mehr, sobald sie außer Betrieb genommen werden. Es gibt keine feste Kapazität, die man erraten muss und keinen Beschaffungszyklus, wenn die Umgebung wächst.
  • Es nutzt native Cloud-Dienste als Grundbausteine: Dies bedeutet native Snapshots für VMs, natives IAM für die Authentifizierung, nativer Objektspeicher für die Aufbewahrung und native Marktplätze für die Abrechnung. Es ist keine vom Anbieter erstellte Abstraktionsschicht nötig, die nachbildet, was die Cloud ohnehin bereits leistet.
  • Die Abrechnung erfolgt auf Basis dessen, was Unternehmen tatsächlich gesichert haben: Ein „Pay-as-you-protect“-Modell, bei dem die Kosten auf der tatsächlich geschützten Quellkapazität und der Backup-Häufigkeit basieren, nicht auf der Kapazität, die Unternehmen vielleicht irgendwann einmal nutzen werden.
  • Es erfordert keine Bereitstellung von Infrastruktur: Dies bedeutet keine Backup-Appliances, den Unternehmen bereitstellen müssen, keine Agenten, die sie auf geschützten Workloads installieren müssen, kein proprietärer Speicher, dessen Größe sie anpassen müssen. Der Kunde abonniert den Dienst, der Dienst läuft.
  • Es verschiebt Daten nativ zwischen Clouds: Ein auf AWS erstelltes Backup wird auf GCP wiederhergestellt. Die Workload-Migration erfolgt über denselben Mechanismus. Die Clouds, für die sich Unternehmen heute entscheiden, und die Clouds, für die sie sich in drei Jahren entscheiden werden, werden alle über dasselbe Management verwaltet.

Was „Cloud-Washing“-Backup Unternehmen tatsächlich kostet

Drei TCO-Muster tauchen bei „Cloud-Washing“-Bereitstellungen immer wieder auf. Sie sind so vorhersehbar, dass sie in der Regel innerhalb von 15 Minuten bei der Überprüfung der Rechnung identifizierbar sind.

  • Überprovisionierung ist das erste Muster: Der Kunde dimensioniert die Backup-Appliance für zukünftige Spitzenauslastung, nutzt sie in den ersten zwei Jahren zu 30 Prozent aus und bezahlt für die ungenutzten 70 Prozent. Bei echter Cloud-Nativität stellen Unternehmen keine Kapazität bereit, sondern verbrauchen sie.
  • Versteckte Cloud-Kosten sind das zweite Muster: Die Backup-Appliance des Anbieters erzeugt erheblichen ausgehenden Datenverkehr, regionenübergreifenden Replikationsverkehr oder API-Aufrufe für Speicherebenen, die auf der Cloud-Rechnung des Kunden, nicht auf der des Anbieters, erscheinen. Der Kunde zahlt dem Anbieter einen Festpreis für die Software und dem Cloud-Anbieter einen unvorhersehbaren Betrag für die durch die Software verursachten Leistungen.
  • Der Migrationsaufwand ist der dritte Faktor: Der Kunde möchte Workloads von einer Cloud in eine andere verlagern. Das Tool des Backup-Anbieters funktioniert jedoch nur innerhalb einer einzigen Cloud. Die Migration wird so zu einem eigenständigen Projekt mit eigenem Tool, eigenem Budget und eigenem Zeitplan.

Die Multi-Cloud-Realität in Unternehmen

Die „State of the Cloud“-Studie von Flexera verfolgt seit Jahren die Verbreitung von Multi-Cloud-Lösungen. Während frühere Berichte ergaben, dass fast neun von zehn Unternehmen (89 Prozent) bereits mehrere Clouds nutzten, zeigt die Studie aus dem Jahr 2025, dass sich der Markt zu einer Hybrid- und Multi-Cloud-Norm entwickelt hat. Unternehmen nutzen mittlerweile durchschnittlich 2,4 Public-Cloud-Anbieter, und 70 Prozent betreiben Hybridumgebungen, die sowohl Public als auch Private Clouds umfassen. Dies unterstreicht, dass Multi-Cloud nicht mehr nur eine Architektur der Zukunft ist, sondern die Art und Weise, wie Unternehmen heute arbeiten. Die meisten IT-Umgebungen in Unternehmen umfassen mittlerweile mindestens zwei Public Clouds sowie eine lokale Infrastruktur und ein Portfolio an SaaS-Anwendungen. Eine Backup-Strategie, die bei AWS funktioniert, bei Azure jedoch versagt, entspricht nicht der Realität, in der Kunden agieren. Ebenso wenig wie eine Strategie, die IaaS abdeckt, SaaS jedoch außer Acht lässt.

Die Kosten für solche Fehler sind greifbar. „Cost of a Data Breach 2024 Report“ von IBM ergab, dass die weltweiten Durchschnittskosten einer Datenpanne 4,88 Millionen US-Dollar erreichten – ein Anstieg von zehn Prozent gegenüber dem Vorjahr und der höchste Anstieg seit Beginn der Pandemie. Der Anstieg war größtenteils auf Betriebsunterbrechungen, entgangene Geschäfte, Kosten für die Reaktion auf Vorfälle und langwierige Wiederherstellungsmaßnahmen zurückzuführen. Die Untersuchung von IBM ergab zudem, dass komplexe Hybridumgebungen, die Cloud-, On-Premises- und containerisierte Infrastrukturen umfassen, die Eindämmung von Sicherheitsverletzungen erschweren und verteuern können. Fehlkonfigurationen in der Cloud, kompromittierte Anmeldedaten und andere Sicherheitslücken gehören nach wie vor zu den Hauptursachen für das Risiko von Sicherheitsverletzungen. Lücken in der Backup-Abdeckung, die Angreifern die Möglichkeit bieten, Daten zu verschlüsseln, zu zerstören oder zu exfiltrieren, können die betrieblichen und finanziellen Auswirkungen eines Vorfalls erheblich verstärken.

Was eine echte Multi-Cloud-Abdeckung beinhalten muss

UmgebungAbdeckungsumfang
AWS EC2, EBS, RDS, S3, EFS, FSx, mit nativen Snapshots und IAM-Integration
Microsoft Azure Azure VMs, Managed Disks, Azure SQL, AKS, Blob Storage, Files, Microsoft 365 und Entra ID 
Google Cloud Compute Engine, Persistent Disks, Cloud SQL, BigQuery, GKE, GCS, Filestore 
On-Premises und Private Cloud Nutanix AHV and ESXi-on-Nutanix, VMware, Dell PowerProtect Data Domain, NetApp ONTAP, physisches Windows und Linux 
Containerisierte Workloads EKS, AKS, GKE und On-Premises-Kubernetes-Distributionen
SaaS-Anwendungen Microsoft 365, Google Workspace, Salesforce, Atlassian Cloud, GitHub, Okta, Box, Dynamics 365 und mehr 
Enterprise-Anwendungen SQL Server, Oracle, SAP HANA, Exchange, mit anwendungskonsistenter Datensicherung

Die entscheidenden Diagnosefragen

Drei Fragen zeigen Unternehmen innerhalb kurzer Zeit auf, ob die Multi-Cloud-Behauptung eines Anbieters der Realität entspricht oder nur Marketing ist.

  • Unternehmen sollten zunächst fragen, was sie bereitstellen müssen: Wenn die Antwort eine virtuelle Appliance pro Cloud, eine feste Kapazitätsdimensionierung oder Verpflichtungen in Höhe von maximal Terabyte beinhaltet, handelt es sich um eine Cloud-gehostete, nicht um eine Cloud-native Architektur. Echte Cloud-Nativität bedeutet, dass keine Infrastruktur bereitgestellt werden muss.
  • Die zweite Frage betrifft die Preisgestaltung: Wenn die Antwort an Kapazitäten geknüpft ist, die Unternehmen im Voraus reservieren, verkauft der Anbieter ein „Appliance“-Modell. Bei einem „Pay-as-Companies-Protect“-Modell werden die Kosten auf Basis der tatsächlich gesicherten Quelldaten berechnet, nicht auf der Grundlage einer Schätzung des zukünftigen Maximums.
  • Die dritte Frage ist, wie eine Cloud-übergreifende Migration aussieht: Der Anbieter muss die Migration einer von AWS gesicherten und auf GCP wiederhergestellten Workload demonstrieren. Wenn die Antwort Export, Reimport und die Beauftragung von Dienstleistungen beinhaltet, ist der Multi-Cloud-Anspruch von der Art, die versagt, wenn Unternehmen ihn tatsächlich benötigen.

Der Kunde wählt die Clouds – nicht der Backup-Anbieter

Wenn der Kunde AWS für die Produktion, Azure für die Notfallwiederherstellung und GCP für Analysen nutzen möchte, schützt die Backup-Plattform alle drei mit denselben Richtlinien und demselben Wiederherstellungsmodell. Die Cloud-Strategie des Kunden wird nicht dadurch eingeschränkt, was sein Backup-Anbieter unterstützt. Kontrolle bedeutet, dass die Daten in der Infrastruktur des Kunden verbleiben. Backups werden in den Cloud-Konten des Kunden gespeichert. Der Kunde besitzt die Schlüssel. Der Anbieter wird weder zu einem Single Point of Failure noch zu einem Single Point of Leverage.

Unternehmen sollten ihr aktuelles Backup-System prüfen und jede Workload auflisten, wo sie läuft, durch welches Backup-Tool sie gesichert ist und was in einem Wiederherstellungsszenario passieren würde. Diese Überprüfung deckt in der Regel zwei oder drei Workloads auf, die funktional ungeschützt sind. Das sind die Lücken, die ein Multi-Cloud-Backup schließen soll.


Häufige Fragen zum Multi-Cloud-Backup

Warum nicht einfach den nativen Backup-Dienst der jeweiligen Cloud nutzen?
Native Dienste sind nützliche Grundbausteine innerhalb ihrer eigenen Cloud. AWS Backup eignet sich gut zur Sicherung von AWS-Workloads. Bei Azure, GCP, On-Premises-Umgebungen oder SaaS hilft es jedoch nicht weiter. Die meisten Unternehmensumgebungen umfassen alle vier Bereiche, und die Betriebskosten für die Verwaltung von vier separaten Backup-Tools mit vier separaten Richtlinien, vier separaten Konsolen und vier separaten Aufbewahrungsmodellen steigen schnell an.

Wie sieht es mit den Kosten für den Datenausgang bei der Wiederherstellung über Clouds hinweg aus?
Der Datenausgang ist real und spielt eine Rolle. Die architektonische Lösung besteht darin, Backup-Kopien in der Cloud zu belassen, aus der die Workload stammt, und Daten nur dann aus der Cloud zu übertragen, wenn tatsächlich eine Wiederherstellung in einer anderen Cloud erfolgt. An den meisten Tagen fallen dabei keine Kosten an. An dem Tag, an dem Unternehmen eine Cloud-übergreifende Wiederherstellung benötigen, macht der Datenausgang nur einen kleinen Bruchteil der Kosten des Vorfalls aus.

Wie werden Compliance und Datenhoheit bei Multi-Cloud-Backups gehandhabt?
Region für Region. Die Backup-Daten verbleiben in der vom Kunden festgelegten Region. Wenn die DSGVO vorschreibt, dass EU-Daten in der EU verbleiben müssen, wird dies durch die Backup-Konfiguration durchgesetzt. Compliance ist eine Konfigurationsentscheidung und keine Zusage des Anbieters, die möglicherweise eingehalten wird oder auch nicht.

Ist das für Unternehmen realistisch, die noch nicht auf Multi-Cloud setzen?
Die meisten Unternehmen landen letztendlich bei einer Multi-Cloud-Umgebung, ob sie das nun geplant haben oder nicht. Übernahmen bringen verschiedene Clouds mit sich. Verschiedene Geschäftsbereiche wählen unterschiedliche Anbieter. Die Ausbreitung von SaaS fügt Workloads außerhalb jeder ausgewählten Cloud hinzu. Die Wahl einer Multi-Cloud-fähigen Backup-Plattform, bevor Unternehmen sie benötigen, ist kostengünstiger als der Wechsel des Backup-Anbieters, wenn dieser Bedarf erst entsteht.

Disclaimer:
„Für den oben stehenden Beitrag sowie für das angezeigte Bild- und Tonmaterial ist allein der jeweils angegebene Nutzer verantwortlich. Eine inhaltliche Kontrolle des Beitrags seitens der Seitenbetreiberin erfolgt weder vor noch nach der Veröffentlichung. Die Seitenbetreiberin macht sich den Inhalt insbesondere nicht zu eigen.“