Multi-Cloud-Backup: Was „Cloud-nativ“ eigentlich bedeutet

Das Problem des „Cloud-Washing“

Jeder Backup-Anbieter in unserem Markt bietet mittlerweile Multi-Cloud-Backups an. Die Marketingseiten sehen alle ähnlich aus. Die zugrunde liegenden Architekturen unterscheiden sich jedoch erheblich, und diese Unterschiede werden genau im falschen Moment kostspielig.

Ich habe in den letzten Jahren beobachtet, wie Kunden dies auf die harte Tour lernen mussten. 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. 

Ich bezeichne dies kurz als „Cloud-Washing“. Das Produkt des Anbieters hat sich nicht wirklich verändert. Seine Präsentationsfolien hingegen schon.

Fünf Merkmale, die ein Backup tatsächlich cloud-nativ machen

Echtes cloud-natives Backup ist kein Marketing-Slogan. 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. Keine feste Kapazität, die man schätzen muss. Kein Beschaffungszyklus, wenn die Umgebung wächst.

Es nutzt native Cloud-Dienste als Grundbausteine. Native Snapshots für VMs, natives IAM für die Authentifizierung, nativer Objektspeicher für die Aufbewahrung, native Marktplätze für die Abrechnung. Keine vom Anbieter erstellte Abstraktionsschicht, die nachbildet, was die Cloud ohnehin bereits leistet.

Die Abrechnung erfolgt auf Basis dessen, was Sie tatsächlich gesichert haben. Ein „Pay-as-you-protect“-Modell, bei dem die Kosten auf der tatsächlich gesicherten Quellkapazität und der Backup-Häufigkeit basieren. Nicht auf Kapazität, die Sie vielleicht eines Tages nutzen werden.

Es ist keine Bereitstellung von Infrastruktur erforderlich. Es müssen keine Backup-Appliances bereitgestellt, keine Agenten auf den geschützten Workloads installiert und keine proprietären Speichersysteme dimensioniert werden. Der Kunde abonniert den Dienst; der Dienst läuft.

Es verschiebt Daten nativ zwischen verschiedenen Clouds. Ein auf AWS erstelltes Backup lässt sich auf GCP wiederherstellen. Die Migration von Workloads erfolgt über denselben Mechanismus. Die Clouds, für die Sie sich heute entscheiden, und die Clouds, für die Sie sich in drei Jahren entscheiden, werden alle über dasselbe Management verwaltet.

Was Sie ein „Cloud-Washed“-Backup tatsächlich kostet

Drei TCO-Muster tauchen bei „Cloud-Washed“-Bereitstellungen immer wieder auf. Sie sind so vorhersehbar, dass ich sie in der Regel bereits nach 15 Minuten bei der Überprüfung der Rechnung eines Kunden identifizieren kann.

Überdimensionierung ist das erste Muster. Der Kunde dimensioniert die Backup-Appliance für zukünftige Spitzenauslastungen, nutzt sie in den ersten zwei Jahren zu 30 % aus und bezahlt für die ungenutzten 70 %. Bei einer echten Cloud-nativen Lösung stellen Sie keine Kapazität bereit. Sie 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 jedoch 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. 

Die Migrationsgebühr ist der dritte Punkt. 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 %) bereits mehrere Clouds nutzten, zeigt die Studie aus dem Jahr 2025, dass sich der Markt zu einer Norm aus Hybrid- und Multi-Cloud-Lösungen entwickelt hat. Unternehmen nutzen mittlerweile durchschnittlich 2,4 öffentliche Cloud-Anbieter, und 70 % betreiben hybride Umgebungen, die sowohl öffentliche als auch private Clouds umfassen, was 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 öffentliche 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 konkret. IBM hat in seinem Bericht „2024 Cost of a Data Breach Report“ festgestellt, dass die weltweiten Durchschnittskosten einer Datenpanne 4,88 Millionen US-Dollar erreichten – ein Anstieg um 10 % 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 sowie 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 Datenschutzverletzungen erschweren und verteuern können. Fehlerhafte Cloud-Konfigurationen, kompromittierte Zugangsdaten und andere Sicherheitslücken zählen nach wie vor zu den Hauptursachen für das Risiko von Datenschutzverletzungen. 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 umfassen muss

Die Diagnosefragen, die tatsächlich funktionieren

Drei Fragen, die in der unten angegebenen Reihenfolge gestellt werden, zeigen Ihnen innerhalb von 10 Minuten, ob die Multi-Cloud-Behauptung eines Anbieters der Realität entspricht oder nur Marketing ist. 

Fragen Sie zunächst, was Sie bereitstellen müssen. Wenn die Antwort eine virtuelle Appliance pro Cloud, eine feste Kapazitätsdimensionierung oder Verpflichtungen hinsichtlich maximaler Terabyte-Mengen beinhaltet, handelt es sich um eine cloud-gehostete Architektur, nicht um eine cloud-native. Echte Cloud-Nativität bedeutet, dass keine Infrastruktur bereitgestellt werden muss.

Fragen Sie als Zweites, wie die Preisgestaltung funktioniert. Wenn die Antwort an die Kapazität gebunden ist, die Sie im Voraus reservieren, verkauft der Anbieter ein „Appliance“-Modell. Bei einem „Pay-as-you-protect“-Modell werden die Kosten auf Basis der tatsächlich gesicherten Quelldaten berechnet, nicht auf der Grundlage einer Schätzung des zukünftigen Maximums.

Fragen Sie drittens, wie die cloudübergreifende Migration aussieht. Lassen Sie sich eine Arbeitslast demonstrieren, die von AWS gesichert und auf GCP wiederhergestellt wird. Wenn die Antwort Export, Reimport und die Inanspruchnahme von Dienstleistungen beinhaltet, ist der Multi-Cloud-Anspruch von der Art, die versagt, wenn Sie ihn tatsächlich benötigen.

Was „Ihre Daten. Ihre Cloud. Sie haben die Kontrolle.“ tatsächlich bedeutet

Unser Gründer Simon Taylor sagt dies schon seit Jahren, und ich habe es mittlerweile als etwas Konkreteres als nur einen Slogan verstanden.

Der Kunde wählt die Clouds aus. 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 durch die Möglichkeiten seines Backup-Anbieters eingeschränkt.

Kontrolle bedeutet, dass die Daten in der Infrastruktur des Kunden verbleiben. Backups werden in den Cloud-Konten des Kunden gespeichert. Der Kunde verfügt über die Schlüssel. Der Anbieter wird weder zu einem Single Point of Failure noch zu einem Single Point of Leverage.

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 jeweiligen Cloud. AWS Backup eignet sich gut zum Schutz von AWS-Workloads. Es bietet jedoch keine Unterstützung für Azure, GCP, On-Premises-Umgebungen oder SaaS. 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 Cloud-Grenzen hinweg aus?

Der Datenausgang ist ein realer Faktor und von Bedeutung. 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 belaufen sich diese Kosten auf null. An dem Tag, an dem Sie eine cloudübergreifende Wiederherstellung benötigen, machen die Datenausgangsgebühren nur einen kleinen Bruchteil der Gesamtkosten 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 dies für Unternehmen realistisch, die noch nicht auf Multi-Cloud umgestellt haben?

Die meisten Unternehmen nutzen letztendlich Multi-Cloud, unabhängig davon, ob sie dies geplant haben oder nicht. Übernahmen bringen unterschiedliche Clouds mit sich. Verschiedene Geschäftsbereiche entscheiden sich für unterschiedliche Anbieter. Die Ausbreitung von SaaS-Lösungen führt zu Workloads außerhalb der gewählten Clouds. Die Wahl einer Multi-Cloud-fähigen Backup-Plattform, bevor Sie sie benötigen, ist kostengünstiger als der Wechsel Ihres Backup-Anbieters, wenn der Bedarf erst entsteht.

Was ich als Nächstes tun würde

Prüfen Sie Ihr aktuelles Backup. Listen Sie jede Workload auf, wo sie ausgeführt wird, womit sie geschützt 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. Wenn Ihre Organisation zu diesen gehört, beginnen Sie dort.