Databricks Disaster Recovery: RPO, RTO und Managed DR richtig planen

Es ist Montag, 8:15 Uhr. Die Cloud-Region, in der Ihr Databricks-Workspace läuft, ist gestört. Das Vertriebsdashboard lädt nicht, der nächtliche Forecast-Job ist nicht gelaufen und die Geschäftsführung fragt, wann alles wieder geht. „Wir haben doch Backups“, sagt jemand im Call. Nur hilft ein Backup in genau dieser Situation kaum weiter.

Databricks Disaster Recovery bedeutet, dass Daten, Unity-Catalog-Metadaten und Workspace-Assets laufend in eine zweite Cloud-Region repliziert werden. So können Sie bei einem Regionsausfall innerhalb von Minuten weiterarbeiten. Inzwischen übernimmt Databricks selbst diese Replikation mit Managed Disaster Recovery. Die Funktion ist sowohl auf AWS als auch auf Azure verfügbar und wird vom Account-Team freigeschaltet. Entscheidend sind vorher zwei Zielwerte pro Workload: wie viel Datenverlust (RPO) und wie viel Ausfallzeit (RTO) Sie akzeptieren.

Bevor Sie weiterlesen: Sie möchten S3-Buckets oder Azure-Speicher per Cloud-Replikation in eine zweite Region spiegeln und das „Disaster Recovery“ nennen? Dann halten Sie kurz an. Databricks empfiehlt für Delta-Tabellen ausdrücklich Deep Clone, also eine Kopie der kompletten Tabelle samt Versionsverlauf, statt reiner Storage-Replikation. Dieser Ratgeber zeigt, welche Disaster Recovery Strategie im Ernstfall tatsächlich hilft.

Was RPO und RTO für Ihre Datenplattform bedeuten

Jedes Gespräch über Ausfallsicherheit landet früher oder später bei zwei Abkürzungen. Diese klingen zwar sehr technisch, stellen aber zwei sehr praktische Fragen dar.

• RPO (Recovery Point Objective): Wie viele Daten dürfen bei einem Ausfall verloren gehen? Ein RPO von 15 Minuten bedeutet, dass alles, was in den letzten 15 Minuten vor dem Ausfall geschrieben wurde, fehlen darf.
• RTO (Recovery Time Objective): Wie lange darf es dauern, bis der Workload in der Ausweichregion wieder läuft? Ein RTO von vier Stunden bedeutet, dass der Vertrieb nach einem Regionsausfall um acht Uhr spätestens um zwölf Uhr wieder auf seine Dashboards zugreifen kann.

RTO und RPO legen Sie nicht für die Plattform als Ganzes fest, sondern pro Workload. Die automatische Preisanpassung im Onlineshop hat beispielsweise andere Anforderungen als das Monatsreporting im Controlling. Databricks hat bei seinen Kunden beobachtet, dass die meisten Anforderungen bei einem RPO von rund 15 Minuten und einem RTO von rund vier Stunden liegen.

Drei Strategien, drei Preisschilder

Managed Disaster Recovery auf Databricks arbeitet nach dem Active-Passive-Prinzip. Die Sekundärregion bekommt dabei laufend Daten und Konfiguration, aber Cluster, Jobs und SQL Warehouses bleiben dort ausgeschaltet, bis Sie den Failover auslösen und die Sekundärregion zur neuen Hauptregion machen.

Was die Regulatorik verlangt

Für Versicherer und andere Finanzunternehmen sind dokumentierte Notfall- und Wiederherstellungspläne seit dem 17.01.2025 gesetzlich vorgeschrieben. Die EU-Verordnung DORA verlangt in Art. 12 Abs. 6, dass die Wiederherstellungszeit und der Wiederherstellungspunkt für jede Funktion festgelegt werden, abhängig davon, wie wichtig die Funktion für Ihr Unternehmen ist. Feste Minutenwerte gibt die Verordnung jedoch nicht vor. Für die Business Continuity Ihrer Datenplattform heißt das, dass Sie Zielwerte festlegen, aufschreiben und regelmäßig testen sollten.

Disaster Recovery ist weder Backup noch Hochverfügbarkeit

Die drei Begriffe werden in fast jedem Projekt durcheinandergeworfen. Der Unterschied ist jedoch wichtig, da jede Variante vor einem anderen Problem schützt.

Die Databricks-Dokumentation zu Disaster Recovery hebt hervor, dass eine DR-Lösung nicht vor Datenkorruption schützt. Wenn ein fehlerhafter Job Ihre Kundentabelle überschreibt, steht dieser Fehler ein paar Minuten später auch in der Sekundärregion. Statt Replikation hilft hier Time Travel auf Delta-Tabellen.

Eine dritte Abgrenzung betrifft Migrationen. Weil Managed DR ohnehin alles in eine zweite Region kopiert, möchten manche Teams es für den Wechsel in eine neue Region nutzen. Wir würden davon abraten, da das Produkt nicht dafür gebaut ist. Darüber hinaus braucht eine Migration einen eigenen Plan mit Tests und Abnahme. Für Umzüge lesen Sie besser unsere Migrationsstrategien für Ihr Data Lakehouse.

Welche der drei Varianten Ihre Plattform braucht, hängt von Ihren Workloads und nicht von der Technik ab. Genau das klären wir in der Databricks-Beratung gemeinsam mit Ihrem Team, bevor jemand eine zweite Region bucht.

Expertentipp von Laurenz, CTO bei Datasolut:

Klären Sie zuerst, ob Ihr Problem ein Regionsausfall oder ein Datenfehler ist. Die meisten Ausfälle, die Fachbereiche spüren, sind kaputte Pipelines in der eigenen Region und keine Regionsausfälle. Dagegen hilft ein sauberes Delta-Setup mit Time Travel mehr als eine zweite Region.

So funktioniert Managed Disaster Recovery auf Databricks

Bisher mussten Unternehmen Disaster Recovery auf Databricks mithilfe von Terraform für Workspaces, Skripten für Berechtigungen und Deep-Clone-Jobs für Tabellen selbst bauen. Managed Disaster Recovery nimmt Ihnen diesen Eigenbau ab. Databricks bezeichnet Managed DR als „Gated GA“, also produktiv nutzbar, aber zugangsbeschränkt. Laut Databricks-Dokumentation (21.10.2026) ist die Funktion für AWS und Azure verfügbar. Den Zugang können Sie dabei über Ihr Databricks-Account-Team beantragen. 

Failover Groups bündeln, was gemeinsam umziehen muss

Das zentrale Objekt heißt Failover Group. Diese legen Sie in der Account Console unter Resilience an und definieren darin:

• den primären und den sekundären Workspace
• die Kataloge, die repliziert werden sollen
• ob zusätzlich Workspace-Assets wie Notebooks, Jobs und SQL Warehouses mitkommen sollen
• die Zuordnung der Speicherorte zwischen beiden Regionen (Storage Mappings)
• optional eine Stable URL

Sie müssen also nicht den ganzen Account schützen. Das ist wichtig für die Kosten, dazu aber gleich mehr.

Deep Clone mit Versionsverlauf hält Tabellen konsistent

Für Managed Tables nutzt Databricks Deep Clone mit Versionsverlauf (CLONE WITH HISTORY), der auf Serverless Compute in der Primärregion ausgeführt wird. Laut Databricks läuft dieser Abgleich ungefähr alle sieben Minuten pro Katalog. Nach dem ersten Komplettlauf wird nur noch die Differenz repliziert. Workspace-Assets wie zum Beispiel Jobs und Notebooks überträgt Databricks wiederum über einen separaten Mechanismus, der ebenfalls nur die Änderungen kopiert.

Warum nicht einfach den Bucket spiegeln? Eine Delta-Tabelle besteht aus Datendateien und einem Transaktionslog. Repliziert ein Storage-Dienst beides unabhängig voneinander, kann das Log in der Zielregion schon auf Dateien verweisen, die noch gar nicht angekommen sind. Die Tabelle ist dann inkonsistent. Deep Clone dagegen kopiert die Tabellenversionen als Ganzes.

Stable URLs: Ein Hostname für beide Regionen

Ohne Stable URL zeigt jedes BI-Tool, jede Datenverbindung (etwa über JDBC) und jedes Skript auf die URL des primären Workspace. Nach einem Failover müssten Sie alle Clients umkonfigurieren, und zwar genau dann, wenn ohnehin alle nervös sind.

Die Stable URL löst dieses Problem. Sie zeigt immer auf den aktuell aktiven Workspace und funktioniert für die Weboberfläche, JDBC/ODBC-Verbindungen zu SQL Warehouses und direkte REST-API-Aufrufe. Voraussetzung sind eine eigene Webadresse für Databricks (Custom URL) und eine zentrale Anmeldung über das Databricks-Konto (Account-Level OAuth). Außerdem behalten Jobs, Notebooks und Dashboards in beiden Regionen dieselbe Kennung, weswegen gespeicherte Links und Lesezeichen auch nach dem Umschalten weiter funktionieren.

Active-Passive: Die Sekundärregion ist schreibgeschützt

Solange repliziert wird, sind die replizierten Kataloge in der Sekundärregion schreibgeschützt. Job-Schedules (automatische Jobs) sind pausiert, Cluster liegen im Zustand TERMINATED, SQL Warehouses im Zustand STOPPED. Compute können Sie dort nicht starten. Das verhindert, dass beide Regionen gleichzeitig schreiben und Ihre Daten auseinanderlaufen.

Beim Failover kehrt Databricks die Replikationsrichtung um, schaltet die Stable URL um und pausiert die Schedules in der bisherigen Primärregion. Laut Dokumentation dauert der Failover selbst nur wenige Minuten. Databricks peilt für RPO und RTO jeweils höchstens 15 Minuten an, garantiert diese Werte jedoch nicht vertraglich. Failback, also das Zurückschalten in die ursprüngliche Region, funktioniert über denselben Knopf in umgekehrter Richtung.

Was repliziert wird und was nicht

Wichtig für externe Tabellen: Es werden nur die Metadaten repliziert. Die Daten selbst müssen Sie über Ihren Cloud-Speicher in die Sekundärregion bringen.

Was als Nächstes kommt: Die Funktionen in der Testphase stehen bereits unter Private Preview in der Tabelle. Bei Zeilenfiltern, Spaltenmasken und ABAC gilt laut Databricks zunächst keine Konsistenzgarantie. 

Für 2027 hat Databricks außerdem angekündigt, dass Managed DR auch Managed Volumes, ML-Modelle, Model Serving Endpoints und Delta Shares repliziert. Zusätzlich soll ein Failover zu einem anderen Cloud-Anbieter möglich werden. Stand heute müssen Primär- und Sekundär-Workspace in derselben Cloud liegen. Wer von AWS nach Azure umschalten will, braucht dafür noch einen Eigenbau.

Was kostet Databricks Disaster Recovery?

Wir als Databricks Silver Partner empfehlen Managed DR für passende Workloads, obwohl es Ihre Databricks-Rechnung erhöht. Aus diesem Grund rechnen wir Ihnen die Kosten, die aus drei Teilen bestehen, einmal offen vor:

1. Mission Critical Add-on

Managed Disaster Recovery setzt das Mission Critical Add-on auf beiden Workspaces voraus. Es handelt sich dabei um einen kostenpflichtigen Zusatzbaustein, den Sie für beide buchen müssen. Laut der Azure-Databricks-Preisseite (Stand Oktober 2026) kostet es 30 Prozent Aufschlag auf den Listenpreis der Databricks-Nutzung im jeweiligen Workspace, mit einem Aktionsrabatt von 50 Prozent bis zum 30.06.2027. Effektiv zahlen Sie im Aktionszeitraum also 15 Prozent Aufschlag, was Databricks auch als Einführungspreis für das erste Jahr kommuniziert. Das Add-on enthält neben Managed DR auch das Enhanced Security and Compliance Add-on, ein Paket mit zusätzlichen Sicherheits- und Prüffunktionen für regulierte Branchen. Wer dieses schon nutzt, bekommt DR im Aktionszeitraum faktisch ohne große Mehrkosten zum Testen. Die AWS-Dokumentation verweist für den aktuellen Preis auf das Account-Team.

Voraussetzung ist auf AWS der Enterprise-Tarif und auf Azure der Premium-Tarif.

2. Replikationsgebühr pro Gigabyte

Seit September 2026 berechnet Databricks zusätzlich eine Replikationsgebühr für die kopierten Daten. Laut Databricks liegt diese bei rund 0,02 USD pro übertragenem Gigabyte, je nach Region kann der Preis etwas abweichen. Auf der Azure-Preisseite ist die Gebühr als eigener Posten aufgeführt, allerdings ohne einen festen Preis. Den aktuellen Betrag für Ihre Region erhalten Sie von Ihrem Ansprechpartner bei Databricks.

3. Datentransfer zwischen Regionen

Zusätzlich berechnet Ihr Cloud-Anbieter den Datentransfer zwischen den Regionen. Diese Kosten gehen nicht an Databricks, sondern an AWS oder Microsoft. In Europa liegen sie typischerweise im Bereich weniger US-Cent pro GB. 

Beispielrechnung

Die folgende Rechnung ist vereinfacht und arbeitet mit Annahmen. Sie zeigt die Größenordnung, nicht Ihr Angebot.

Teuer wird es also nicht durch die Datenmenge, sondern durch den Aufschlag auf die Compute-Kosten. Daraus folgt die klare Empfehlung, Workloads, die DR brauchen, in eigene Workspaces zu legen. Wer den Aufschlag auf einen Workspace zahlt, in dem auch Sandbox-Experimente und Ad-hoc-Analysen laufen, zahlt auch für deren Ausfallsicherheit mit. Mehr zur Kostensteuerung lesen Sie in unserem Beitrag zu FinOps auf Databricks.

In fünf Schritten zum Disaster Recovery Konzept auf Databricks

Schritt 1: RPO und RTO je Workload festlegen

Was in diesem Schritt passiert: Sie listen Ihre Workloads auf und fragen die Fachbereiche, was ein Ausfall von einer Stunde, einem Tag und einer Woche kosten würde. Daraus leiten Sie RPO und RTO ab.

Worauf Sie achten sollten:

• Fragen Sie nach Folgen, nicht nach Wunschwerten. Wer gefragt wird, ob er null Datenverlust möchte, sagt immer ja.
• Denken Sie an Abhängigkeiten außerhalb von Databricks, wie Quellsysteme, Ingestion-Tools und BI-Tools.

Typischer Fehler: Ein RPO für die ganze Plattform. Das macht entweder alles zu teuer oder das Wichtige zu unsicher.

Schritt 2: Regionspaar und Voraussetzungen klären

Was in diesem Schritt passiert: Sie wählen eine Sekundärregion, die DR-fähig ist und alle Dienste anbietet, die Sie nutzen. Beide Workspaces müssen im selben Databricks-Account und in derselben Cloud liegen.

Worauf Sie achten sollten:

• In jeder Region brauchen Sie einen eigenen Unity-Catalog-Metastore. Der sekundäre Metastore darf keine gleichnamigen Kataloge enthalten.
• Identitäten müssen auf Account-Ebene existieren, synchronisiert über SCIM oder Automatic Identity Management und mit Account-Level SSO. Sonst kann sich nach dem Failover niemand in der zweiten Region anmelden.
• External Locations und Storage Credentials kopiert Databricks nicht mit, weshalb Sie diese in beiden Regionen selbst anlegen müssen. Auf AWS müssen die Credentials auf dieselbe IAM-Rolle zeigen.
• Netzwerkobjekte wie Network Connectivity Configuration und IP-Access-Listen müssen an beiden Workspaces hängen, sonst ist die zweite Region im Ernstfall nicht erreichbar.

Typischer Fehler: Workspace-lokale Benutzer und Gruppen. Sie existieren in der Sekundärregion nicht und nach dem Failover kommt niemand mehr an seine Daten.

Warum Lakehouses die Datenarchitektur der Zukunft sind

In unserem Whitepaper erfahren Sie:

• Wie sich ein Data Lakehouse von anderen Architekturen unterscheidet.
• Wie Sie durch ein Lakehouse KI-Anwendungen schneller umsetzen.
• Wie Sie Ihr internes Team befähigen, selbstständig KI Projekte zu implementieren.

Jetzt herunterladen

Schritt 3: Mission Critical aktivieren und Failover Group anlegen

Was in diesem Schritt passiert: Sie schalten das Add-on in der Account Console für beide Workspaces ein und legen unter Resilience zuerst die Stable URL und dann die Failover Group an. Danach startet die initiale Replikation.

Worauf Sie achten sollten:

• Die erste Replikation der Workspace-Assets kann bei großen Workspaces bis zu fünf Tage dauern. Fällt die Hauptregion in dieser Zeit aus, können Sie wegen der unvollständigen Kopie noch nicht auf die zweite Region umschalten. Bis die Erstkopie abgeschlossen ist, sind Sie also noch nicht abgesichert.
• Wenn Sie Workspace-Assets replizieren, überschreibt Databricks im sekundären Workspace alle vorhandenen Notebooks, Jobs und anderen Assets derselben Art. Nutzen Sie dafür deshalb einen leeren Workspace, der ausschließlich als Ausweichstandort dient, und sichern Sie vorher alles, was dort schon liegt.

Typischer Fehler: Die Failover Group kurz vor einem Audit oder Go-live anlegen und dann auf die Erstreplikation warten.

Schritt 4: Clients und CI/CD auf die Stable URL umstellen

Was in diesem Schritt passiert: Sie ändern Hostnamen in BI-Tools, JDBC/ODBC-Verbindungen und Skripten auf die Stable URL. Terraform und Databricks Asset Bundles stellen Sie auf die Custom URL und die stabile Workspace-ID um.

Worauf Sie achten sollten:

• Bestehende Terraform-Projekte nicht einfach auf die neue Adresse umstellen. Terraform erkennt die vorhandenen Ressourcen sonst nicht wieder und legt sie neu an. Übernehmen Sie stattdessen die Bestandsliste des alten Projekts (den State) in ein neues Projekt, das bereits mit der Stable URL arbeitet.
• Wenn Sie Databricks Asset Bundles nutzen, schalten Sie in der Failover Group auch die Kopie der Workspace-Assets ein. Asset Bundles speichern ihre Bestandsliste im Workspace selbst. Ohne diese Kopie fehlt die Liste nach dem Failover, und beim nächsten Ausspielen können doppelte oder fehlerhafte Jobs entstehen.

Typischer Fehler: Die Weboberfläche läuft über die Stable URL, das Power-BI-Gateway aber noch über die alte Workspace-URL.

Schritt 5: Failover regelmäßig testen

Was in diesem Schritt passiert: Sie führen einen geplanten Failover durch, prüfen Jobs, Dashboards und Berechtigungen in der Sekundärregion und schalten zurück. Databricks empfiehlt, einmal pro Quartal zu testen.

Worauf Sie achten sollten:

• Bei einem geplanten Failover stoppen Sie zuerst alle Schreibvorgänge und warten, bis der Replikationspunkt aufgeholt hat. Dann verlieren Sie keine Daten.
• Die Zeitpläne Ihrer Job-Schedules schalten Sie nach dem Failover in der neuen Hauptregion von Hand wieder ein. Databricks pausiert sie dort, damit keine Jobs doppelt laufen.
• Den Replikationsstand über die Zeit sehen Sie in Databricks‘ Systemtabelle system.replication.states.

Typischer Fehler: Ein DR-Konzept, das nur auf dem Papier existiert. Ungetestet scheitert es meist am ersten fehlenden Secret.

Sechs Stolperfallen, die im Ernstfall teuer werden

Die Liste der nicht replizierten Assets liest sich harmlos. Im Unternehmensalltag entscheidet sie aber darüber, ob der Failover in Minuten oder in Stunden endet.

Stolperfalle 1: Secrets fehlen in der Sekundärregion

Unity-Catalog- und Workspace-Secrets werden nicht repliziert. Ihre Jobs sind nach dem Failover da, aber die Zugangsdaten zum Quellsystem fehlen. Legen Sie Secrets per Terraform oder Skript in beiden Regionen an und prüfen Sie das im Test.

Stolperfalle 2: Time Travel nach Zeitstempel liefert falsche Versionen

Ohne In-Commit-Timestamps übernimmt die Kopie in der zweiten Region den Kopierzeitpunkt als Änderungszeit. Abfragen eines früheren Tabellenstands nach Uhrzeit (Time Travel) liefern dann eine falsche Version, ohne dass eine Fehlermeldung erscheint. Schalten Sie die Einstellung deshalb vor dem Start der Replikation ein (delta.enableInCommitTimestamps = true).

Stolperfalle 3: Schreibzugriffe externer Engines gehen verloren

Managed DR erkennt Änderungen, die über Databricks-Compute geschrieben werden. Schreibt ein externes System über offene Schnittstellen wie den Iceberg REST Catalog in eine Managed Table, kann diese Änderung unbemerkt bleiben. Schreiben Sie replizierte Tabellen deshalb nur über Databricks.

Stolperfalle 4: Private Link zum Speicher blockiert die Datenkopie

Ist Ihr S3-Bucket nur über eine private Netzwerkanbindung (Private Link) erreichbar, kann Managed DR die Tabellendaten nicht kopieren. Klären Sie das früh mit dem Account-Team und nicht erst, wenn die Failover Group Fehler meldet.

Stolperfalle 5: Archivierte Tabellen und Zeilenfilter halten das RPO auf

Tabellen mit Delta-Archivierung sowie Tabellen mit Zeilenfiltern, Spaltenmasken oder ABAC-Tags werden als „Failed to replicate“ markiert. Solange sie im Replikationsumfang stehen, bleibt der Replikationspunkt der ganzen Failover Group stehen. Ein einzelnes Objekt kann so Ihr RPO für alle anderen Tabellen verschlechtern.

Stolperfalle 6: Streaming außerhalb von Lakeflow läuft ins Leere

Spark Structured Streaming außerhalb von Lakeflow-Pipelines wird nicht repliziert. Checkpoints müssen in kundeneigenem Speicher liegen und in die Sekundärregion kommen, sonst startet der Stream nach dem Failover nicht dort, wo er aufgehört hat.

Was wir daraus ableiten: Machen Sie vor dem Anlegen der Failover Group eine Inventur. Welche Workloads nutzen Secrets, Streaming außerhalb von Lakeflow, Model Serving oder externe Schreibzugriffe? Für diese Punkte brauchen Sie neben Managed DR einen eigenen Plan.

Lakebase: Disaster Recovery für operative Datenbanken

Für Ihre Postgres-Datenbanken auf Lakebase gibt es ein eigenes DR-Verfahren, das von den Failover Groups getrennt ist. Managed DR schützt Lakebase nicht mit und Lakebase-DR kopiert umgekehrt keine Delta-Tabellen. Wer beides nutzt, benötigt somit zwei Notfallpläne.

Databricks hat in der Lakebase-Keynote eine Cross-Cloud-Disaster-Recovery als Private Preview vorgestellt, etwa von AWS nach Azure. Die Lakebase-Dokumentation (09.10.2026) beschreibt einen engeren Umfang, bei dem die Replikation zwischen zwei Regionen als Private Preview und ausdrücklich nicht für den Produktivbetrieb gedacht ist.

So funktioniert die Replikation bei Lakebase

Lakebase kopiert die gespeicherten Daten in regelmäßigen Abständen in die zweite Region, und zwar direkt von Speicher zu Speicher. Die Rechenleistung dort bleibt bis zum Failover ausgeschaltet, Sie zahlen also nicht für eine dauerhaft laufende Ersatzdatenbank. Wie weit die Kopie zurückliegt, zeigt Lakebase als eigene Kennzahl an. Databricks spricht von einem RPO „im Minutenbereich“, einen festen Wert für das RTO nennt die Dokumentation jedoch nicht.

Hochverfügbarkeit und Disaster Recovery ergänzen sich

Für geschäftskritische Anwendungen empfiehlt Databricks, beides zu kombinieren. Die Einstellungen zur Hochverfügbarkeit werden in die zweite Region übernommen.

Was beim Failover zu beachten ist

• Umschalten nur von Hand: Ein Projekt-Administrator löst den Failover aus. Danach braucht Ihre Anwendung die neue Verbindungsadresse und ein neues Zugangstoken.
• Offene Transaktionen bleiben erhalten: Was vor dem Ausfall nicht mehr kopiert wurde, bleibt in der alten Region als Recovery Branch erhalten. Abgleichen müssen Sie sie selbst, Lakebase führt sie nicht automatisch zusammen.
• Verbindungen zum Lakehouse neu einrichten: Synchronisierte Tabellen und Datenströme von Lakebase ins Lakehouse stoppen beim Failover und laufen nicht von selbst wieder an.
• Zurückschalten ohne Datenverlust: Stoppen Sie vorher alle Schreibzugriffe und warten Sie, bis die Kopie aufgeholt hat.
• Was noch fehlt: eine einheitliche Adresse für beide Regionen, private Netzwerkverbindungen für die Replikation und Lesezugriffe auf die Kopie in der zweiten Region.

Gegen Fehler und versehentliches Löschen hilft auch bei Lakebase nicht DR, sondern Point-in-Time-Restore. Damit setzen Sie die Datenbank auf einen früheren Zeitpunkt zurück, laut Databricks mit einer Aufbewahrung von bis zu 30 Tagen.

Unsere Einschätzung: Lakebase-DR ist eine sinnvolle Ergänzung für Anwendungen, die auf Lakebase laufen. Für produktive Notfallpläne würden wir uns Stand heute aber noch nicht darauf verlassen. Beobachten Sie den Status und testen Sie früh, sofern Lakebase bei Ihnen geschäftskritische Anwendungen trägt. Wie Lakebase im Versicherungsumfeld produktiv eingesetzt wird, zeigt unsere Case Study Databricks Lakebase in der Versicherungsbranche.

Für welche Workloads lohnt sich Managed DR?

Sie betreiben eine einzige Databricks-Umgebung für ein paar Dashboards und laden die Daten ohnehin täglich neu aus den Quellsystemen? Dann brauchen Sie kein Managed DR. Hier ist es günstiger, im Ernstfall einen neuen Workspace aufzusetzen und die Pipelines neu laufen zu lassen. Das sagen wir auch im Erstgespräch so.

Fazit: Disaster Recovery auf Databricks beginnt mit den richtigen Zielwerten

Managed DR macht Disaster Recovery auf Databricks deutlich zugänglicher. Failover Groups, konsistente Replikation per Deep Clone und Stable URLs ersetzen einen großen Teil des Eigenbaus, der bisher nötig war. Die eigentliche Arbeit liegt aber davor, da Sie festlegen müssen, welche Workloads welches RPO und RTO Sie brauchen. Anschließend nehmen Sie nur diese in die Failover Group auf. Prüfen Sie dann die Lücken bei Secrets, Streaming und Model Serving und testen Sie den Failover einmal pro Quartal. Wer so vorgeht, zahlt den Mission-Critical-Aufschlag nur dort, wo ein Ausfall wirklich wehtut.

Häufig gestellte Fragen zu Disaster Recovery auf Databricks

Vinzent Wuttke

Geschäftsführer

Ihr nächster Schritt mit uns!

Databricks ist eine der leistungsfähigsten Plattformen für Daten und KI – aber ihr volles Potenzial entfaltet sich erst, wenn Ihr Team sie wirklich beherrscht. Lassen Sie uns gemeinsam schauen, welche Schulungspakete zu Ihrer Ausgangssituation passen.

Im kostenlosen Erstgespräch klären wir:

• Welche Rollen und Teams von welchem Paket am meisten profitieren
• Ob und wie wir Inhalte auf Ihre Datenarchitektur und Use Cases anpassen
• Wie ein realistischer Zeitplan und die nächsten Schritte aussehen

Erstgespräch vereinbaren