Google Cloud Backup: Der umfassende Leitfaden zu BaaS

So erkennen Sie einen Anbieter, dessen Lösung nicht wirklich für GCP entwickelt wurde

Ob ein Backup-Anbieter seine Lösung tatsächlich für Google Cloud entwickelt hat, lässt sich daran erkennen, welche Fragen er beim ersten Verkaufsgespräch stellt. Wenn die ersten Fragen lauten: „Wie viele Backup-Server benötigen Sie?“ oder „Wie hoch ist Ihre maximale Kapazität in Terabyte?“, dann wurde die Lösung nicht für Google Cloud entwickelt. Es handelt sich um eine fest konfigurierte Appliance, die einfach in GCP migriert wurde.

Dieses Muster wiederholt sich so häufig, dass ich es mittlerweile als Diagnosekriterium nutze. Die Fragen, die ein Anbieter stellt, verraten, welche Architektur er liefert. Cloud-native Architekturen erfordern diese Antworten nicht. Cloud-gehostete Appliances hingegen schon.

Dieser Beitrag erläutert, was echtes BaaS für Google Cloud leisten muss, welche Fragen zur Bewertung von Anbietern relevant sind und welche Bereiche die nativen Funktionen von GCP abdecken – und wo Lücken bestehen. 

Warum die integrierten Funktionen von Google Cloud keine Strategie darstellen

Google stellt nützliche Schutzfunktionen zur Verfügung: Snapshots von Persistent Disks, automatisierte Backups von Cloud SQL, Objektversionierung in GCS, Snapshots von BigQuery-Tabellen. Diese stellen jedoch keine Backup-Strategie dar. 

Das Modell der geteilten Verantwortung von GCP ist eindeutig. Google kümmert sich um die Sicherheit und Verfügbarkeit der Infrastruktur. Der Kunde kümmert sich um die Daten. Wenn ein Administrator ein Projekt löscht, Ransomware eine „Persistent Disk“ verschlüsselt, ein Konfigurationsfehler Cloud-SQL-Daten löscht oder ein Entwickler die falsche BigQuery-Tabelle löscht, wird Google diese Aktion pflichtbewusst ausführen. Die Wiederherstellung ist Aufgabe des Kunden.

Vier Lücken, die native Funktionen nicht schließen: Unabhängige Aufbewahrungsfristen, damit Backups auch dann erhalten bleiben, wenn die Quell-Workload gelöscht wird; Anwendungskonsistenz, damit Datenbanken und Anwendungen sauber wiederhergestellt werden und nicht nur absturzkonsistent sind; Regions- und projektübergreifende Isolierung, damit eine Kompromittierung an einem Standort den Schutz nicht außer Kraft setzt. Und granulare Wiederherstellung, damit eine einzelne Datei, Tabelle oder VM wiederhergestellt werden kann, ohne alles neu aufbauen zu müssen.

Was vollständige GCP-Abdeckung tatsächlich bedeutet

Ein Anbieter, der ausschließlich Compute Engine-VMs schützt, verkauft Cloud-Backup aus dem Jahr 2018. Echtes BaaS schützt jede Workload-Klasse über eine einzige Verwaltungsebene.

Die richtigen Fragen, die Sie jedem GCP-Backup-Anbieter stellen sollten

Fünf Fragen, die den Unterschied zwischen einer cloud-nativen Architektur und cloud-gehosteten Appliances verdeutlichen.

Lässt sich die Lösung elastisch mit Google Cloud skalieren? Die richtige Antwort lautet „Ja“ – über Backup-Richtlinien und Cloud Storage-Buckets, ohne dass Knoten bereitgestellt oder Kapazitäten prognostiziert werden müssen. Fügen Sie morgen ein neues GCP-Projekt hinzu, und der Schutz sollte ohne betrieblichen Eingriff folgen.

Wie nativ und integriert ist die Lösung? Drei konkrete Tests. Erstens: IAM. Authentifiziert sich der Dienst über Google Cloud IAM und übernimmt dabei bestehende Berechtigungen und die Projektstruktur? Zweitens: die API-Oberfläche. Läuft der Dienst über Google Cloud-APIs, sodass Daten die GCP-Grenzen niemals verlassen? Drittens: die Abrechnung. Ist die Nutzung über den Google Cloud Marketplace möglich, wobei die Kosten über die bestehende GCP-Abrechnung abgerechnet werden? 

Unterstützt er Cloud SQL, BigQuery, GKE und SAP HANA, nicht nur Compute Engine? Ein reines VM-Backup lässt den Großteil dessen außer Acht, was in modernen GCP-Umgebungen läuft. Fragen Sie nach konkreten Angaben zu jeder Workload-Klasse. Allgemeine Antworten bedeuten allgemeinen Schutz. 

Wie sieht die regionen- und projektübergreifende Wiederherstellung aus? Workloads entwickeln sich zu regionen- und projektübergreifenden Bereitstellungen. Der Backup-Mechanismus, der in einem einzelnen Projekt funktionierte, versagt an den Grenzen. Bitten Sie den Anbieter, eine Wiederherstellung zu demonstrieren, die beide Bereiche umfasst.

Wie skaliert die Preisgestaltung mit dem Wachstum der Umgebung? Achten Sie auf ein „Pay-as-you-protect“-Modell, das auf den tatsächlich gesicherten Quelldaten basiert und nicht auf der maximal reservierten Kapazität.

Drei Säulen: Sicherung, Migration und DR

BaaS für Google Cloud deckt drei eng miteinander verbundene Anwendungsfälle ab. Starke Lösungen bewältigen alle drei Bereiche über eine einzige Plattform, ein einziges Richtlinien-Framework und ein einziges Wiederherstellungsmodell.

Das Backup selbst. Anwendungskonsistentes Backup und Wiederherstellung für jede Workload-Klasse unter Verwendung nativer Google Cloud-Snapshots als erste Schutzebene und Google Cloud Storage zur längerfristigen Aufbewahrung. Die enge Plattformintegration bedeutet nahezu keine Auswirkungen auf die Produktionsleistung. 

Migration zu und innerhalb von GCP. Der gleiche Backup-Mechanismus dient gleichzeitig als Migrationsmechanismus. Verlagern Sie Produktions-Workloads aus dem lokalen Umfeld, aus einer anderen Cloud oder von einer GCP-Region in eine andere, wobei vorhandene Backup-Daten als Migrationsquelle dienen. Die Anwendungskonsistenz bleibt während der Verlagerung gewahrt. 

Notfallwiederherstellung mit GCP. Google Cloud als DR-Ziel für Workloads vor Ort oder aus anderen Clouds. Das wirtschaftliche Modell ist entscheidend. Speichern Sie Backup-Kopien kontinuierlich und kostengünstig in GCP, verbrauchen Sie Rechenleistung und Hochleistungsspeicher jedoch erst, wenn tatsächlich ein Notfall ausgerufen wird. Den größten Teil des Jahres zahlen Sie lediglich für den Speicherplatz. An den seltenen Tagen, an denen eine Katastrophe eintritt, zahlen Sie für Rechenleistung. Dies entspricht nur einem Bruchteil der Kosten für eine ständig aktive Notfallwiederherstellung.

So funktioniert „Lift-and-Shift“ mit GCP bei Backup-Daten tatsächlich

Der technische Ablauf umfasst vier Schritte bei der Migration von Compute Engine-Workloads aus der lokalen Umgebung. 

Stellen Sie das Festplatten-Image der Produktions-VM aus dem vorhandenen Backup wieder her. Exportieren Sie es in ein SMB- oder NFS-Ziel, auf das von der Migrations-Workstation aus zugegriffen werden kann.

Installieren Sie das Google Cloud SDK auf der Workstation. 

Erstellen Sie einen Cloud Storage-Bucket im Zielprojekt und laden Sie die Festplattendateien der VM hoch.

Importieren Sie die Festplatten als benutzerdefinierte Compute Engine-Images mit dem Befehl „gcloud compute images import“, wobei Sie den Quell-Bucket und das Betriebssystem angeben.

Sobald das benutzerdefinierte Image vorliegt, werden neue Compute Engine-Instanzen direkt daraus gestartet. Das gleiche Muster gilt für die regionenübergreifende Migration innerhalb von GCP sowie für die Migration aus anderen Clouds.

Häufige Fragen zur GCP-Sicherung

Kann ich mich allein auf die integrierten Funktionen von Google Cloud verlassen?

Nein. Die integrierten Funktionen sind nützliche Grundbausteine, es fehlt ihnen jedoch an unabhängiger Aufbewahrungsdauer, Anwendungskonsistenz bei Workloads mit mehreren Ressourcen, projektübergreifender Isolation und granularer Wiederherstellung für viele Workload-Typen. Echtes BaaS baut auf diesen integrierten Funktionen auf.

Wie kann ich Daten nach einer versehentlichen Löschung oder einem Ransomware-Angriff wiederherstellen? 

Stellen Sie Daten zu jedem beliebigen aufbewahrten Zeitpunkt wieder her, selbst nach einer Löschung oder Verschlüsselung. Die Wiederherstellungsoptionen reichen von einer einzelnen Datei innerhalb einer VM, einer einzelnen Tabelle in BigQuery oder einem einzelnen Namespace in GKE bis hin zur vollständigen Wiederherstellung einer VM oder eines gesamten Projekts in der ursprünglichen oder einer anderen Region. Die Aufbewahrungsdauer ist unabhängig von der Quell-Workload. 

Ist GCP BaaS sicher und konform?

Verschlüsselung während der Übertragung und im Ruhezustand, Integration mit Google Cloud IAM sowie Zertifizierungen gemäß SOC 2, HIPAA und DSGVO. Dank der cloud-nativen Architektur verbleiben die Backup-Daten durchgehend innerhalb der GCP-Grenzen. 

Funktioniert BaaS für SAP HANA, GKE und BigQuery?

Das sollte der Fall sein. SAP HANA benötigt anwendungsorientiertes Backup, das in das Protokollmanagement von HANA integriert ist. GKE erfordert eine Granularität auf Container-, persistenter Volume- und Namespace-Ebene. BigQuery benötigt Backups auf Datensatz- und Tabellenebene. Ein Anbieter, der nur Compute Engine-VMs unterstützt, lässt den Großteil dessen außer Acht, was in einer modernen GCP-Umgebung läuft.

Testen Sie es in Ihrer Umgebung

HYCU R-Cloud für Google Cloud ist direkt im Google Cloud Marketplace erhältlich. Die Testversion nutzt Ihr tatsächliches GCP-Konto, Ihre tatsächlichen Workloads und Ihre tatsächlichen Daten. Sie können die Lösung innerhalb von 15 Minuten zum Laufen bringen. Die meisten Teams wissen bereits nach wenigen Tagen, ob die Lösung zu ihnen passt. Den Link zur Testversion finden Sie unter hycu.com/trial.