MongoDB-Backup und -Restore (mongodump, mongorestore, Snapshot)

Richtet für ein installiertes MongoDB eine Backup-Routine ein und beschreibt die Wiederherstellung aus dem Backup Szenario für Szenario. Backup: mongodump einer einzelnen Collection, einer Datenbank oder des gesamten Deployments (--archive --gzip; im Replica Set ein konsistenter Zeitpunkt mit --oplog, Lesen vom Secondary), Credential-Datei, zeitgesteuerte Backups mit Aufbewahrungsdauer per systemd-Timer/cron, Test-Restore und optional ein Dateisystem-Snapshot. Restore: Restore-Probe, vollständiger Restore, einzelne Datenbank/Collection, Rückkehr zu einem bestimmten Zeitpunkt aus Backup + Oplog, Klon in einen anderen Cluster und Sharded Cluster. Bei Hunderten von GB Daten, wenn eine schnelle Wiederherstellung nötig ist, oder im Sharded Cluster sind Snapshots oder ein Enterprise-Werkzeug (PBM, Ops Manager) mongodump vorzuziehen; die Auswahl wird in den ersten Schritten erklärt.

Topologie: Backup-Server oder ein Member + Replica Set / Einzelinstanz / Sharded Cluster (mongos)

Szenarien

• Backup einrichten: mongodump, Zeitplanung und Test-Restore — Backup-Benutzer, Credential-Datei, manueller und zeitgesteuerter mongodump, Test-Restore unter neuem Namen; optional Snapshot und mongoexport. Wenn du das zum ersten Mal einrichtest, beginne hier.
• Lässt sich das Backup wirklich wiederherstellen? (--dryRun und Probe auf einer temporären Instanz) — Ohne Live-Daten anzufassen: Integrität des Archivs, enthaltene Namespaces und Oplog, optional ein vollständiger Restore in einen temporären mongod mit Dokumentzählung.
• Alle Daten aus dem Backup wiederherstellen (vollständiger Restore, --drop) — Daten sind weitgehend verloren oder beschädigt, und das Deployment kehrt auf den Zeitpunkt des Backups zurück. Schreibvorgänge nach dem Backup gehen verloren; die Anwendung steht während des Restores.
• Einzelne Datenbank oder Collection zurückholen (--nsInclude, unter neuem Namen oder an Ort und Stelle) — Eine Collection/Datenbank wurde gelöscht oder beschädigt, der Rest ist intakt: Nur dieser Namespace kommt aus dem Backup; andere Daten bleiben unberührt, die Anwendung kann weiterlaufen.
• Zu einem bestimmten Zeitpunkt zurückkehren: Backup + Oplog (versehentliches Drop, fehlerhaftes Update/Delete) — Die fehlerhafte Operation geschah nach dem Backup, und die Schreibvorgänge bis zu diesem Zeitpunkt werden ebenfalls gebraucht: Das letzte vollständige Backup wird wiederhergestellt, das Live-Oplog bis unmittelbar vor die fehlerhafte Operation angewendet (--oplogReplay --oplogLimit). Nur Replica Set.
• Backup in einen anderen Cluster / auf einen anderen Server einspielen (Klon, Testumgebung, Migration) — Das Quell-Deployment bleibt unberührt: Das Backup wird in ein anderes Replica Set oder eine andere Instanz eingespielt (Test-/Reporting-Kopie, Servermigration, Versionswechsel); Benutzer werden optional übernommen.
• Sharded Cluster wiederherstellen: Grenzen von mongodump und die richtige Methode — Die gesicherte Topologie ist ein Sharded Cluster: logischer Restore über mongos (Shard Keys neu anlegen, Balancer) oder physischer Wiederaufbau des gesamten Clusters aus koordinierten Snapshots.

Vor dem Start

• Der gesicherte Server läuft auf einem unterstützten Betriebssystem; die Uhr ist per NTP synchronisiert und die Zeitzone stimmt (Backup-Dateinamen und Zeitplanung richten sich nach der lokalen Zeit).
• Von diesem Server aus sind die Namen von … auflösbar und die Ports erreichbar.… Im Replica Set müssen die Namen im Connection String mit den Member-Namen in rs.conf() übereinstimmen; der Treiber verbindet sich zu diesen Namen.…
• … liegt auf einer vom Datenträger der Daten getrennten Platte oder einer Netzwerkfreigabe, und der freie Platz beträgt mindestens die komprimierte Backup-Größe (meist 20–50 % der Daten) mal die Aufbewahrungsdauer. Ein Backup auf derselben Platte geht beim Verlust der Platte zusammen mit den Daten verloren.
• Die Autorisierung ist aktiviert, und dir liegen der Benutzer … (root oder die Rollen userAdminAnyDatabase + clusterAdmin) und sein Passwort vor. Der Backup-Benutzer wird mit diesem Benutzer angelegt.
• Das Oplog-Fenster ist deutlich länger als die Dauer eines vollständigen Backups (mindestens einige Stunden). --oplog sammelt die während des Backups entstehenden Oplog-Einträge; ist das Fenster kürzer als das Backup, schlägt das Backup fehl.… Bei der Point-in-Time-Recovery muss der erste Eintrag im Live-Oplog vor dem Zeitpunkt liegen, an dem das verwendete vollständige Backup beendet wurde; andernfalls sind die Operationen dazwischen nirgends vorhanden.…
• HTTPS-Zugriff auf das MongoDB-Repo (repo.mongodb.org) besteht oder ein interner Mirror ist eingerichtet; sind die Werkzeuge bereits auf dem Server installiert, werden ihre Versionen angezeigt.
• dbPath (…) liegt auf dem LV …, und die Volume Group hat mindestens … frei. Das WiredTiger-Journal (…/journal) muss auf demselben LV liegen; wurde es auf eine andere Platte verschoben, ist fsyncLock vor dem Snapshot Pflicht.
• Du hast root- oder sudo-Rechte. Für einen vollständigen Restore liegen ein Wartungsfenster und die Freigabe des Anwendungsteams vor.… Vor dem Restore wurde der Vorfall dokumentiert (wann, welche Operation, wer); das Anwendungsteam weiß, welche Daten zurückkommen.…
• Das Backup ist mit dem Szenario „Backup einrichten“ dieses Guides eingerichtet: Die Werkzeuge (mongorestore, mongosh) und die Credential-Datei … (…: backup + restore) sind auf diesem Server vorhanden. Andernfalls führe zuerst die ersten beiden Phasen des Szenarios Backup einrichten aus.
• Beim Restore werden Daten und Indexe neu geschrieben: Auf dem Datenträger der Zielserver ist mindestens das 1,5-Fache der (unkomprimierten) wiederherzustellenden Daten frei.… Im Replica Set erhalten die Secondaries dieselben Schreibvorgänge per Replikation; das Oplog-Fenster schrumpft während des Restores.…
• Für … ist freier Platz in Höhe der unkomprimierten Größe der wiederherzustellenden Daten (vollständiges Backup + Oplog) vorhanden. Der temporäre mongod lauscht nur auf 127.0.0.1, Port …; der Port muss frei sein.
• Das Ziel (…) ist installiert und läuft, die Autorisierung ist aktiviert, und dir liegt das Passwort des Benutzers … (root) vor. Die Zielversion ist gleich der Quellversion oder neuer (z. B. 7.0 → 8.0); ein Restore auf eine ältere Version wird nicht unterstützt.

Phasen der Anleitung

• Installation der Werkzeuge — MongoDB-…-Repo hinzufügen · MongoDB-…-Repo hinzufügen · mongodump, mongorestore und mongosh installieren · Backup-Verzeichnis vorbereiten
• Backup-Benutzer und Credential-Datei — Backup-Benutzer anlegen · Credential-Datei schreiben (--config) · Verbindung testen
• Manuelles Backup (mongodump) — Datengröße und Oplog-Fenster prüfen · Balancer stoppen · Backup mit mongodump erstellen · Balancer wieder starten · Backup prüfen (gzip und dryRun) · Teilmengen-Backup per Abfrage (--query)
• Restore (mongorestore) — Test-Restore unter neuem Namen (--nsFrom/--nsTo) · Dokumentzahlen vergleichen · Testdatenbank löschen · Rolle für oplogReplay definieren · Vollständiger Restore an Ort und Stelle (--drop) · Temporäres Recht entziehen …
• mongoexport / mongoimport (Datenübertragung, kein Backup) — Collection exportieren (mongoexport) · In eine separate Collection importieren (mongoimport) · Datentypen vergleichen und aufräumen
• Dateisystem-Snapshot — LVM-Snapshot erstellen (mit fsyncLock) · Snapshot ins Backup-Verzeichnis archivieren · Dateikopie mit fsyncLock erstellen
• Backup eines Sharded Clusters: Grenzen und der Enterprise-Weg — Methode für ein konsistentes Backup des Sharded Clusters wählen
• Zeitgesteuertes Backup und Aufbewahrung — Balancer auf Zeiten außerhalb der Backup-Stunden beschränken · Backup-Skript schreiben · Skript ausführbar machen · SSH-Zugriff auf den entfernten Server vorbereiten · systemd-Service und -Timer anlegen · Zeitgesteuertes Backup manuell auslösen und prüfen …
• Monitoring und Wartung — Alter des letzten Backups überwachen · Regelmäßige Wiederherstellungsübung
• 1. Diagnose: Backup-Dateien und Werkzeuge — Backup-Dateien und die neuesten Backups der Reihe nach auflisten
• 2. Probe: Archiv lesen — Integrität der Komprimierung prüfen (gzip -t) · Restore ohne Schreiben von Daten testen (--dryRun) · Enthält das Archiv ein Oplog? (konsistenter Zeitpunkt)
• 3. Probe: vollständiger Restore in eine temporäre Instanz — mongod für die temporäre Instanz vorbereiten · Temporären mongod starten · Backup in die temporäre Instanz einspielen · Wiederhergestellte Daten zählen · Temporäre Instanz stoppen und entfernen
• 4. Abschluss — Ergebnis der Probe dokumentieren
• Sharded Cluster: Ein vollständiger Restore erfolgt nicht mit diesem Szenario — Zum Szenario für Sharded Cluster wechseln
• 1. Diagnose: Ist ein vollständiger Restore das richtige Szenario? — Aktuellen Zustand und betroffene Daten ansehen · Restore ohne Schreiben von Daten testen (--dryRun)
• 2. Sicherheitsnetz — Anwendung stoppen und Verbindungen prüfen · Aktuellen Zustand sichern (Rückfallpunkt)
• 3. Durchführung: vollständiger Restore — Temporäres Recht für oplogReplay vergeben · Backup an Ort und Stelle wiederherstellen (--drop… --oplogReplay…) · Temporäres Recht entziehen · Temporäre Benutzer-Collections des Restores aufräumen
• 4. Prüfung — Dokument- und Indexanzahl prüfen · Prüfen, ob das Replica Set aufgeholt hat
• 5. Abschluss — Neues vollständiges Backup erstellen und Anwendung starten
• 1. Diagnose: aktueller Stand des Namespace und Stand im Backup — Live-Zustand ansehen · Restore ohne Schreiben von Daten testen (--dryRun)
• 2. Sicherheitsnetz — Aktuellen Zustand sichern (Rückfallpunkt)
• 2. Durchführung: unter neuem Namen wiederherstellen — Backup unter neuem Namen wiederherstellen (--nsFrom/--nsTo) · Zahlen im Backup und in der Live-Umgebung vergleichen · Gelöschte Dokumente in die Live-Umgebung zurückschreiben ($merge) · Temporäre Kopie löschen
• 3. Durchführung: an Ort und Stelle wiederherstellen (--drop) — Shard Key erhalten: Collection neu sharden · Namespace an Ort und Stelle wiederherstellen
• Point-in-Time-Recovery nur im Replica Set — In diesem Deployment ist keine Point-in-Time-Recovery mit dem Oplog möglich
• 1. Diagnose: Zeitpunkt der fehlerhaften Operation und Oplog-Fenster — Fehlerhafte Operation im Oplog finden · Prüfen, ob das vollständige Backup im Oplog-Fenster liegt
• 2. Sicherheitsnetz: Live-Oplog kopieren — Kopie des Live-Oplogs erstellen · Aktuellen Zustand sichern (Rückfallpunkt)
• 3. Durchführung: auf einer temporären Instanz zu diesem Zeitpunkt zurückkehren — mongod für die temporäre Instanz vorbereiten · Temporären mongod starten · Vollständiges Backup in die temporäre Instanz einspielen · Live-Oplog bis unmittelbar vor die fehlerhafte Operation anwenden · Zurückgeholte Daten auf der temporären Instanz prüfen · Zurückgeholte Daten in die Live-Umgebung übernehmen …
• 4. Abschluss — Neues vollständiges Backup erstellen und Ursache beseitigen
• 1. Diagnose: Ist das Ziel richtig und kompatibel? — Prüfen, dass das Ziel nicht die Quelle ist, und seine Version prüfen · Restore ohne Schreiben von Daten testen (--dryRun)
• 2. Sicherheitsnetz und Zugangsdaten für das Ziel — Temporäre Credential-Datei für das Ziel schreiben · Vorhandene Daten auf dem Ziel sichern