Backups für NoSQL-Systeme (MongoDB, Cassandra): Konsistenzpunkte, Incrementals und Wiederherstellung

NoSQL-Datenbanken werden im Betrieb oft als „einfach zu skalieren“ wahrgenommen – beim Backup kommt dann die Ernüchterung. „Ein Dump reicht“ funktioniert bei verteilten Systemen nur selten, und selbst ein erfolgreicher Sicherungslauf sagt wenig darüber aus, ob sich daraus ein konsistenter Zustand wiederherstellen lässt. Genau hier setzt dieser Beitrag an: Backups für NoSQL-Systeme (am Beispiel MongoDB und Cassandra) brauchen bewusst geplante Konsistenzpunkte (definierte, zusammenhängende Datenstände), eine belastbare Inkremental-Strategie und vor allem einen Restore-Prozess, der unter Zeitdruck reproduzierbar bleibt.

Der Fokus liegt auf dem, was Admins und Operatoren im Alltag wirklich brauchen: Voraussetzungen, typische Stolperfallen, Prüfschritte, Umsetzung, Troubleshooting und eine Rückfallstrategie. Wo Kommandos sinnvoll sind, gibt es kopierbare Blöcke – ohne sich in Tool-Marketing oder Framework-Interna zu verlieren.

Backups für NoSQL-Systeme in der Praxis

Viele NoSQL-Systeme sind verteilt (mehrere Knoten/Nodes), nutzen Replikation (Daten werden redundant gespeichert) und erlauben eventual consistency (zeitverzögerte Angleichung). Das ist gut für Verfügbarkeit – schlecht für naive Backup-Methoden.

Typische Fehlerbilder aus dem Betrieb:

• „Backup ist durchgelaufen, Restore ist kaputt“: Daten waren beim Sichern nicht konsistent (z. B. Snapshot ohne sauberen Checkpoint oder ohne passende Transaktions-/Log-Position).
• Clusterweiter Zustand fehlt: Nur Datenfiles gesichert, aber keine Metadaten/Cluster-Konfiguration (Replikaset-Config, Keyfiles, TLS-Keys, Schema/Indices, Token/Topology-Infos).
• Inkremetal-Kette ist unbrauchbar: Segment fehlt, Log-Rotation war zu aggressiv, oder Zeitfenster überschneidet sich nicht (bei MongoDB z. B. Oplog-Reichweite zu klein).
• Restore dauert zu lange: RTO (maximal tolerierbare Wiederanlaufzeit) wird ignoriert, bis der Ernstfall eintritt – dann blockieren Rebuilds, Repairs, Replays oder Netzbandbreite.

Die Konsequenz: NoSQL-Backup ist weniger „Datei kopieren“, sondern ein definierter Datenstand plus nachvollziehbarer Weg zurück – inklusive Test.

Grundbegriffe: Konsistenzpunkt, RPO/RTO und „Incremental“ im NoSQL-Kontext

Konsistenzpunkt bedeutet: Es existiert ein Zeitpunkt/Stand, an dem die Daten so vorliegen, dass der Datenbankprozess sie beim Start als gültig akzeptiert und dass sie logisch zusammenpassen. In klassischen Datenbanken wird das über Write-Ahead-Logs (WAL) und Checkpoints erreicht. In NoSQL-Systemen gibt es Entsprechungen – aber sie unterscheiden sich.

RPO (Recovery Point Objective) ist der maximal tolerierbare Datenverlust in Zeit (z. B. 15 Minuten). RTO (Recovery Time Objective) ist die maximal tolerierbare Wiederherstellungszeit (z. B. 2 Stunden). Beide Werte bestimmen, ob Sie eher auf Snapshots, Log-Shipping, inkrementelle Strategien, Replikation oder Kombinationen setzen müssen.

Inkrementelles Backup heißt in der Praxis: Sie sichern nicht jedes Mal den vollen Datenbestand, sondern nur Änderungen seit dem letzten Sicherungspunkt. Bei NoSQL bedeutet das häufig log-basiert (z. B. MongoDB Oplog) oder datei-/segmentbasiert (z. B. Cassandra SSTables plus Commitlog). Wichtig: „Inkremental“ ist nur so gut wie die Rekonstruktionskette und deren Validierung.

Konsistenzpunkte in MongoDB: Snapshots, Checkpoints und Oplog

MongoDB nutzt je nach Version/Storage-Engine üblicherweise WiredTiger. WiredTiger erstellt Checkpoints (konsistente Zustände auf Disk) und nutzt zusätzlich Journaling (Wiederanlauf-Logik). Für Backups ist entscheidend, welches Ziel Sie verfolgen:

• Crash-konsistent: Datenfiles werden im laufenden Betrieb kopiert (z. B. Storage-Snapshot). MongoDB kann beim Start aus Journal/Recovery einen konsistenten Stand herstellen – das ist aber nicht automatisch ein „sauberer“ Applikations-Konsistenzpunkt über mehrere Knoten hinweg.
• Replikations-/zeitpunktkonsistent: Sie sichern einen Stand, der einem definierten Oplog-Zeitpunkt entspricht (Oplog = Operation Log, ein ringförmiges Log replizierter Änderungen im Replica Set). Damit können Sie gezielt bis zu einem Zeitpunkt wiederherstellen (PITR-ähnlich, Point-in-Time-Recovery).

Bewährtes Muster: Backup von einem Secondary (oder Hidden) Node

In Replica Sets ist es üblich, die Sicherung von einem Secondary oder einem Hidden Node zu ziehen (Hidden = nimmt an Replikation teil, bedient aber keine Reads). Vorteil: weniger Last auf dem Primary. Risiko: Wenn die Secondary stark hinterherhinkt (Replication Lag), sichern Sie einen Stand, der im Vergleich zum Primary deutlich älter ist – relevant für Ihr RPO.

Prüfen Sie vor dem Backup mindestens: Replikationsstatus, Lag, Oplog-Fenster. Beispielkommandos:

mongosh --quiet --eval 'rs.printReplicationInfo()'
mongosh --quiet --eval 'rs.status().members.map(m => ({name:m.name, state:m.stateStr, optimeDate:m.optimeDate, health:m.health}))'

Warum das hilft: rs.printReplicationInfo() zeigt u. a. die Oplog-Zeitspanne („log length“). Wenn Ihr inkrementeller Ansatz auf Oplog basiert, muss die Oplog-Reichweite größer sein als Ihr Backup-Intervall plus Puffer (Wartungsfenster, Störungen, Verzögerungen).

Snapshot-Backup: konsistent bekommen, ohne MongoDB zu stoppen

Wenn Sie Storage-Snapshots (LVM, ZFS, SAN/Array, Cloud-Volume-Snapshot) einsetzen, ist das Ziel ein punktgenauer Dateisystem-Stand. Das ist zunächst nur „crash-konsistent“. Für MongoDB ist das häufig ausreichend, wenn Sie das Journal mit sichern und der Snapshot sauber atomar ist (keine halbfertigen Writes über mehrere Volumes).

Praktische Regeln aus dem Betrieb:

• Ein Volume pro MongoDB-Datenpfad (oder Snapshot über alle beteiligten Volumes synchron). Wenn Daten und Journal getrennt liegen, müssen beide in denselben Snapshot-Zeitpunkt fallen.
• Keine Dateikopie per rsync im laufenden Betrieb als „Billig-Backup“. Das wirkt oft, bis es das erste Mal nicht wirkt.
• Aufbewahrung von Metadaten: mongod.conf, Keyfile (Replica Set Auth), TLS-Zertifikate/Keys, Automation-Skripte, Parameter (z. B. featureCompatibilityVersion, falls relevant für Downgrade/Upgrade-Pfade).

Wenn Ihr Ziel Wiederherstellung auf einen exakten Zeitpunkt ist, brauchen Sie zusätzlich eine Oplog-basierte Kette oder einen Mechanismus, der die Log-Position festhält. Ein Snapshot ohne Bezugspunkt lässt sich zwar starten, aber nicht deterministisch „bis 10:37:15“ vorrollen.

Inkrementell in MongoDB: Oplog als Änderungsstrom – mit zwei Haken

Für „Incrementals“ ist das Oplog naheliegend: Es enthält die replizierten Operationen. Zwei typische Haken:

• Oplog ist ein Ring: Wenn Ihr Oplog zu klein dimensioniert ist, überschreibt er alte Einträge. Dann bricht Ihre inkrementelle Kette, selbst wenn alle Backup-Jobs „grün“ sind.
• Topologie- und Rollenwechsel: Failover, Rollback-Szenarien oder Re-Syncs können dazu führen, dass ein Node einen anderen Verlauf hat. In solchen Fällen ist „Oplog fortschreiben“ ohne klare Quelle riskant.

Operational heißt das: Dimensionieren Sie das Oplog-Fenster so, dass es mehrere Backup-Zyklen abdeckt, und überwachen Sie Lag und Oplog-Reichweite. Zusätzlich sollten Restore-Tests immer auch einen „Log-Replay“-Teil enthalten, sonst bleibt PITR theoretisch.

Konsistenzpunkte in Cassandra: SSTables, Commitlog und Snapshot-Logik

Apache Cassandra ist ein verteiltes Wide-Column-System. Daten landen zuerst im Memtable (RAM-Struktur) und werden dann als SSTables (Sorted String Tables, immutable Dateisegmente) auf Disk geschrieben. Zusätzlich gibt es das Commitlog (Write-Ahead-Log), das Writes absichert, bis sie in SSTables „geflusht“ sind.

Für Backups bedeutet das:

• Ein konsistenter Stand besteht oft aus SSTables plus den passenden Commitlog-Segmenten (wenn Sie näher an „bis zum letzten Write“ sichern wollen).
• „Snapshot“ in Cassandra meint in der Regel: Hardlinks/Kopien der aktuellen SSTables pro Keyspace/Table – nicht zwingend ein Storage-Snapshot.
• Weil Cassandra verteilt ist, ist clusterweite Konsistenz schwieriger: Ein Snapshot auf Node A ist nicht automatisch derselbe Stand wie auf Node B.

Cassandra-Snapshots: schnell, aber nur so gut wie Ihr Restore-Pfad

Cassandra kann pro Node Snapshots erzeugen, typischerweise über nodetool. Das ist schnell, weil SSTables unveränderlich sind und häufig nur Hardlinks gesetzt werden. Beispiel:

# Snapshot für einen Keyspace auf einem Node
nodetool snapshot --tag nightly_2026-08-19 my_keyspace

# Auflistung vorhandener Snapshots
nodetool listsnapshots

Warum das funktioniert: SSTables werden nach dem Schreiben nicht mehr geändert. Ein Snapshot referenziert genau diese Dateien. Wann es scheitert: Wenn Sie beim Restore nicht sauber wissen, welche SSTables zu welchem Zeitpunkt und zu welcher Topologie gehören, oder wenn Sie Snapshots nur von einem Teil der Nodes haben (je nach Replikationsfaktor und Tokenverteilung).

Inkrementelle Backups in Cassandra: „incremental backups“ vs. wirklich inkrementell

Cassandra bietet „incremental backups“ als Feature, bei dem neue SSTables zusätzlich in ein Backup-Verzeichnis hardverlinkt/kopiert werden. Das ist nützlich, aber kein vollständiges Backup-Konzept: Sie brauchen weiterhin Snapshots als Baseline und müssen die Kette kontrollieren (Retention, Cleanup, Wiederherstellung).

Wichtige Betriebsaspekte:

• Compaction (Hintergrundprozess zum Zusammenführen von SSTables) erzeugt neue SSTables und obsolet macht alte. Das beeinflusst, welche Dateien Sie sichern müssen und wie schnell Backup-Verzeichnisse wachsen.
• Commitlog: Je nach RPO/RTO-Anspruch kann es nötig sein, Commitlog-Segmente zu sichern oder zumindest sicherzustellen, dass Snapshots nach einem Flush genommen werden, um Commitlog-Abhängigkeiten zu minimieren.
• Repair: Cassandra benötigt regelmäßige Repairs (Abgleich zwischen Replikaten). Ein Restore ohne nachgelagerte Repair-Strategie kann zu „stillen“ Inkonsistenzen führen.

Incrementals sauber aufbauen: Drei Strategien, die in der Praxis funktionieren

Bei MongoDB und Cassandra sehen die Mechanismen unterschiedlich aus, aber die Planung folgt oft ähnlichen Mustern. Drei Strategien, die im Betrieb wiederkehren:

1) Full + Log-Shipping (PITR-nah)

Sie erstellen regelmäßig ein Vollbackup (Snapshot/Dump) und sichern fortlaufend Logs/Änderungsströme. Bei MongoDB ist das typischerweise Oplog-basiert, bei Cassandra eher Commitlog-orientiert (oder über externe Streaming/CDC-Ansätze, falls vorhanden). Vorteil: gutes RPO. Nachteil: Restore ist komplexer, weil Replays und Reihenfolge stimmen müssen.

2) Full + „Block-/Datei-Incremental“ (Storage-/Backup-System macht Deltas)

Hier übernimmt ein Backup-System Deduplizierung und Block-Incrementals (z. B. auf Dateisystemebene). Vorteil: weniger DB-spezifische Logik. Risiko: Sie bekommen zwar „Deltas“, aber keine garantierte Anwendungs-Konsistenz, wenn der Konsistenzpunkt nicht sauber erzeugt wird (Quiesce/Checkpoint/koordinierte Snapshots).

3) Replikation ist nicht Backup – aber sinnvoller Baustein

Replikation (Replica Set, Multi-DC in Cassandra) schützt primär gegen Node-Ausfälle und erhöht Verfügbarkeit. Sie ersetzt kein Backup, weil logische Fehler (Löschungen, fehlerhafte Jobs, Ransomware mit gültigen Credentials) repliziert werden. In der Praxis kombiniert man Replikation mit Backups, um RTO zu senken und Backups als „letzte Instanz“ zu nutzen.

Restore-Realität: Was Sie zusätzlich zu den Daten immer sichern müssen

Viele Restore-Probleme entstehen nicht durch fehlende Datenfiles, sondern durch fehlende „Betriebsumgebung“. Legen Sie fest, was zu einem wiederherstellbaren Zustand gehört:

• Konfiguration: mongod.conf / cassandra.yaml, JVM-Optionen, Parameter für Storage, Netzwerk, Auth.
• Sicherheitsmaterial: TLS-Zertifikate/Keys, Keyfiles, Keystores/Truststores, KMS-/Vault-Referenzen, Passwörter/Secrets (mit eigenem Backup-Konzept).
• Cluster-Metadaten: Replica Set Name, Seed-Nodes, Token/Rack/DC-Topologie (Cassandra), Auth-/RBAC-Definitionen.
• Indizes und Nebenstrukturen: Bei MongoDB sind Indizes Teil der Daten, aber ein Restore kann sie ggf. neu bauen müssen (Zeit!). Bei Cassandra hängen Query-Performance und Stabilität stark von der erwarteten SSTable-/Index-Lage ab.
• Runbooks: Schrittfolge, Ansprechpartner, DNS/Load-Balancer-Umschaltung, Monitoring-Checks, „Stop-The-Bleed“-Maßnahmen.

Ein guter Ansatz ist, diese Artefakte versioniert abzulegen (z. B. in einem gesicherten Git-Repo) und zusätzlich im Backup zu erfassen, damit Restore auch bei Tool-/Repo-Ausfällen möglich bleibt.

Praxis-How-to: Preflight-Checks vor jedem NoSQL-Backup

Preflight heißt: Sie prüfen Bedingungen, die später nicht mehr reparierbar sind. Die Checks sind kurz, aber sie sparen Stunden beim Restore.

MongoDB Preflight: Replikation, Oplog, Storage, Locks

• Replica Set stabil, kein Re-Sync, kein dauerhafter Lag
• Oplog-Fenster größer als Backup-Intervall + Puffer
• Genug freier Platz für Snapshot/Export und für Restore-Test
• Keine Wartung (z. B. Index-Rebuild) im Konflikt mit Snapshot-Zeitfenster

# Basisstatus und Oplog-Fenster prüfen
mongosh --quiet --eval 'rs.status().ok'
mongosh --quiet --eval 'rs.printReplicationInfo()'

# Optional: wichtige Server-Infos (Version, Storage Engine)
mongosh --quiet --eval 'db.serverStatus().version'
mongosh --quiet --eval 'db.serverStatus().storageEngine'

Cassandra Preflight: Cluster health, pending compactions, repair/streaming

• Alle Nodes „UN“ (Up/Normal), keine instabilen Nodes
• Keine großen Streaming-Vorgänge oder ausufernde Pending Compactions
• Backup-Tag/Namensschema konsistent (für spätere Zuordnung)

nodetool status
nodetool tpstats
nodetool compactionstats

Interpretation: Ein Snapshot während massiver Compaction ist nicht grundsätzlich „falsch“, aber Sie müssen mit Wachstum und längeren Laufzeiten rechnen. Für Betreiber ist entscheidend: Snapshots sollen planbar sein, nicht „läuft irgendwann durch“.

Wiederherstellung planen: Schrittfolge, Prüfungen und Rückfallstrategie

Die Wiederherstellung ist kein einzelner Befehl, sondern eine kontrollierte Sequenz. Bewährt hat sich ein Restore-Runbook mit klaren Gates (Go/No-Go) und einem Rückfallplan.

Restore-Gates: drei Prüfpunkte, die Sie nicht überspringen sollten

1. Artefakte vollständig? Daten + Konfig + Security-Material + Versionsinfos. Fehlende Keys oder falsche Config kosten sonst später Zeit.
2. Zielumgebung stimmt? Versionen kompatibel (MongoDB/Cassandra), Kernel/Filesystem passend, Storage-Performance ausreichend. Ein Restore auf „irgendeine VM“ ist oft der Beginn langer Nachtarbeit.
3. Validierung nach Restore: Service startet, Cluster stabil, Konsistenz-/Integritätschecks, Applikations-Smoke-Tests, Monitoring wieder grün.

Rückfallstrategie: Wenn Restore nicht sauber wird

Planen Sie einen definierten Rückfall, statt ad hoc zu improvisieren:

• Parallel-Restore: Wiederherstellung in isolierter Umgebung (separates VLAN/Namespace), dann kontrollierte Umschaltung (DNS/Load-Balancer). So vermeiden Sie, dass ein halbfertiger Restore Produktionsdaten überschreibt.
• Read-only Phase: Wenn möglich, schalten Sie Anwendungen auf Read-only (oder degradierten Modus), um Datenänderungen zu stoppen, bevor Sie „zurückdrehen“.
• Letztes bekannt gutes Backup: Definieren Sie, welche Generation als „Known Good“ gilt (besteht Restore-Test), und dokumentieren Sie den Pfad dorthin.

Troubleshooting: Häufige Stolperfallen bei MongoDB- und Cassandra-Backups

MongoDB: Oplog zu klein, Failover zur falschen Zeit, Snapshot ohne Journal

Symptom: Inkremental-Replay nicht möglich, weil Oplog-Lücken entstehen.

Ursache: Oplog-Fenster deckt das Intervall nicht ab, oder Sie sichern von einem Node mit instabilem Verlauf (Rollback).

Gegenmaßnahmen:

• Oplog-Dimensionierung erhöhen und überwachen (Trend über Tage/Wochen).
• Backup-Quelle fixieren (z. B. Hidden Secondary) und Failover-Szenarien in der Backup-Logik berücksichtigen.
• Snapshot-Strategie so bauen, dass Journal/Datenpfade gemeinsam konsistent gesichert werden.

Cassandra: Snapshot nur auf einigen Nodes, falsche Reihenfolge, Repair-Lücke

Symptom: Restore startet, aber Daten sind unvollständig oder Abfragen liefern unterschiedliche Ergebnisse je Node.

Ursache: Snapshot wurde nicht clusterweit (für alle relevanten Replikate) koordiniert oder Restore wurde ohne nachgelagerte Repair-Strategie in Betrieb genommen.

Gegenmaßnahmen:

• Snapshot-Runbook pro Node automatisieren und Erfolg zentral einsammeln (nicht „per SSH hoffen“).
• Restore immer mit definiertem Post-Restore-Plan (z. B. Repair/Validierung) koppeln, abgestimmt auf Replikationsfaktor und Konsistenzlevel.
• Retention und Cleanup sauber halten: volle Disziplin bei Tags/Zeiträumen, sonst ist die Kette nicht mehr nachvollziehbar.

Backup-Validierung: So testen Sie Wiederherstellbarkeit ohne Produktionsrisiko

„Backup erfolgreich“ ist nur ein Signal, dass Daten weggeschrieben wurden. Ob sie wiederherstellbar sind, zeigt erst ein Test. Für NoSQL empfiehlt sich ein abgestufter Ansatz:

• Technischer Restore-Test: Daten in isolierte Umgebung zurückspielen, DB startet, Cluster bildet sich, Grundfunktionen laufen.
• Logik-/Smoke-Tests: Beispielabfragen, Zählungen, Stichproben (z. B. wichtige Collections/Keyspaces), optional Checksummen-/Vergleichsmethoden.
• RTO-Messung: Zeit stoppen (Download/Decrypt/Restore/Rebuild/Repair). Wenn RTO nicht passt, müssen Sie Restore-Pfade optimieren, nicht nur Backup-Frequenz erhöhen.

Wichtig für den Alltag: Restore-Tests müssen nicht jedes Mal „alles“ prüfen. Aber es sollte regelmäßig ein vollständiger Drill stattfinden, bei dem das Team den Prozess durchläuft, Logs und Zeiten dokumentiert und das Runbook verbessert.

Checkliste: Minimaler Standard für Backups von MongoDB und Cassandra

• Definierte Zielwerte: RPO/RTO schriftlich, inkl. Ausnahmen (Wartungsfenster, große Deployments).
• Quellknoten festgelegt: MongoDB bevorzugt Secondary/Hidden, Cassandra Snapshot-Plan pro Node.
• Konsistenzpunkt dokumentiert: Zeitpunkt/Tag, Oplog-/Log-Position, Snapshot-ID, Versionsinfos.
• Inkremental-Kette überwacht: Oplog-Fenster, Log-Retention, Storage-Wachstum, Compaction-Effekte.
• Konfig & Security gesichert: Konfigurationen, Keys, Zertifikate, Secrets-Referenzen.
• Restore-Runbook vorhanden: Schrittfolge, Gates, Rückfall, Verantwortlichkeiten.
• Regelmäßige Restore-Tests: isoliert, dokumentiert, mit RTO-Messung.

Fazit: NoSQL-Backup ist ein Restore-Projekt – nicht nur ein Sicherungslauf

Bei MongoDB und Cassandra entscheidet nicht das „ob“, sondern das „wie“: Konsistenzpunkte müssen bewusst erzeugt und nachvollziehbar gemacht werden, Incrementals brauchen eine robuste Kette (Oplog/Logs/SSTables) und Wiederherstellung muss als geübter Prozess existieren. Wenn Sie Preflight-Checks, saubere Metadaten und regelmäßige Restore-Übungen etablieren, werden Backups von einer Pflichtübung zu einem belastbaren Betriebsmittel – auch dann, wenn nachts um 03:00 Uhr niemand Zeit für Experimente hat.

Für dieses Thema sind auch Mongodb Backup und Cassandra Backup wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.