Google Cloud Backup: Der umfassende Leitfaden zu BaaS

So erkennen Sie einen Anbieter, der seine Lösung nicht wirklich für GCP entwickelt hat 

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 portiert 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 bereitstellt. Cloud-native Architekturen erfordern diese Antworten nicht. Bei in der Cloud gehosteten Appliances ist dies jedoch der Fall. 

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 bzw. 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. Sie stellen 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 ist für die Daten verantwortlich. 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 Aufbewahrung, 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 Isolation, 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 eine vollständige GCP-Abdeckung tatsächlich bedeutet 

 Ein Anbieter, der lediglich Compute Engine-VMs schützt, vermarktet 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. Kann der Dienst über den Google Cloud Marketplace genutzt werden, wobei die Kosten über die bestehende GCP-Abrechnung abgerechnet werden? 

Unterstützt er Cloud SQL, BigQuery, GKE sowie SAP HANA, und nicht nur Compute Engine? Eine reine VM-Sicherung 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 wachsen zu regionen- und projektübergreifenden Bereitstellungen heran. Der Backup-Mechanismus, der in einem einzelnen Projekt funktionierte, versagt an der Grenze. 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 Notfallwiederherstellung 

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

Die Datensicherung selbst. Anwendungskonsistente Datensicherung 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 Sicherungsmechanismus 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 Sicherungsdaten als Migrationsquelle dienen. Die Anwendungskonsistenz bleibt während der Verlagerung erhalten. 

Notfallwiederherstellung mit GCP. Google Cloud als DR-Ziel für Workloads vor Ort oder aus anderen Clouds. Das wirtschaftliche Modell ist entscheidend. Speichern Sie Sicherungskopien kontinuierlich und kostengünstig in GCP, verbrauchen Sie jedoch Rechenleistung und Hochleistungsspeicher erst dann, wenn tatsächlich eine Notfallwiederherstellung ausgelöst wird. Den größten Teil des Jahres zahlen Sie für Speicherplatz. An den seltenen Tagen, an denen eine Katastrophe eintritt, zahlen Sie für Rechenleistung. Das ist nur ein 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 lokalen Umgebungen. 

Stellen Sie das Festplatten-Image der Produktions-VM aus dem vorhandenen Backup wieder her. Exportieren Sie diese 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 mithilfe von `gcloud compute images import`, wobei Sie den Quell-Bucket und das Betriebssystem angeben. 

Sobald das benutzerdefinierte Image vorhanden ist, werden neue Compute Engine-Instanzen direkt daraus gestartet. Das gleiche Verfahren 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. Echte BaaS-Lösungen bauen auf diesen integrierten Funktionen auf. 

Wie stelle ich Daten nach einer versehentlichen Löschung oder einem Ransomware-Angriff wieder her? 

Stellen Sie Daten zu jedem beliebigen 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 Sicherungsdaten durchgehend innerhalb der GCP-Grenzen. 

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

Das sollte der Fall sein. SAP HANA benötigt anwendungsorientierte Backups, die in das Protokollmanagement von HANA integriert sind. GKE erfordert eine Granularität auf Container-, persistenter Volume- und Namespace-Ebene. BigQuery benötigt Backups auf Datensatz- und Tabellenebene. Ein Anbieter, der ausschließlich 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.