Vollständige Anleitung zur Sicherung und Wiederherstellung von Cassandra-Datenbanken

Einführung: Warum sind Backups für Cassandra so wichtig?

Cassandra ist dafür ausgelegt, niemals auszufallen. Cassandra-Backups sind wichtig, denn ohne ein ordnungsgemäßes Backup besteht die Gefahr, dass wichtige Daten verloren gehen. Die Replikation ist zwar eine wichtige Komponente, die vor Hardwareausfällen schützt, aber sie schützt nicht vor Datenverlust. Daher ist eine wiederherstellbare Sicherungskopie und die Aufbewahrung von Kopien an einem separaten Ort eine Notwendigkeit, um alle Ihre Daten zu schützen.

Für welche Arten von Ausfällen oder Zwischenfällen ist ein Backup- und Wiederherstellungsplan erforderlich?

Backup- und Wiederherstellungspläne sind für logische Ausfälle erforderlich, die durch die Replikation nicht abgedeckt werden können. Dazu gehören versehentliches Löschen, Datenbeschädigung, Ransomware und fehlgeschlagene Upgrades. Cassandra kopiert jede Operation gleichzeitig auf alle Replikate, was bedeutet, dass im Falle eines dieser Probleme der gesamte Cluster in Mitleidenschaft gezogen wird.

Im Folgenden gehen wir auf typische Ausfälle und Vorfälle ein, die einen Backup- und Wiederherstellungsplan erfordern.

• Versehentliches Löschen von Daten: Sie führen DROP TABLE oder TRUNCATE auf dem falschen Cluster aus, wodurch Ihre Daten auf allen Replikaten gelöscht werden.
• Beschädigung der Daten: Ein Software-, Hardware- oder Dateisystemproblem, das ein Rollback auf einen stabilen Zustand erfordert.
• Fehlgeschlagene Upgrades: Unsachgemäße Datenbankkonfiguration oder Upgrades, die zu beschädigten Daten führen oder SSTable-Dateien in einem inkompatiblen Format hinterlassen.
• Ransomware: Bösartige Software, die Cassandra-Datenverzeichnisse verschlüsselt und Ihre Daten unlesbar macht.
• Böswilliger Insider: Jemand innerhalb des Teams, der absichtlich Daten löscht oder vernichtet (ein weniger seltenes Szenario, als die meisten annehmen).

Was sind die geschäftlichen und technischen RPO- (Recovery Point Objective) und RTO- (Recovery Time Objective) Überlegungen?

RPO und RTO sind zwei wichtige Metriken, die direkt bestimmen, wie häufig Backups durchgeführt werden sollten oder wie schnell die Wiederherstellung abgeschlossen sein muss. Jede Backup-Entscheidung, die ein Unternehmen trifft, hängt direkt von diesen beiden Faktoren ab:

Das Recovery Point Objective (RPO) definiert den Umfang des Datenverlusts, den Ihr Unternehmen tolerieren kann, ausgedrückt in Stunden. Ein RPO von 4 Stunden bedeutet z.B., dass Sie nicht mehr als 4 Stunden Daten verlieren können; daher ist alle 4 Stunden ein Backup erforderlich.

Das Recovery Time Objective (RTO) hingegen legt fest, wie lange Ihr Unternehmen nicht verfügbar sein darf, während Sie sich auf den Wiederherstellungsprozess konzentrieren. Nehmen wir an, Ihr RTO beträgt 2 Stunden. In diesem Fall haben Sie 2 Stunden Zeit für die Wiederherstellung; das Unternehmen könnte ernsthafte finanzielle Probleme haben.

Beide Kennzahlen sind wichtig, weil sie geschäftliche Entscheidungen beeinflussen, die sich direkt auf Ihre Cassandra-Backup-Strategie auswirken können.

Welche Risiken birgt das Fehlen einer zuverlässigen Strategie zur Sicherung von Apache Cassandra-Daten?

Die Replikation allein ist für die Datensicherung nicht ausreichend und stellt daher ein großes Risiko für jedes Unternehmen dar. Die Folgen gehen über den Datenverlust hinaus und beeinträchtigen die betriebliche Kontinuität, die Compliance und das Vertrauen der Benutzer. Hier sind die wichtigsten Probleme, denen Unternehmen ohne eine zuverlässige Cassandra-Backup-Strategie ausgesetzt sind.

• Permanenter Datenverlust: Eine fehlende oder unzuverlässige Backup-Strategie bedeutet, dass es keinen Wiederherstellungspfad gibt, und im Falle einer Katastrophe kann das, was verloren gegangen ist, nicht wiederhergestellt werden.
• Längere Ausfallzeiten: Ohne eine Backup-Strategie und klar definierte RTO- und RPO-Zeiten kann Ihr Unternehmen am Ende mehr verlieren als erwartet.
• Einhaltung von Richtlinien und Vorschriften: Branchen wie das Gesundheitswesen und das Finanzwesen unterliegen strengen Vorschriften. Ohne eine angemessene Cassandra-Backup-Strategie kann die Nichteinhaltung dieser Vorschriften zu erheblichen finanziellen Strafen führen.
• Schädigung des Rufs: Wenn Benutzerdaten gefährdet sind, können Unternehmen einen dauerhaften Imageschaden erleiden, der im Laufe der Zeit zu einem allmählichen Verlust von Benutzern und Vertrauen führt.

Wie wirkt sich die Einsatzarchitektur von Apache Cassandra auf den Backup-Bedarf aus?

Die Einsatzarchitektur von Cassandra kann den Backup-Bedarf stark beeinflussen. Sie bestimmt, wie risikoreich oder wie komplex die Backup-Strategie sein sollte. Jede Einsatzart bringt spezifische Herausforderungen mit sich, die mit einem Einheitsansatz nicht zu bewältigen sind.

1. Multi-Datacenter-Einsätze

Bei Implementierungen mit mehreren Rechenzentren werden die Backup-Vorgänge in der Regel von einem dedizierten sekundären Rechenzentrum und nicht von den Produktionsknoten aus durchgeführt, um zu verhindern, dass die Backup-Aktivitäten die Live-Performance beeinträchtigen. Dieses dedizierte Rechenzentrum erhält die gleichen replizierten Daten wie die Produktion, wickelt aber alle Backup-Workloads separat ab, so dass die primären Knoten für den Benutzerverkehr frei bleiben.

2. Cloud/AWS – EBS vs. Instance Store

Cloud-Bereitstellungen auf AWS erfordern je nach Speichertyp unterschiedliche Backup-Ansätze. Knoten, die auf EBS-Volumes laufen, können die nativen Snapshot-Funktionen nutzen, da der EBS-Speicher unabhängig von der Instanz bestehen bleibt. Knoten, die mit Instance-Storage arbeiten, benötigen jedoch stündliche und tägliche Backups auf externem Speicher wie S3, da die Daten des Instance-Storage dauerhaft und unwiderruflich verloren gehen, sobald eine Maschine angehalten oder neu gestartet wird.

3. Kubernetes/Hybrid-Einsätze

Kubernetes-basierte Cassandra-Implementierungen erfordern mehr als nur die Sicherung von SSTable-Daten. Sie hängen auch von Kubernetes Secrets, ConfigMaps und StatefulSet-Definitionen ab, die die Konfiguration und Identität des Clusters definieren. Ohne diese Definitionen haben die wiederhergestellten Daten keine gültige Umgebung, in der sie ausgeführt werden können.

4. Multi-Node Produktionscluster

In Produktionsclustern mit mehreren Knoten müssen Snapshots auf allen Knoten gleichzeitig ausgelöst werden, um einen konsistenten Wiederherstellungspunkt zu erzeugen. Bei einem gestaffelten Backup besteht die Gefahr, dass Lücken in den Daten entstehen, die eine saubere Wiederherstellung unmöglich machen.

5. Commit-Log-Archivierung

Die Commit-Log-Archivierung bewahrt das sequentielle Schreibprotokoll von Cassandra neben den regulären Snapshots auf und ermöglicht so eine Point-in-Time-Wiederherstellung. Für Einsätze, bei denen selbst kleine Datenverluste inakzeptabel sind, ist die Archivierung von Commit-Logs ein wesentlicher Bestandteil der Backup-Strategie.

Welches Recovery Time Objective (RTO) und Recovery Point Objective (RPO) sollten Sie bei der Sicherung und Wiederherstellung von Cassandra-Datenbanken berücksichtigen?

Das richtige RPO und RTO für eine Cassandra-Implementierung hängt vom Geschäftswert der Daten und der Komplexität des Clusters ab. Diese beiden Zahlen müssen festgelegt werden, bevor eine Sicherungsstrategie entworfen wird.

Auf der RPO-Seite gilt: Je kritischer Ihre Daten sind, desto enger muss Ihr Wiederherstellungspunkt sein. Der RPO definiert den akzeptablen Datenverlust und bestimmt die Häufigkeit der Datensicherung. Nehmen wir an, Sie haben eine Zahlungsverarbeitungsplattform, die Live-Transaktionen aufzeichnet, für die ein RPO von Minuten erforderlich sein könnte.

Was die RTO betrifft, so erfordert Cassandra ehrliche Erwartungen. Im Gegensatz zu einer Datenbank mit nur einem Server, bei der die Wiederherstellung nur wenige Minuten dauert, müssen bei einem verteilten Cassandra-Cluster Daten auf mehrere Knoten zurückkopiert, Dienste neu gestartet und Reparaturvorgänge zur Synchronisierung der Replikate durchgeführt werden.

Wie fügt sich die Cassandra-Sicherung in eine umfassendere Strategie zum Schutz von Unternehmensdaten ein?

Für kleine Unternehmen, die in ihren jeweiligen Branchen tätig sind, reicht es aus, nur die Cassandra-Backup-Strategie zu verwenden. Bei großen Unternehmen und Konzernen funktioniert das Cassandra-Backup jedoch nicht isoliert, sondern ist in ein breiteres Datensicherungskonzept integriert.

Warum reicht ein Backup auf Datenbankebene für die Ausfallsicherheit von Unternehmen nicht aus?

Im Gegensatz zu Startups und mittelgroßen Unternehmen verwalten Unternehmen eine riesige Datenmenge. In solchen Szenarien ist es für alle Teams schwierig, ihr eigenes Backup unabhängig zu verwalten, da

• Die Unternehmen verlieren den Überblick darüber, was sie tatsächlich schützen
• Größere Probleme oder Katastrophen, wie ein Ransomware-Angriff, der mehrere Systeme gleichzeitig betrifft

Enterprise Resilience ist mehr als nur ein Backup auf Datenbankebene. Auch wenn jedes Team für sich sein Bestes tut, braucht es ein universelles System, das alles verwaltet und unter Kontrolle hält, falls etwas passiert. Daher wird Cassandra in großen Unternehmen nicht separat betrieben, sondern neben anderen wichtigen Systemen, die unter einheitlichen Richtlinien geschützt werden müssen.

Wie lassen sich Cassandra-Backups in die Backup-Plattformen von Unternehmen integrieren?

Cassandra-Backups lassen sich über die dafür vorgesehenen Plugins in die Backup-Plattformen von Unternehmen integrieren, die später Teil des vereinheitlichten Bestandes des Unternehmens werden. Im Folgenden gehen wir auf die Funktionen und Möglichkeiten ein, die Cassandra nach der Integration in die Backup-Plattform des Unternehmens bietet.

• Automatische Snapshot-Verwaltung: Die Plattform plant den Snapshot-Befehl nodetool und führt ihn automatisch auf allen Knoten gleichzeitig aus.
• Knotenübergreifende Koordinierung: Das Cassandra-Backup-Plugin koordiniert alle Knoten des gesamten Clusters.
• Zentraler Speicherort: Die Dateien werden von den einzelnen Knoten an einen zentralen Speicherort übertragen.
• Keine manuelle Bereinigung: Die Plattform löscht automatisch alte Dateien, die nicht mehr gebraucht werden.
• Überwachen und warnen: Falls ein Problem auftritt, erkennt die Plattform dies und alarmiert das Team, was zu einer frühzeitigen Lösung führt.
• Wiederherstellungsprozess abwickeln: Wenn die Wiederherstellung erforderlich ist, verwaltet die Plattform alles von A bis Z.

Wie reduzieren zentralisierte Backup-Systeme das operative Risiko?

Der Einsatz eines zentralisierten Backup-Systems kann sich positiv auf die betriebliche Effizienz des Unternehmens auswirken. In der folgenden Tabelle sehen wir uns die typischen Risiken an, die einzelne Backups für Unternehmen mit sich bringen, und erfahren, wie ein zentrales Backup-System die operationellen Risiken erheblich reduzieren kann.

Welche Cassandra-Backup-Strategien gibt es?

Cassandra-Backup allein reicht nicht aus, um die Anforderungen von Unternehmen zu erfüllen. Es wird immer nur ein System auf einmal gesichert, während Unternehmen mehrere Systeme mit koordiniertem und konsistentem Schutz benötigen. Ein einzelnes Backup kann eine Unternehmensumgebung nicht isoliert schützen. Es braucht eine zentralisierte Datensicherungsstrategie, die alles unter einem Rahmenwerk vereint und konsistente Richtlinien, Überwachungs-, Warn- und Wiederherstellungsverfahren implementiert.

Was ist ein Cassandra Snapshot-Backup und wann sollten Sie es verwenden?

Cassandra-Snapshot-Backup erstellt eine zeitpunktgenaue Kopie aller SSTables, die mit dem Befehl nodetool snapshot ausgeführt wird. Es wird kein zusätzlicher Speicherplatz benötigt, sondern es werden harte Links für diesen bestimmten Zeitpunkt erstellt, die eingefroren werden und später verwendet werden können, um die Informationen wiederherzustellen, die Sie hatten, falls etwas schief geht oder Ihre Daten verloren gehen.

Vor risikoreichen Operationen sollte eine Cassandra-Snapshot-Sicherung durchgeführt werden. Zu solchen Szenarien gehören

• Groß angelegte Upgrades
• Schema-Änderungen
• Massenhafte Löschung von Daten

Wichtig: Es wird dringend empfohlen, Snapshots täglich oder gelegentlich zu erstellen. Sobald er erstellt ist, übertragen Sie ihn auf einen externen Speicher. Cassandra-Backup S3 ist die am häufigsten verwendete Methode. Sie können sie auf Amazon S3 übertragen, wodurch Ihre Snapshots geschützt werden und die Sicherheit aller Ihrer Daten gewährleistet ist.

Was ist der Unterschied zwischen vollständigen, inkrementellen und differenziellen Backups?

Cassandra bietet drei Hauptkategorien von Backups:

• Vollständige Sicherung
• Inkrementelle Sicherung
• Differenzielle Sicherung

1. Ein vollständiges Backup erfasst eine vollständige Kopie des gesamten Datensatzes (unabhängig davon, ob es Änderungen gegeben hat oder nicht). Sie ist zwar die einfachste Option, aber zeitaufwändig und wird daher nicht so häufig verwendet.
2. Bei der inkrementellen Sicherung wird nur das erfasst, was sich seit der letzten Sicherung geändert hat.
3. Bei der differenziellen Sicherung werden nur die seit der letzten vollständigen Sicherung neu hinzugekommenen und geänderten Daten erfasst.

HINWEIS: Cassandra unterstützt von Haus aus keine differenzielle Datensicherung.

Wie funktioniert das inkrementelle Backup von Cassandra und wann sollten Sie es aktivieren?

Bei der inkrementellen Sicherung von Cassandra werden nur neue SSTable-Dateien erfasst, wenn sie auf die Festplatte geschrieben werden, was sie speichereffizienter macht als vollständige Sicherungen. Inkrementelle Backups reduzieren den Speicherplatzbedarf, da nur neue Daten seit dem letzten Backup erfasst werden. Die Aktivierung dieser Funktion erfordert eine einzeilige Änderung in Cassandra.yaml

Sobald diese Funktion aktiviert ist, ist keine weitere manuelle Arbeit erforderlich: der Rest wird automatisch erledigt.

Schritt 1: Neue Daten werden empfangen

Neue Daten werden im Memtable empfangen, einem temporären Schreibpuffer im Arbeitsspeicher.

Schritt 2: Die Daten werden aus der Memtable auf die Festplatte übertragen

Sobald die Memtable voll ist und kein Speicherplatz mehr zur Verfügung steht, flusht Cassandra Ihre Daten als permanente SSTable-Datei.

Schritt 3: Harte Links werden erstellt

Sobald SStables erstellt werden, erstellt Cassandra automatisch Hard Links für diese Daten in den vorgesehenen Backups.

Schritt: 4: Backup-Agenten durchsuchen und übertragen

Backup-Tools wie Medusa, die in Cassandra integriert sind, überprüfen regelmäßig neue Dateien und übertragen sie auf den externen Speicher.

Schritt 5: Zyklus wiederholt sich

Dieser Prozess wird jedes Mal wiederholt, wenn neue Daten in den Cluster gelangen.

Cassandra inkrementelle Backups sollten aktiviert werden, wenn:

• Sich die Daten häufig ändern
• Ein großes Datenvolumen vorhanden ist
• Ihr RPO häufigere Wiederherstellungspunkte als 24 Stunden erfordert
• Tägliche vollständige Snapshots zu viel Speicherplatz beanspruchen oder zu lange dauern

Wie wirken sich Überlegungen zu Commit-Logs und Point-in-Time-Recovery auf die Sicherung und Wiederherstellung von Cassandra aus?

Die Archivierung von Commit-Logs ist eine wichtige Funktion in der Cassandra-Bereitstellungsarchitektur, wenn es um die Wiederherstellung der Datenbanken geht.

Bei der Durchführung der Cassandra-Sicherung gehen Sie wie folgt vor:

• Schreiben kommt an
• Commit Log (Festplatte) + Memtable (RAM)
• Memtable füllt sich → FLUSH
• SSTable (Festplatte)
• Commit Log-Segment gelöscht

Während dies unter normalen Betriebsbedingungen eine ideale Abfolge ist, ändert die Commit-Log-Archivierung dieses Muster. Anstatt Commit-Log-Segmente am Ende zu löschen, werden Kopien in einem externen Speicher abgelegt, was den Zugriff auf verlorene Daten ermöglicht. Regelmäßige Snapshots in Kombination mit Commit-Log-Archiven ermöglichen eine Point-in-Time-Recovery (PITR). Ohne die Archivierung des Commit-Logs ist die Wiederherstellung nur auf den letzten Snapshot beschränkt.

Um sich ein besseres Bild zu machen, lassen Sie uns das folgende Beispiel betrachten. Um 11 Uhr wurde ein Snapshot erstellt, und um 15:34 Uhr wurde er versehentlich gelöscht. Ohne die Archivierung des Commit-Logs könnten Sie nur bis 11:00 Uhr auf die Daten zugreifen, was Sie 4 Stunden und 34 Minuten Datenverlust kosten würde. Mit der Commit-Log-Archivierung können alle Ihre Daten ersetzt werden, was den Datenverlust verringert.

In solchen Szenarien, in denen der RPO gegen Null geht, ist die Archivierung von Commit-Protokollen keine Option, sondern ein Muss.

Was sind die Vor- und Nachteile von Backups auf Clusterebene gegenüber Backups auf Knotenebene?

Cassandra-Backups werden entweder auf Knotenebene oder auf Clusterebene durchgeführt, was jeweils unterschiedliche Vorteile mit sich bringt.

Sicherung auf Knotenebene: Sie ist im Vergleich zur Sicherung auf Clusterebene einfacher, da sie keine spezielle Orchestrierung erfordert und auf jedem Knoten unabhängig gesichert wird. Die unabhängige Sicherung von Knoten birgt jedoch das Risiko von Dateninkonsistenzen im gesamten Cluster, insbesondere bei Clustern mit mehr als 50 Knoten, da die Wiederherstellung schwierig sein kann und Probleme mit der Datenintegrität verursacht.

Backup auf Clusterebene: Im Gegensatz zur Sicherung auf Knotenebene ist sie wesentlich komplexer und erfordert eine spezielle Orchestrierung. Sie sichert alle Knoten innerhalb desselben Clusters gleichzeitig. Dadurch wird sichergestellt, dass die Datenintegrität nicht beeinträchtigt wird.

Welche Tools und Dienste unterstützen die Sicherung und Wiederherstellung von Cassandra?

Cassandra bietet eine breite Palette von Tools und Diensten für Backup und Wiederherstellung. Die Wahl des richtigen Tools ist genauso wichtig wie die Strategien selbst und hängt von mehreren Faktoren ab, darunter die Größe des Clusters und die Anforderungen an die Wiederherstellung. In diesem Abschnitt gehen wir ausführlich auf die wichtigsten Arten von Tools und Diensten ein, die die Sicherung und Wiederherstellung von Cassandra unterstützen, und erörtern die Vor- und Nachteile der einzelnen Tools und Dienste.

Was sind die Vor- und Nachteile von nativen Cassandra-Backup-Methoden?

Was sind die Vor- und Nachteile von nativen Cassandra-Backup-Methoden?

Native Cassandra-Backup-Methoden sind die Tools, die direkt in Cassandra integriert sind, so dass eine Integration von Drittanbieter-Software wie Medusa und Bacula nicht erforderlich ist. Die beiden wichtigsten Arten von nativen Cassandra-Backup-Methoden sind die folgenden:

1. Nodetool-Snapshot
2. Eingebautes inkrementelles Backup

Beide Optionen sind bei Cassandra weit verbreitet, und die von Ihnen gewählte Methode hängt stark von mehreren Faktoren ab. Native Cassandra-Backup-Methoden können aufgrund ihrer Praktikabilität eine ideale Option für kleine Bereitstellungen sein. Es fallen keine zusätzlichen Installations- oder Lizenzierungskosten an.

Allerdings haben auch sie ihre Grenzen. Sie konzentrieren sich stark auf die manuelle Arbeit, d.h. die Übertragung der Dateien auf ein externes System und die manuelle Bereinigung der alten Snapshots. Für große Installationen ist dies möglicherweise nicht die ideale Option, da es keine zentrale Überwachung, keine automatische Benachrichtigung bei Ausfällen und viele andere Funktionen gibt.

Vorteile:

• einfach zu verstehen
• ideal für kleine Implementierungen
• keine Installation erforderlich
• kostenlos und integriert

Nachteile:

• nicht für große Produktionen geeignet
• keine Überwachung oder Alarmierung
• keine Aufbewahrungsverwaltung
• keine Zeitplanung

Wie funktioniert Cassandra Backup S3 und wann sollten Sie es verwenden?

Cassandra-Backup S3 ist eine der am häufigsten verwendeten Backup-Lösungen, da sie eine ganze Reihe von Vorteilen bietet:

• Unbegrenzte Speicherkapazität
• Geografische Standortredundanz
• Zugriffskontrolle
• Automatische Lebenszyklus-Richtlinien

Um Ihnen dabei zu helfen, eine fundierte Entscheidung zu treffen und herauszufinden, ob es für Ihre Bedürfnisse geeignet ist, lassen Sie uns Schritt für Schritt erkunden, wie es funktioniert.

Schritt 1: Auf jedem einzelnen Knoten wird ein Snapshot ausgelöst, der SStable-Dateien erzeugt.

Schritt 2: Anschließend werden diese Dateien komprimiert, verschlüsselt und mit einem Backup-Tool eines Drittanbieters wie Medusa in den zugewiesenen S3-Bucket hochgeladen.

Schritt 3: Sobald sie in S3 sind, können die lokalen Snapshot-Dateien gelöscht werden.

Cassandra Backup S3 sollte verwendet werden, wenn Sie

• der Cluster in einer Cloud-Umgebung mit S3-Zugang läuft
• einen geografisch getrennten, kostengünstigen Backup-Speicher benötigen
• eine automatische Aufbewahrungsverwaltung durch S3-Lebenszyklusrichtlinien wünschen
• sie Tools von Drittanbietern verwenden, wie z.B. Bacula Enterprise, Medusa und OpsCenter, die sich nativ mit S3 integrieren

Wie sehen manuelle Snapshot-basierte Methoden im Vergleich zu automatisierten Cassandra-Backup-Tools aus?

In Bezug auf die Praktikabilität sind automatisierte Cassandra-Backup-Tools die bessere Option, insbesondere für Unternehmen. Im Folgenden werden wir sie separat diskutieren und vergleichen.

Manuelle Snapshot-Methode

Diese Methode beruht in hohem Maße auf manueller Arbeit, einschließlich der Ausführung Ihrer Nodetool-Snapshots, dem Schreiben eigener Skripte zur manuellen Übertragung von Dateien auf S3 SStable, der Einrichtung von Cron-Jobs und dem manuellen Löschen alter Snapshots, die nicht mehr benötigt werden. Manuelle Methoden sind für Unternehmen und Großkonzerne nicht sehr effizient, da sie von Menschen abhängig sind, keine Überwachung und Koordination bieten und das Fehlerrisiko erhöhen.

Automatisierte Cassandra-Backup-Tools werden automatisch über Tools von Drittanbietern integriert, darunter Medusa und Bacula Enterprise. Zu den typischen Funktionen gehören automatische Planung, Koordination, Übertragung, Komprimierung und Verschlüsselung, Aufbewahrungsmanagement, Überwachung und Alarmierung.

Wie können Snapshots auf Dateisystemebene sicher für Cassandra DB-Backups verwendet werden?

In einem typischen Szenario werden bei der Cassandra DB-Sicherung einfach Daten in der Cassandra-Datenbank erstellt und gespeichert. Ein Snapshot auf Dateisystemebene bietet einen alternativen Ansatz dazu und ermöglicht die Erfassung der gesamten Festplatte auf der Speicherebene. Er lässt sich mit Cassandra-Sicherungstools von Drittanbietern wie AWS EBS-Snapshots integrieren, um SSTable-Dateien, Commit-Logs und Konfigurationsdateien zu erfassen.

Diese Tools sind zwar recht schnell und umfassend und können auf der Speicherebene unabhängig voneinander arbeiten, können aber bei unsachgemäßer Verwendung ernsthafte Probleme verursachen. Wenn Cassandra mitten im Schreibvorgang ist und ein Dateisystem-Snapshot ausgelöst wird, während sich die Daten in der Memtable befinden, kann es schwierig werden, die betreffenden Daten eindeutig wiederherzustellen.

WICHTIGER HINWEIS: Um das Risiko eines solchen Szenarios zu minimieren, führen Sie das nodetool flush aus, bevor Sie den Dateisystem-Snapshot auslösen. Hier erfahren Sie, wie Sie das Risiko eines solchen Szenarios mindern können.

Gibt es Tools von Drittanbietern zur Sicherung und Wiederherstellung von Cassandra und welche Funktionen bieten sie?

Es gibt eine breite Palette von Tools für die Sicherung und Wiederherstellung von Cassandra, die sich ideal für die Anforderungen großer Produktionsumgebungen eignen. Zu den typischen Vorteilen solcher Tools gehören unter anderem

• Operative Effizienz
• Unterstützung von Cloud-Speicher
• Flexibilität bei der Sicherung
• Schnellere Notfallwiederherstellung

Führende Tools zur Sicherung und Wiederherstellung von Cassandra von Drittanbietern

• Bacula Enterprise

Bacula Enterprise hebt sich von allen anderen Backup-Lösungen ab, da es speziell für große und komplexe Umgebungen entwickelt wurde. Es ist das umfassendste Backup- und Wiederherstellungs-Tool auf Unternehmensniveau, das für Cassandra-Implementierungen verfügbar ist.

• OpsCenter

OpsCenter ist ein Cassandra-Backup-Tool eines Drittanbieters, das Teil der offiziellen Cluster-Management-Plattform von DataStax ist. Die Sicherung und Wiederherstellung ist nur eine Komponente der breiteren Plattform, die es abdeckt. Dieses Tool speichert Sicherungsdaten, um sicherzustellen, dass es keine doppelten Dateien gibt, und unterstützt sowohl lokalen Speicher als auch Amazon S3 als Sicherungsziele.

OpsCenter lässt sich direkt in das DataStax Enterprise-Ökosystem integrieren und bewältigt die zusätzliche Komplexität der Wiederherstellung dieser Workloads neben den normalen Cassandra-Daten. Die Funktion zum Klonen von Clustern ermöglicht die Wiederherstellung von Sicherungsdaten in einem anderen Cluster und unterstützt so Migrations- und Disaster Recovery-Workflows.

• Medusa

Medusa ist eines der am weitesten verbreiteten Open Source-Tools für Backup und Wiederherstellung, das speziell für Apache Cassandra entwickelt wurde. Zu den typischen Funktionen von Medusa gehören die Unterstützung von vollständigen und inkrementellen Backups, die automatische Verwaltung von Retentionen und die Integration mit verschiedenen Cloud-Speicherdiensten wie Amazon S3, Google Cloud Storage und Azure Blob Storage.

Medusa wurde für die verteilte Architektur von Cassandra entwickelt. Es versteht es, Backups über Knoten hinweg zu koordinieren, SSTable-Dateien zu verwalten und inkrementelle Backup-Ketten ohne benutzerdefinierte Skripte zu handhaben.

Wie kann Cassandra Backup mit Bacula Enterprise für den Schutz von Unternehmen integriert werden?

Cassandra-Backup-Tools können die Datenbank isoliert behandeln, was eine ideale Option für kleine Implementierungen ist. Bei Clustern mit mehr als 50 Knoten reicht Cassandra Backup allein nicht aus, da es an der Koordination und Transparenz einer vollständigen Infrastruktur mangelt. Bacula Enterprise integriert Cassandra Backup in eine umfassendere, unternehmensweite Datensicherungsstrategie.

Im Gegensatz zum Cassandra-Snapshot-Backup, bei dem jeder Knoten einzeln gesichert wird, können mit Bacula alle Knoten des Clusters auf einmal und im selben Moment koordiniert werden. Es verwaltet ein vollständiges Backup automatisch, ohne dass ein manuelles Eingreifen erforderlich ist. Dazu gehören das Auslösen der Snapshots, die Übertragung der SStables auf den entsprechenden zentralen Speicher, die Verwaltung der Backup-Ketten und die spätere Archivierung der Commit-Logs für eine Point-in-Time-Recovery (PITR).

Das macht Bacula Enterprise zu einer praktischen Option für Unternehmen, die neben anderen Systemen in ihrer Infrastruktur auch Cassandra zentral steuern müssen.

Wie führen Sie ein sicheres Backup für verschiedene Cassandra-Topologien durch?

Ein sicheres Backup von Cassandra erfordert mehr als das: Es erfordert eine sorgfältig geplante Ausführung, was oft übersehen wird. Die Beachtung der operativen Details ist ebenso wichtig wie die Tools und Strategien selbst, denn nur so kann die Datenkonsistenz durchgehend gewährleistet werden.

Wie sichern Sie einen Cassandra-Cluster mit mehreren Knoten, ohne die Verfügbarkeit zu beeinträchtigen?

Die Sicherung eines Cassandra-Clusters mit mehreren Knoten ohne Beeinträchtigung der Verfügbarkeit erfordert eine Staffelung der Sicherungsvorgänge über die Knoten hinweg, eine Planung außerhalb der Stoßzeiten und eine Drosselung der Ressourcennutzung. Die folgenden Vorgehensweisen gehen direkt auf jede dieser Anforderungen ein.

• Sichern Sie einen Knoten nach dem anderen

Cassandra repliziert Daten über mehrere Knoten hinweg, was die Verfügbarkeit beeinträchtigen kann. Um dieses Risiko zu minimieren, empfiehlt es sich, immer nur einen Cluster zu sichern, während die übrigen Knoten ihren täglichen Aufgaben nachgehen können, z.B. der Bearbeitung von Anfragen.

• Führen Sie Backups nur außerhalb der Stoßzeiten durch

Während der Spitzenzeiten, insbesondere an Wochentagen und während der Arbeitszeit, ist der Wettbewerb um Ressourcen relativ hoch. Die Durchführung von Backups am Wochenende löst dieses Problem, da die Konkurrenz um die Ressourcen gering ist oder gar nicht stattfindet.

• Backup-Vorgänge drosseln

Backup-Vorgänge und Live-Datenverkehr konkurrieren um dieselben Ressourcen. Tools wie Bacula Enterprise oder Medusa helfen dabei, Backup-Vorgänge zu drosseln. Dadurch wird sichergestellt, dass die Backup-Vorgänge nicht zu viele Ressourcen verbrauchen, was sich auf die Live-Performance auswirken wird.

Wie koordinieren Sie Cassandra-Snapshot-Backups über verteilte Knoten hinweg?

Die Koordinierung von Cassandra-Snapshot-Backups über verteilte Knoten hinweg ist einfach, solange alle Knoten des verteilten Clusters gleichzeitig erfasst werden.

Das gegenteilige Szenario kann zu ernsthaften Problemen führen. In einem verteilten Cluster hält jeder Knoten einen anderen Teil des gesamten Datenbestands. Selbst ein winziger Unterschied kann zu unterschiedlichen Zeitpunkten führen, was letztlich zu einem inkonsistenten Wiederherstellungspunkt führen kann, der sich nur schwer oder kaum eindeutig wiederherstellen lässt.

Effektive Tools oder Orchestrierungsskripte sollten vorhanden sein, um dies nativ zu handhaben. Die Integration von Cassandra mit Tools von Drittanbietern wie Bacula Enterprise ermöglicht es, alle Knoten gleichzeitig zu verbinden, dann zu warten, bis alle Snapshots abgeschlossen sind, und später die Dateien auf einen externen Speicher zu übertragen. Dieser Prozess sorgt für eine reibungslose Koordination der Cassandra-Snapshot-Backups über verteilte Knoten hinweg, ohne dabei Kompromisse einzugehen.

Wie stellen Sie sicher, dass Backups über Replikate und Rechenzentren hinweg konsistent bleiben?

Backups können über Replikate und Rechenzentren hinweg inkonsistent werden, wenn die Knoten zum Zeitpunkt des Snapshots leicht unterschiedliche Versionen der gleichen Daten enthalten. Zwei Schritte vor dem Backup und zwei Praktiken auf Backup-Ebene, die dieses Problem direkt angehen.

• Führen Sie nodetool repair aus

Wenn Sie ein nodetool repair ausführen, findet eine Synchronisierung der Replikate im gesamten Cluster statt und jeder Knoten verfügt über die neueste Version der gleichen Daten. Sobald dieser Prozess abgeschlossen ist, gibt es keine Inkonsistenz mehr, wenn der Snapshot beginnt.

• Deaktivieren Sie die Verdichtung

Führen Sie nodetool disableautocompaction aus, um zu verhindern, dass sich die Knoten in der Mitte der Verdichtung befinden, wenn der Snapshot ausgeführt wird, und um teilweise zusammengeführte SSTable-Dateien im Backup zu vermeiden.

Sobald diese Schritte erledigt sind, können Sie mit dem Backup-Prozess fortfahren. Im Folgenden erfahren Sie, was Sie tun können, um über verschiedene Rechenzentren hinweg konsistent zu bleiben.

• Verwenden Sie LOCAL_QUORUM-Konsistenz

Dadurch erhalten Sie nur vollständig bestätigte, aktuelle Daten aus dem lokalen Rechenzentrum, die bei der Datensicherung erfasst werden

• Sichern Sie nur von einem Rechenzentrum aus

Backups von mehreren Rechenzentren können aufgrund der Zeitverschiebung zu Inkonsistenzen führen. Die Sicherung von nur einem Rechenzentrum beseitigt Inkonsistenzen, da ein komplettes DC-Backup bereits den gesamten Datenbestand durch Replikation erfasst.

Was sind die Schritte zur Wiederherstellung von Cassandra aus Backups?

Die Sicherung von Cassandra ist nur die Hälfte des Prozesses: Es ist ebenso wichtig, sich mit Informationen darüber auszustatten, wie man Cassandra aus einer Sicherung wiederherstellen kann. Der Wiederherstellungsprozess kann in Abhängigkeit von mehreren Faktoren variieren, einschließlich des Umfangs und der während des Prozesses verwendeten Methoden.

Der folgende Abschnitt behandelt alle Wiederherstellungsszenarien, die Ihnen begegnen können.

Wie führen Sie ein sicheres Cassandra-Backup und eine sichere Wiederherstellung von Tabellen, Keyspaces oder kompletten Clustern durch?

Cassandra-Backups und -Wiederherstellungen können auf drei verschiedenen Ebenen durchgeführt werden, und jede dieser Ebenen kann zu einem anderen Ausmaß an Datenverlust führen. Lassen Sie uns diese nacheinander besprechen.

• Wiederherstellung auf Tabellenebene

Dies ist die einfachste Stufe der Wiederherstellung. Bei der Wiederherstellung auf Tabellenebene müssen Sie nicht alles wiederherstellen, sondern nur eine Tabelle, die versehentlich gelöscht oder gelöscht wurde. Der Vorgang ist ganz einfach: Kopieren Sie die angegebene Snapshot-Datei zurück in das richtige Verzeichnis und führen Sie nodetool refresh aus, um die Daten zu laden.

• Wiederherstellung auf Keyspace-Ebene

Die Wiederherstellung auf Keyspace-Ebene bezieht sich auf den Prozess der Wiederherstellung aller Tabellen, die sich im selben Keyspace befinden. Sie folgt demselben Prozess wie die Wiederherstellung auf Tabellenebene, gilt aber für alle Tabellen und wird durchgeführt, wenn der gesamte Keyspace gleichzeitig gelöscht oder beschädigt wird.

• Eine Wiederherstellung des gesamten Clusters

Diese Art der Wiederherstellung erstreckt sich auf den gesamten Cluster und ist daher die komplexeste und zeitaufwändigste. In der Regel wird eine Full-Cluster-Wiederherstellung nach größeren katastrophalen Ereignissen wie Ransomware durchgeführt. Bei der Wiederherstellung eines kompletten Clusters wird Cassandra auf jedem Knoten gestoppt, alle Datenverzeichnisse werden gesäubert, die Snapshot-Dateien werden wiederhergestellt und anschließend wird der Cluster neu gestartet.

Wie stellen Sie ein Cassandra-Snapshot-Backup wieder her und nehmen die Knoten wieder in Betrieb?

Die Wiederherstellung eines Cassandra-Knotens ist ein akribischer Prozess und erfordert die Einhaltung klar definierter Schritte. Lassen Sie uns im Folgenden den genauen Pfad der Schritte erkunden, die Sie zur Wiederherstellung Ihres Cassandra-Knotens durchlaufen müssen.

Schritt 1: Beenden Sie Cassandra

Sie müssen Cassandra stoppen, da Datendateien nicht ersetzt werden können, während Cassandra läuft.

Schritt 2: Löschen Sie das Datenverzeichnis

Löschen Sie alle beschädigten Dateien aus dem Datenverzeichnis, da es sich dabei um die Dateien handelt, die durch das Backup ersetzt werden.

Schritt 3: Kopieren der Snapshot-Dateien

Sobald das Datenverzeichnis von den gelöschten oder beschädigten Dateien bereinigt ist, können Sie die Snapshot-Dateien kopieren und in den korrekten Datenverzeichnispfad zurückbringen.

Schritt 4: Berechtigungen korrigieren

Sobald sich die korrekten Daten am richtigen Ort befinden, korrigieren Sie die Dateiberechtigungen und stellen Sie sicher, dass Cassandra Eigentümer der Datei ist, da sie sonst nicht in der Lage ist, die korrekte Version zu lesen.

Schritt 5 – Neustart von Cassandra

Der Knoten ist wieder online und liest die wiederhergestellten SSTable-Dateien.

Schritt 6 – Führen Sie nodetool repair aus. Dadurch wird der wiederhergestellte Knoten mit seinen Nachbarn synchronisiert, so dass er alle Schreibvorgänge empfängt, die auf anderen Knoten stattgefunden haben, während er offline war.

WICHTIGER HINWEIS: Wenn Sie einen kompletten Cluster wiederherstellen, müssen Sie diese Sequenz für alle Knoten wiederholen.

Wie verwenden Sie inkrementelle Cassandra-Backup-Daten bei der Wiederherstellung?

Die Wiederherstellung von inkrementellen Cassandra-Backups ist im Vergleich zur Wiederherstellung von Snapshot-Backups sehr viel komplexer. Wenn Sie eine Wiederherstellung mit einem inkrementellen Cassandra-Backup einleiten, müssen Sie zwei wichtige Dinge beachten.

• Die inkrementelle Sicherung sollte in chronologischer Reihenfolge durchgeführt werden.
• Es können keine Dateien in der Kette übersprungen werden.

Die Wiederherstellung eines inkrementellen Backups besteht aus zwei Hauptphasen, die wie folgt aussehen

1. Wiederherstellung der vollständigen Snapshot-Baseline: Es ist UNMÖGLICH, Ihre inkrementelle Sicherung wiederherzustellen, ohne die vollständige Snapshot-Sicherung wiederherzustellen, da diese als Grundlage dient.
2. Wenden Sie Ihre Inkremente in chronologischer Reihenfolge an: Jedes Inkrement wird auf der Baseline aufgebaut, vom ältesten bis zum neuesten. Wenn die Reihenfolge nicht eingehalten wird, kann das Backup nicht wiederhergestellt werden.

Lassen Sie uns ein Beispiel besprechen und sehen, wie es funktioniert

Nehmen wir an, Sie hatten am Dienstag einen vollständigen Snapshot und bis Samstag jeden Tag inkrementelle Sicherungen. Um Ihr inkrementelles Backup am Samstag wiederherzustellen, müssen Sie die Snapshots vom Dienstag anwenden, dann das inkrementelle Backup vom Mittwoch, Donnerstag, Freitag und Samstag in der gleichen chronologischen Reihenfolge.

Wie gehen Sie mit Versionsabweichungen zwischen Backup und Ziel-Cassandra-Version um?

Wie gehen Sie mit Versionsabweichungen zwischen Sicherungs- und Ziel-Cassandra-Versionen um?

Cassandra-Backups können sich von Zeit zu Zeit ändern. Wenn die Version, mit der die Sicherung erstellt wurde, und die Version, mit der sie wiederhergestellt wird, nicht übereinstimmen, kann keine saubere Wiederherstellung erfolgen. Je nach den Umständen gibt es zwei Lösungen, die Sie in Betracht ziehen sollten.

1. Führen Sie dieselbe Cassandra-Version aus, mit der die Sicherung erstellt wurde, und aktualisieren Sie sie dann auf die Zielversion. Dies ist die am häufigsten verwendete dieser beiden Optionen. Dies minimiert die Komplexität des gesamten Prozesses und beseitigt die Risiken der Formatkompatibilität.
2. Konvertieren Sie die alten Dateien, und stellen Sie sie dann in einer neuen Version wieder her. Wenn die erste Lösung nicht funktioniert, können Sie die Dateien der alten Version mit dem Tool sstableupgrade konvertieren und dann später auf die neue Version wiederherstellen.

Beide dieser Optionen sind praktikabel. Es kommt nicht darauf an, welche Sie wählen, sondern darauf, dass Versionsabweichungen richtig behandelt und die Daten korrekt wiederhergestellt werden.

Wie können Sie Cassandra-Backups zuverlässig automatisieren und planen?

Manuelle Backup-Prozesse, die für kleine Implementierungen ideal sind, haben immer noch ihre Nachteile. Sie sind anfällig für menschliche Fehler, vergessene Zeitpläne und Funktionen, die erst im Falle einer ernsten Katastrophe entdeckt werden. Automatisierung und Zeitplanung sind speziell darauf ausgerichtet, dieses Problem zu lösen: Sie stellen sicher, dass Fehler rechtzeitig behandelt werden, bevor sie zu schwerwiegenden Problemen werden, und erkennen Ausfälle frühzeitig, um die notwendigen Vorkehrungen zu treffen. Dieser Abschnitt behandelt umfassend alles, was Sie wissen müssen, um Ihre Cassandra-Backups zuverlässig zu automatisieren und zu planen.

Welche Zeitplanungsmuster minimieren die Last und erfüllen Ihre RTO/RPO?

Bei der Wahl des richtigen Sicherungsplans müssen Sie zwei Anforderungen berücksichtigen

• Erfüllung der RPO/RTO-Anforderungen
• Minimierung der Belastung Ihres Clusters

Es gibt zwei Hauptmuster für die Backup-Planung, die Sie in Betracht ziehen sollten

• Tägliche vollständige Snapshots + stündliche inkrementelle Backups

Führen Sie einmal am Tag einen vollständigen Snapshot und stündlich inkrementelle Sicherungen durch, um die im Laufe des Tages auftretenden Änderungen zu erfassen. Mit dieser Kombination können Sie Ihr einstündiges RPO einhalten, ohne wiederholt vollständige Snapshots auszuführen.

WICHTIGER HINWEIS: Planen Sie Ihre vollständigen Snapshots außerhalb der Hauptverkehrszeiten, um die Konkurrenz zum Live-Datenverkehr zu minimieren.

• Wöchentliche vollständige Snapshots + tägliche inkrementelle Snapshots

Während bei den meisten Einsätzen tägliche Full-Snapshots das 24-Stunden-RPO erfüllen, ist dies bei Clustern mit mehr als 50 Knoten nicht der Fall, da sie zeitaufwändig sind. In solchen Szenarien kann die Planung wöchentlicher Full-Snapshots in Kombination mit täglichen Inkrementen eine bessere Option sein, mit der Sie den Overhead reduzieren und ein 24-Stunden-RPO einhalten können.

Lassen Sie uns im Folgenden die am häufigsten verwendeten RPO-Anforderungen und die dafür empfohlenen Muster erörtern.

Wie können Skripte, Orchestrierungs-Tools oder Cron-Jobs widerstandsfähig und idempotent gemacht werden?

Backup-Skripte sind in vielerlei Hinsicht unzureichend, und es ist wichtig, dies rechtzeitig zu beheben. Die ultimative Lösung ist der Aufbau von Resilienz und Idempotenz, um sicherzustellen, dass jeder Backup-Prozess sorgfältig durchgeführt wird.

Hier sind die konkreten Schritte, die Sie befolgen sollten, um Ihre Backup-Automatisierung widerstandsfähig und idempotent zu machen.

Schritt 1: Führen Sie vor der Ausführung einen Pre-Check durch

Bevor Sie überhaupt versuchen, einen neuen Snapshot zu erstellen, überprüfen Sie und stellen Sie sicher, dass kein anderer Snapshot für dasselbe Fenster existiert

Schritt 2: Verwenden Sie Sperrdateien

Sobald Sie Ihre Backup-Automatisierung starten, erstellen Sie eine Sperrdatei und löschen Sie diese später. Dieser Schritt stellt sicher, dass keine zwei Sicherungsdateien gleichzeitig ausgeführt werden.

Schritt 3: Überprüfen Sie jeden Schritt

Überprüfen Sie jedes einzelne Detail und den Exit-Code jedes Befehls, einschließlich Snapshots, Komprimierung und Uploads. So können Sie Fehler während des gesamten Prozesses identifizieren und alles unter Kontrolle halten.

Schritt 4: Protokollieren Sie alles

Schreiben Sie alle Aktivitäten, einschließlich der Erfolge, Misserfolge und Warnungen, in eine Protokolldatei, die Ihnen hilft, sicherzustellen, dass die Skripte belastbar sind.

Schritt 5: Bereinigen Sie bei Misserfolg

Bereinigen Sie automatisch partielle Snapshots oder unvollständige Uploads, falls Ihr Backup-Skript auf halbem Weg scheitert.

Schritt 6: Wiederholungslogik hinzufügen

Wiederholen Sie vorübergehende Ausfälle automatisch bis zu einer bestimmten Grenze.

Schritt 7: Nutzen Sie die Orchestrierungs-Tools

Verwenden Sie anstelle von Cron-Jobs Orchestrierungstools wie Bacula Enterprise, mit denen Sie den gesamten Backup-Lebenszyklus steuern können.

Wie überwachen Sie Backup-Aufträge und warnen Sie bei Fehlern?

Während Ihres Cassandra-Backup-Prozesses kann es jederzeit zu Fehlern kommen. Die Überwachung von Backup-Aufträgen und die Alarmierung bei Ausfällen sind zwei wichtige Bestandteile, die Sie bei Ausfällen berücksichtigen sollten.

Wenn Sie mit der Überwachung Ihres Backups beginnen, sollten Sie die folgenden Fragen beachten, damit sie effektiv ist.

• Wurde Ihr Backup ausgeführt?
• Wurde es erfolgreich abgeschlossen?
• Wie lange hat die Ausführung gedauert?
• Wie groß war die Ausgabe?
• Ist es möglich, das Backup wiederherzustellen?

Um Ihre Sicherungsaufträge zu überwachen, sollten Sie Folgendes beachten:

1. Prüfen Sie die Cassandra-Protokolle

Scannen Sie system.log nach jedem Sicherungsauftrag auf Fehler oder Warnungen, die darauf hinweisen, dass etwas nicht sauber abgeschlossen wurde.

2. Verwenden Sie nodetool, um Ihre Snapshots zu überprüfen

Führen Sie nodetool listsnapshots aus, um sicherzustellen, dass Ihr Snapshot tatsächlich existiert.

3. Verfolgen Sie die Jobausgaben

Stellen Sie sicher, dass Sie den Exit-Code, die Dateigröße und die Dauer Ihres Backup-Skripts protokollieren, um es später mit früheren Versionen vergleichen zu können.

Bei der Durchführung Ihres Cassandra-Backups ist die Alarmierung ebenso wichtig wie die Überwachung, die Ihnen hilft, rechtzeitig die notwendigen Vorkehrungen zu treffen. Je nach Schwere des Problems sollten Fehlermeldungen über den dafür vorgesehenen Kanal erfolgen.

• PagerDuty für eine sofortige Reaktion auf den Bereitschaftsdienst
• Slack für die Sichtbarkeit des Teams
• E-Mail für nicht dringende Benachrichtigungen

Sie können auch Tools von Drittanbietern wie Bacula Enterprise einsetzen, das eine einheitliche Sicherung und Überwachung sowie Warnmeldungen bietet, um sicherzustellen, dass alles unter Kontrolle ist.

Wie wirken sich Sicherheit und Compliance auf Cassandra-Backup-Praktiken aus?

Der Einsatz der richtigen Cassandra-Backup-Strategie ist wichtig, aber das ist nur die eine Seite der Medaille. Sicherheit und Compliance sind die zweite Hälfte der Gleichung. Die Sicherheit sorgt dafür, dass die Dateien vor unbefugtem Zugriff oder Einschränkungen geschützt sind. Die Konformität wiederum sorgt dafür, dass die Backup-Praktiken allen gesetzlichen Anforderungen entsprechen.

Wie sollten Cassandra-Backups im Ruhezustand und während der Übertragung verschlüsselt werden?

Cassandra-Backups müssen sowohl im Ruhezustand als auch bei der Übertragung verschlüsselt werden. Dabei handelt es sich um zwei unterschiedliche Schutzanforderungen, die verschiedene Schwachstellen abdecken.

Bei der Verschlüsselung im Ruhezustand werden Ihre Sicherungsdateien in verschlüsselter Form auf der Festplatte oder dem Sicherungsspeicher gespeichert. Sie stellt sicher, dass die Dateien geschützt sind und nicht gelesen werden können, selbst wenn der physische Speicher gestohlen wird.

Die Verschlüsselung während der Übertragung bezieht sich hingegen auf den Prozess der Übertragung Ihres Backups vom Cassandra-Knoten zum Backup-Speicher. Dieser Prozess verhindert das Abfangen während der Übertragung, was den Schutz wichtiger Daten gewährleistet.

Im Folgenden erfahren Sie, was Unternehmen und Betriebe tun sollten, um Cassandra-Backups richtig zu sichern.

• Verwenden Sie starke Verschlüsselungsstandards wie AES-256 für die Verschlüsselung im Ruhezustand
• Sichere Protokolle wie HTTPS für die Verschlüsselung bei der Übertragung
• Speichern und verwalten Sie Verschlüsselungsschlüssel mit dem Key Management Service (KMS)
• Beschränken Sie den Zugriff auf Backup-Dateien

Wie kontrollieren Sie den Zugriff auf Backups und setzen das Prinzip der geringsten Berechtigung durch?

Die Kontrolle des Zugriffs auf alles und jeden ist eine der am wenigsten genutzten Praktiken bei Cassandra-Backups. Das bedeutet, dass Sie jedem System und jeder Person die für seine/ihre Rolle erforderliche Mindestberechtigung erteilen müssen. Zu den typischen Dienstkonten oder Rollen gehören:

1. Backup-Agenten, die nur Schreibzugriff auf den Backup-Speicher haben, aber keine bestehenden Backups lesen oder löschen können
2. Wiederherstellungsagenten, die nur Lesezugriff haben und nichts löschen oder ändern können
3. Backup-Administrator, der vollen Zugriff auf alles hat.

Viele Unternehmen implementieren IAM- (Identity and Access Management) und S3-Bucket-Richtlinien, um den Zugriff auf Backups zu kontrollieren und die geringsten Rechte durchzusetzen. Zu diesen Richtlinien gehören u.a. die Verweigerung von Operationen für Nicht-Administrator-Konten, die Beschränkung des Zugriffs auf einen unbekannten IP-Bereich, die Forderung nach Verschlüsselung aller Uploads und die Überprüfung von Protokollierungsaufzeichnungen.

Durch die Aufteilung dieser Aufgaben auf verschiedene Systeme und Personen und die Festlegung, wer was wann tun darf, wird sichergestellt, dass alles unter Kontrolle ist und nichts gefährdet wird.

Wie wirken sich Aufbewahrungsrichtlinien und Anforderungen an die Datenlöschung auf die Cassandra-Backup-Strategie aus?

Aufbewahrungsrichtlinien und Anforderungen an die Datenlöschung sind zwei unterschiedliche Herausforderungen, die sich auf die Cassandra-Backup-Strategie auswirken. Aufbewahrungsrichtlinien sind die Richtlinien, die festlegen, wie lange Cassandra-Backups aufbewahrt werden, bevor sie gelöscht werden, wenn sie nicht mehr verwendet werden.

• Tägliche Backups – Aufbewahrung für 30 Tage
• Wöchentliche Sicherungen – Aufbewahrung für 3 Monate
• Monatliche Sicherungen – Ein Jahr lang aufbewahrt
• Jährliche Backups – Aufbewahrung für 7 Jahre

Um dieses Problem zu lösen, implementieren Unternehmen einen abgestuften Aufbewahrungsansatz, d.h. sie wenden unterschiedliche Aufbewahrungszeiträume auf verschiedene Backup-Typen gleichzeitig an. Dies stellt sicher, dass Unternehmen und Betriebe ihre Speicherkosten und die Einhaltung gesetzlicher Vorschriften in Einklang bringen können, ohne alles für immer aufzubewahren.

Die Anforderungen an die Datenlöschung stellen eine weitere Herausforderung dar, da es nicht möglich ist, die Daten bestimmter Benutzer aus binären Sicherungsdateien zu löschen. Um dieses Problem zu lösen, halten Unternehmen die Aufbewahrungsfrist so kurz, dass gelöschte Daten innerhalb eines dokumentierten und vertretbaren Zeitrahmens natürlich verfallen.

Was bedeuten unveränderliche Backups und Schutz vor Ransomware für die Sicherung und Wiederherstellung von Cassandra?

Ransomware ist der größte und katastrophalste Fehler, der während des Cassandra-Backup-Prozesses auftritt. Im Falle eines solchen Angriffs folgt Ransomware einem vorhersehbaren Muster, das wie folgt aussieht:

• Verschlüsselung der Live-Daten
• Angriff auf die Backup-Datei, um eine Wiederherstellung zu verhindern

Unveränderliche Backups sprechen dieses Problem direkt an. Es stellt sicher, dass Backup-Dateien nicht verändert werden können, nachdem sie geschrieben wurden, und selbst ein vollständig kompromittiertes Administratorkonto kann ein unveränderbares Backup nicht löschen oder verschlüsseln.

S3 Object Lock implementiert die Unveränderbarkeit auf der AWS-Speicherebene:

• Dateien, die in einen gesperrten Bucket geschrieben werden, können während der definierten Aufbewahrungsfrist weder geändert noch gelöscht werden.
• Der Compliance-Modus hebt alle Überschreibungsmöglichkeiten auf.
• Der Governance-Modus erlaubt es autorisierten Administratoren, die Sperre unter bestimmten Bedingungen aufzuheben.

Wie können Air-Gapped- oder Offline-Backups die Auswirkungen von Sicherheitsverletzungen reduzieren?

In den meisten Szenarien geht es bei Ransomware-Angriffen um mehr als nur die Verschlüsselung von Live-Daten: Sie suchen ständig nach Möglichkeiten, Online-Backups zu zerstören und die Chancen auf Wiederherstellungsoptionen zu minimieren. Der beste Schutzmechanismus, den Ransomware-Angriffe nicht überwinden können, sind Air-Gapped- und Offline-Backups.

Air-Gapped-Backups sind physisch vollständig von allen Netzwerken getrennt. Das bedeutet, dass Air-Gapped-Datensicherungen nicht erreicht, gelöscht oder verschlüsselt werden können, da es keine Internetverbindung und keinen Fernzugriff gibt.

Offline-Backups sind breiter angelegt und zum Zeitpunkt eines Sicherheitsverstoßes nicht aktiv mit aktiven Systemen verbunden. Sie können aber dennoch über andere Wege erreichbar sein.

Was sind die besten Praktiken für produktive Cassandra-Backups?

Eine produktive Cassandra-Backup-Strategie scheint ein unendlicher Weg zu sein, der konsistente Richtlinien, laufende Messungen und eine klare Dokumentation erfordert, um auf Dauer zuverlässig zu sein. Der folgende Abschnitt befasst sich mit den Best Practices für Cassandra-Backups in der Produktion, definiert die Baseline und erörtert alles, was Sie wissen müssen.

Welche Mindestrichtlinien sollte jeder Produktionseinsatz haben?

Unabhängig von der Größe des Unternehmens, des Budgets oder der Komplexität des Clusters sollte jede Cassandra-Produktionsumgebung über die folgenden Mindestanforderungen verfügen:

1. Automatisierte tägliche Snapshots. Durch die Automatisierung wird die menschliche Abhängigkeit von der kritischsten Datensicherungsoperation beseitigt.
2. Offsite-Speicherung. Jeder Snapshot muss sofort auf einen externen, vom Cluster völlig getrennten Speicher übertragen werden.
3. Definierte Aufbewahrungsrichtlinien. Sie sollten dokumentieren, wie lange jeder Backup-Typ aufbewahrt und automatisch durchgesetzt wird.
4. Überwachung und Alarmierung. Automatisierte Überwachung und Alarmierung sind ein Muss, damit Sie rechtzeitig die notwendigen Vorkehrungen treffen und größere Ausfälle verhindern können.
5. Getesteter Wiederherstellungsprozess. Backups müssen regelmäßig getestet werden, um die Sicherheit Ihrer Daten zu gewährleisten.
6. Verschlüsselung. Alle Ihre Backup-Dateien müssen im Ruhezustand und während der Übertragung ausnahmslos verschlüsselt sein.
7. Zugriffskontrolle. Das Prinzip der geringsten Berechtigung muss für alle Ihre Sicherungsspeicher gelten.
8. Dokumentation der Version. Jedes Backup muss mit der Cassandra-Version gekennzeichnet sein, mit der es erstellt wurde.
9. Dokumentiertes Runbook. Sie sollten über ein dokumentiertes Runbook mit detaillierten Wiederherstellungsprozeduren verfügen, das im Falle einer größeren Katastrophe verwendet werden kann.
10. Inkrementelle Backups. Sie sollten inkrementelle Backups in Kombination mit vollständigen Snapshot-Backups verwenden, die einen RPO von unter 24 Stunden haben.

Wie dokumentieren Sie Cassandra-Sicherungs- und Wiederherstellungsprozeduren für Bereitschaftsteams?

Um die Verfahren zur Sicherung und Wiederherstellung von Cassandra für das Bereitschaftsteam zu dokumentieren, verfügen Unternehmen über ein Runbook, ein Dokument, das als Schritt-für-Schritt-Anleitung dient. Ein ideales Runbook sollte so geschrieben sein, dass selbst ein Junior-Spezialist, der noch nie ein Cassandra-Backup durchgeführt hat, es lesen und alles erfolgreich ausführen kann. Hier ist, was ein solches Runbook abdecken sollte:

• Wiederherstellung einzelner Tabellen
• Wiederherstellung von Schlüsselbereichen
• Wiederherstellung eines kompletten Clusters
• Erwartungen an den Zeitplan für jeden erforderlichen Schritt
• Kontaktdaten von Cassandra-Experten und Support für Backup-Tools

WICHTIGER HINWEIS: Es sollte eine Anleitung geben, damit auch Unkundige verstehen, welches dieser Verfahren auf die jeweilige Situation zutrifft.

Diese Runbooks erfüllen eine äußerst wichtige Funktion für Unternehmen und Betriebe. Sie sollten nach jedem Upgrade, jeder Wiederherstellung oder bei jeder Änderung von Backup-Tools aktualisiert werden.

Welche Metriken und SLAs sollten für den Zustand des Backups verfolgt werden?

Die Überwachung des Zustands von Backups erfordert die Überwachung spezifischer Metriken und die Messung, wie gut sie funktionieren und ob die Leistung nachlässt.

Wichtige Metriken, die Sie für den Zustand Ihres Backups berücksichtigen sollten:

1. Erfolgsquote. Diese Kennzahl gibt den Prozentsatz der Aufträge an, die innerhalb des festgelegten Zeitraums erfolgreich waren.
2. Dauer. Diese Kennzahl gibt an, wie lange jeder Auftrag dauern kann. Legen Sie zum Beispiel fest, dass ein vollständiger Snapshot innerhalb einer Woche erfolgen soll.
3. Größe. Untersuchen Sie unerwartete Rückgänge oder Spitzen, die auf Anomalien hinweisen.
4. Zeit bis zur Wiederherstellung. Diese Kennzahl wird durch regelmäßige Wiederherstellungstests gemessen und bestätigt, dass die tatsächliche RTO in der Praxis erreicht werden kann.
5. Alter der Sicherung. Ermitteln Sie, wie alt das letzte erfolgreiche Backup gerade ist.
6. Reaktionszeit bei Alarmen – wie schnell werden Ausfälle erkannt und darauf reagiert. SLA: alle Backup-Warnungen werden innerhalb von 15 Minuten bestätigt.

Um diese Metriken zu überwachen und den Zustand Ihres Backups zu ermitteln, können Sie Tools von Drittanbietern wie Bacula Enterprise, Medusa oder OpsCenter verwenden, die eine einheitliche Plattform bieten, mit der Sie all diese Aufgaben auf einmal erledigen können.

Das Wichtigste in Kürze

• Definieren Sie Ihre RPO und RTO, bevor Sie Ihre Strategie entwerfen, denn ohne sie hat Ihre Backup-Strategie kein messbares Ziel.
• Speichern Sie Ihre Snapshots immer außerhalb des Unternehmens, sobald sie erstellt wurden.
• Führen Sie inkrementelle Backups durch und legen Sie die Archivierung von Protokollen fest, da dies den Speicher-Overhead reduziert.
• Automatisierung, Überwachung und Alarmierung sind ein Muss, da sie die Wahrscheinlichkeit von Fehlern und Ausfällen verringern.
• Sorgen Sie immer für Verschlüsselung, Zugriffskontrolle, unveränderlichen Speicher und Air-Gapped-Backups. Verschlüsselung und Zugriffskontrolle verhindern unbefugten Zugriff. Unveränderbare und Air-Gapped-Backups stellen sicher, dass Ransomware Ihren Wiederherstellungspfad nicht zerstören kann.
• Testen Sie Ihre Backups als regelmäßige Wiederherstellungsübungen zur Bestätigung Ihres Wiederherstellungsplans.

Häufig gestellte Fragen

Können Cassandra-Backups über verteilte Anwendungsarchitekturen hinweg konsistent bleiben?

Ja, Cassandra-Backups können über verteilte Anwendungskanäle hinweg konsistent bleiben. Dies wird jedoch durch koordinierte Snapshots und die Archivierung von Commit-Protokollen erreicht, die zuverlässige und wiederherstellbare Backups erzeugen.

Wie können Sie Cassandra-Bereitstellungen mit mehreren Mandanten sicher sichern?

Die sichere Sicherung von mandantenfähigen Cassandra-Installationen erfordert Snapshots auf Keyspace-Ebene, um die Daten der Mandanten zu isolieren. Stellen Sie sicher, dass Sie strenge Zugriffskontrollen und Verschlüsselung während der Backup-Speicherung durchsetzen, um eine mandantenübergreifende Datenexposition zu verhindern.

Wie verändern containerisierte und Kubernetes-basierte Cassandra-Implementierungen die Backup-Strategie?

Containerisierte Cassandra-Implementierungen erfordern persistente Volume-Snapshots, anstatt sich ausschließlich auf nodetool snapshot zu verlassen. In Kubernetes können Sie Tools wie Medusa für die Orchestrierung von Backups über Pods hinweg verwenden.