Cassandra-Datenbanken sichern

Moderne Daten sind zunehmend umfangreich und unstrukturiert, sodass sie nur schwer in herkömmlichen relationalen Datenbanken mit einer festen Tabellenstruktur gespeichert werden können. Da Unternehmen immer mehr Anwendungen und Daten in die Cloud migrieren, investieren sie auch in die Entwicklung moderner, Cloud-nativer Anwendungen, die schnell bereitgestellt werden müssen. Diese modernen Anwendungen benötigen einen Datenspeicher, der agil, flexibel und leistungsfähig ist. Hier kommen nicht-relationale NoSQL-Datenbanken („Not only SQL“) wie Apache Cassandra ins Spiel.

Eine Cassandra-Datenbank ist für große Datensätze ausgelegt und eignet sich besonders für Unternehmensanwendungen wie das Internet der Dinge (IoT) und Personalisierung. Cassandra verwendet Daten in Spaltenfamilien, die mit Tabellen in relationalen Datenbanken vergleichbar sind. Die Familien enthalten Spalten und Zeilen, und jede Zeile hat einen eindeutigen Schlüssel. Spalten können im laufenden Betrieb hinzugefügt werden und der Zugriff erfolgt über die Cassandra Query Language (CQL), die in ihrer Syntax SQL ähnelt. Da Cassandra nicht-relational ist, werden Daten anders gespeichert und abgerufen als in relationalen Datenbanken.

Ebenso erfordern NoSQL-Datenbanken eine andere Datenschutz- und Backup-Lösung. Herkömmliche Backup-Methoden erfüllen die Anforderungen strukturierter Anwendungen auf relationalen Datenbanken, die einen gemeinsamen Speicher verwenden. Sie werden den Anforderungen moderner Anwendungen, die auf verteilten NoSQL-Datenbanken wie Cassandra basieren, nicht gerecht.

Idealerweise benötigen Unternehmen, die NoSQL-basierte Anwendungen einsetzen, sowohl Backup als auch Replikation, um ihre Daten erfolgreich zu schützen.

Backup-Anforderungen für Cassandra-Datenbanken

Es gibt zwar native Backup-Tools, aber sie gehen nicht vollständig auf die architektonischen Feinheiten von Cassandra ein. Im Folgenden sind einige der wichtigsten Anforderungen an Backup und Wiederherstellung von Cassandra aufgeführt.

Anforderung Nr. 1 – Zeitpunktgenaues Backup. Native Datenbank-Backup-Tools erstellen knotenweise Snapshots, die im Wesentlichen lokale Snapshot-Backups sind. Diese Methode ist jedoch fehleranfällig und nicht skalierbar. Außerdem bietet sie nicht das zeitpunktgenaue Backup, das Sie zur Wiederherstellung nach einem Datenverlust benötigen.

Anforderung Nr. 2 – Wiederherstellung auf jeden beliebigen Zeitpunkt. Unternehmen müssen ihre Test-/Entwicklungscluster häufig mit den neuesten Schutzdaten aktualisieren, um kontinuierliche Integration (CI) und kontinuierliche Entwicklung (CD) zu ermöglichen. Test-/Entwicklungscluster haben eine andere Topologie mit einer anderen Anzahl von Knoten als Produktionsdatenbankcluster. Die Aktualisierung jedes Clusters mit nativen Lösungen dauert Stunden oder Tage und beeinträchtigt die Produktivität von Entwicklern.

Anforderung Nr. 3 – Datenmaskierung. Bei nativen Tools können nicht bestimmte Spalten bei der Wiederherstellung vertraulicher Daten ausgeblendet werden. Dieses Defizit kann negative Auswirkungen auf Unternehmen haben, die mit sensiblen Daten, wie z. B. persönlich identifizierbaren Informationen, arbeiten.

Anforderung Nr. 4 – Umgang mit Knotenausfällen während Backup und Wiederherstellung. Wenn bei einer nativen Lösung ein Quellknoten während des Backups ausfällt, werden die Backups für diesen Knoten angehalten, was zu Datenverlusten oder Inkonsistenzen in einem gesicherten Datensatz führen kann. Ihre Datenbank-Backup-Lösung muss optimal funktionieren, wenn Knotenausfälle auftreten.

Anforderung Nr. 5 – TTL-Unterstützung (Time to live). Es gibt keine Möglichkeit, TTL während der Wiederherstellung mit einer nativen Backup-Lösung anzupassen. Wenn TTL während der Wiederherstellung bereits abgelaufen ist, lässt Cassandra die wiederhergestellten Daten automatisch verfallen.

Anforderung Nr. 6 – Datenschutz auf granularer Ebene. Native Lösungen führen meist nur Backups auf Schlüsselbereichsebene durch, ohne die Möglichkeit, Backups auf Spaltenfamilienebene durchzuführen. So werden alle Spaltenfamilien in einem Schlüsselbereich mit der gleichen Backup-Häufigkeit und Aufbewahrungsrichtlinie gesichert. Auch Spaltenfamilien, die nicht benötigt werden, sich aber im selben Schlüsselbereich befinden, werden gesichert.

Anforderung Nr. 7 – Effiziente Speicherung von Datenbank-Backups. Native Backup-Lösungen können Ihre Speicherkosten erhöhen. So werden beispielsweise alle Replikate in einem Backup-Speicher aufbewahrt; diese Backups werden sowohl in Cassandra-Knoten als auch in einem optionalen Sekundärspeicher gespeichert. Außerdem werden neu erzeugte, komprimierte SSTables (unveränderliche Datendateien, die Cassandra für die Persistenz von Daten auf der Festplatte verwendet) zusätzlich zu der SSTable gesichert, aus der die neuen SSTables stammen. All diese Aktivitäten führen zu erhöhten Kosten für die Speicherung von Datenbank-Backups.

Rubrik Mosaic für NoSQL-Datenbank-Backup

Rubrik Mosaic ist eine Software, die speziell entwickelt wurde, um die Herausforderungen bei Backup und Wiederherstellung von modernen NoSQL-Datenbanken und Big-Data-Dateisystemen zu lösen. Rubrik Mosaic geht die hier genannten Apache Cassandra-Backup-Anforderungen zusammen mit anderen wichtigen Anforderungen an. 

Rubrik Mosaic:

• liefert zeitpunktgenaue Backups in benutzerdefinierten Intervallen.

• streamt Daten parallel an sekundären Backup-Speicher. Backups sind clusterkonsistent über jede Cassandra-Clustergröße hinweg.

• nutzt die patentierte semantische Deduplizierungstechnologie, um die Kosten für die lokale Speicherung und die Cloud-Speicherung um bis zu 70 % zu senken.

• automatisiert die Test/Entwicklungs-Aktualisierung mit einer Granularität auf Spaltenfamilienebene und Cloud-übergreifender Mobilität. Die Any-to-Any-Topologie-Wiederherstellung stellt Daten in Clustern bereit, die aus völlig andersartigen Clustern stammen.

• stellt erweiterte Unterstützung für TTL bereit.

Erfahren Sie mehr darüber, wie Rubrik Ihre Cassandra-Daten schützen kann. Und lesen Sie auch unser Whitepaper: Definitive Guide to Backup and Recovery for Cassandra.