Google Cloud macht Cross-Region-Backups im Backup and DR Service allgemein verfügbar und gibt Admins damit mehr Kontrolle über Wiederherstellung nach regionalen Ausfällen, Fehlbedienung und Ransomware. Google hat die Neuerung am 25. Juni 2026 im Google Cloud Blog angekündigt. Für Unternehmen mit Workloads in Google-Cloud-Umgebungen ist die Änderung wichtig, weil Backups nicht mehr an die Region der primären Workload gebunden sind.
Der Kern der Neuerung ist einfach: Eine produktive Workload kann in einer Region laufen, während ihre Backups in einer anderen Region liegen. Google nennt dafür Compute Engine instances, Compute Engine disks und Filestore instances. Bei den Disks sind auch Persistent Disk und Hyperdisk relevant. Cloud SQL und AlloyDB sollen später folgen.
Das ist ein deutlicher Unterschied zu einfachen Backups in derselben Region. Wenn ein lokaler Ausfall, eine Fehlkonfiguration oder ein massives Betriebsproblem die Primärregion trifft, bleibt eine getrennte Backup-Region als zusätzlicher Wiederherstellungspfad. Google positioniert Cross-Region-Backups deshalb zwischen regionalem Backup, Multi-Region-Strategie und klassischer Disaster-Recovery-Architektur.
Für Admins zählt auch die Datenresidenz. Eine Firma kann gezielter festlegen, welche Sekundärregion für Sicherungen genutzt wird. Das ist für deutsche und europäische Unternehmen wichtig, weil Cloud-Architektur oft mit internen Compliance-Vorgaben, Datenschutz-Folgenabschätzungen, Kundenverträgen und regulatorischen Anforderungen zusammenhängt. Die neue Funktion ersetzt keine rechtliche Prüfung. Sie gibt Infrastrukturteams aber mehr technische Kontrolle.
Google Cloud trennt Backup-Ziel und Produktionsregion
Google beschreibt den Ablauf als Erweiterung bestehender Backup-and-DR-Workflows. Admins erstellen einen Backup Vault in einer Region, die sich von der Quellregion unterscheidet. Danach wird ein Backup-Plan in der Region der Ressource angelegt. In diesem Plan wählen Admins den Backup Vault in der Sekundärregion aus. Anschließend wird der Plan an die Ressource gebunden.
Der Backup and DR Service verschiebt die Backupdaten dann direkt in den regionalen Backup Vault außerhalb der Quellregion. Das reduziert die Abhängigkeit von einer einzelnen Region. Zugleich bleibt die Auswahl granularer als bei vordefinierten Multi-Region-Optionen. Unternehmen können so Kosten, Recovery-Ziele und Datenstandorte genauer gegeneinander abwägen.
| Baustein | Neue Rolle bei Cross-Region-Backups | Wichtig für Admins |
|---|---|---|
| Compute Engine | VM-Backups können in andere Regionen geschrieben werden | Schutz für virtuelle Maschinen |
| Persistent Disk und Hyperdisk | Disk-Backups können getrennt von der Quelle liegen | Hilft bei VM- und Datenvolumen-Recovery |
| Filestore | Dateisystem-Backups erhalten regionale Ausweichziele | Wichtig für gemeinsam genutzte Dateidienste |
| Cloud SQL | Unterstützung soll später folgen | Noch nicht Teil dieser GA-Funktion |
| AlloyDB | Unterstützung soll später folgen | Noch nicht Teil dieser GA-Funktion |
| Backup Vault | Zielregion für geschützte Backupdaten | Immutability und Indelibility werden zentral |
Google nennt in den Release Notes eine Einschränkung, die Admins sofort beachten müssen. Cross-Region-Backups stehen in dieser Phase über Google Cloud CLI, Terraform und API zur Verfügung. Teams mit starkem Console-Workflow sollten deshalb prüfen, ob ihre Betriebsprozesse schon Infrastruktur als Code oder Automatisierung verwenden.
Für größere Umgebungen ist das eher ein Vorteil. Backup-Konfigurationen gehören in reproduzierbare Deployments. Terraform, API und CLI erleichtern Reviews, Vier-Augen-Prinzip, Rollback und Standardisierung über Projekte hinweg. Ein manuell gesetzter Backup-Plan kann schnell vergessen werden. Eine versionierte Backup-Definition passt besser zu Audit, Change Management und Notfallübungen.
Der Bezug zu Ransomware liegt nicht nur in der zweiten Region. Google beschreibt den Backup and DR Service als zentral verwalteten Dienst mit Backup Vaults, die unveränderbare und nicht löschbare Sicherungen ermöglichen sollen. Genau solche Eigenschaften sind bei Ransomware entscheidend. Angreifer versuchen häufig, produktive Daten und Backups gleichzeitig zu löschen oder zu verschlüsseln. Eine getrennte Region plus geschützter Backup Vault erschwert dieses Szenario.
Der Ansatz passt zu einem breiteren Sicherheitsbild. Unsere Einordnung zum Digitaltag 2026 behandelt digitale Sicherheit als Alltags- und Unternehmensthema. Bei Cloud-Backups geht es um denselben Grundsatz: Schutz entsteht nicht erst im Ernstfall. Er entsteht durch vorbereitete Prozesse, klare Verantwortlichkeiten und getestete Wiederherstellung.
Admins müssen Datenresidenz, Kosten und Recovery-Ziele prüfen
Cross-Region-Backups lösen nicht jede Disaster-Recovery-Aufgabe. Ein Backup in einer zweiten Region ist ein starker Schutzbaustein. Es ist aber kein automatisches Failover für jede Anwendung. Unternehmen müssen Recovery Time Objective, Recovery Point Objective, Abhängigkeiten, Netzwerkpfade, IAM-Rechte, Schlüsselverwaltung und Wiederanlaufpläne getrennt prüfen.
Auch die Kostenfrage bleibt wichtig. Google positioniert Cross-Region-Backups als granularere Alternative zu Multi-Region-Ansätzen. Das kann günstiger sein, wenn nicht jede Anwendung nahe Null-Ausfallzeit braucht. Kritische Systeme mit sehr kurzen Wiederherstellungszielen brauchen aber weiterhin zusätzliche Replikation, Tests und Automatisierung. Backups allein garantieren keine sofortige Rückkehr in den Normalbetrieb.
| Prüffrage | Warum sie wichtig ist | Konkreter Admin-Schritt |
|---|---|---|
| Welche Region speichert das Backup | Datenresidenz und Compliance hängen daran | Sekundärregion dokumentieren |
| Welche Workloads sind unterstützt | Cloud SQL und AlloyDB folgen erst später | Compute Engine, Disks und Filestore priorisieren |
| Wie läuft die Wiederherstellung | Backup ist nur so gut wie der Restore | Restore-Runbook schreiben |
| Wer darf Backups ändern | Ransomware zielt oft auf Backuprechte | IAM und Adminrollen begrenzen |
| Welche Kosten entstehen | Cross-Region-Strategien erzeugen Zusatzkosten | Schutzklassen definieren |
| Wie oft wird getestet | Ungeprüfte Backups scheitern im Ernstfall | Regelmäßige Recovery-Übung einplanen |
Für DACH-Unternehmen ist die Regionenauswahl besonders sensibel. Google listet mehrere europäische Regionen, darunter Berlin und Frankfurt. Das erlaubt Architekturen, bei denen produktive Systeme und Backups innerhalb Europas bleiben können. Trotzdem müssen Firmen prüfen, ob ihre konkrete Workload, ihr Backup Vault, ihre Schlüssel und ihre organisatorischen Prozesse zur eigenen Compliance passen.
Ransomware-Schutz beginnt zudem nicht beim Backup allein. Zugangsschutz, starke Authentisierung und Berechtigungsmanagement bleiben Pflicht. Google Passkeys und Passwortmanager und 2FA betreffen zwar Nutzerkonten, sie verfolgen aber denselben Sicherheitsgedanken: Ein Angreifer soll möglichst früh scheitern. Backup Vaults helfen erst später in der Kette.
Für Entwicklerteams kommt eine weitere Ebene hinzu. Infrastrukturänderungen brauchen dieselbe Sorgfalt wie Codeänderungen. GitHub Dependabot gehört in einen anderen Werkzeugbereich, erinnert aber an ein wichtiges Muster: Automatisierte Sicherheit braucht Regeln, Review und Tests. Bei Backup-Plänen gilt das genauso.
Google-Cloud-Admins sollten nach der GA-Ankündigung zuerst ihre Schutzklassen sortieren. Nicht jede VM braucht sofort ein Cross-Region-Backup. Kritische Systeme, gemeinsam genutzte Dateidienste, wichtige Datenvolumen und Wiederherstellungsabhängigkeiten sollten aber oben stehen. Danach folgen Terraform-Module, API-Berechtigungen, regionale Zielvorgaben, Retention und Restore-Tests.
- Compute Engine zuerst prüfen, wenn VMs zentrale Geschäftsanwendungen tragen.
- Persistent Disk und Hyperdisk getrennt betrachten, weil Datenvolumen oft wichtiger als einzelne Maschinen sind.
- Filestore einbeziehen, wenn Teams gemeinsam auf Dateien, Build-Artefakte oder Anwendungsdaten zugreifen.
- Cloud SQL und AlloyDB nicht einplanen, bis Google die angekündigte Unterstützung nachliefert.
- Restore-Tests terminieren, bevor die neue Backup-Architektur als produktionsreif gilt.
Für weniger technische Google-Nutzer ist das Thema ebenfalls ein Hinweis auf die Bedeutung eigener Sicherungen. Google Takeout deckt private Daten in Gmail, Fotos, Drive und YouTube ab. Cross-Region-Backups im Backup and DR Service sind dagegen ein Unternehmenswerkzeug für Cloud-Workloads. Beide Themen zeigen aber denselben Grundsatz: Daten sollten nicht nur dort existieren, wo sie täglich genutzt werden.
Google Cloud Cross-Region-Backups sind im Backup and DR Service allgemein verfügbar, aber zunächst für Compute Engine, Disks und Filestore relevant. Cloud SQL und AlloyDB folgen später. Für Unternehmen ist die Funktion ein starker Baustein gegen regionale Ausfälle, Ransomware-Folgen und Datenverlust. Der echte Schutz entsteht erst durch passende Regionen, klare IAM-Regeln, Backup Vaults, dokumentierte Wiederherstellung und regelmäßige Tests.