Lösung für die Sicherung und Wiederherstellung von MongoDB im Unternehmensumfeld

Home > Bacula Enterprise Backup Lösungen > MongoDB-Backup-Lösung der Enterprise-Klasse für groß angelegte Bereitstellungen

NoSQL-Datenbanken wie MongoDB können dank ihres skalierbaren Designs enorme Datenmengen und hohen Datenverkehr bewältigen, was sie zu einer unschätzbaren Lösung für Unternehmen macht, die Millionen von gleichzeitigen Nutzern verwalten.

Allerdings birgt die Sicherung eines NoSQL-Clusters an sich eine Reihe von Herausforderungen hinsichtlich der Datenkonsistenz, die herkömmliche Backup-Lösungen nicht bewältigen können. Denn das Kopieren von Rohdatenbankdateien bei laufendem Server kann zu inkonsistenten oder nicht wiederherstellbaren Daten führen, da sich die Dateien zwischen den Lesevorgängen ändern können

Das MongoDB-Backup- und Wiederherstellungs-Plugin von Bacula Enterprise ist direkt mit der MongoDB-Engine verbunden und automatisiert logische Backups einer laufenden Datenbank für Einzel-Server und Replikatsätze, ohne Schreibvorgänge zu unterbrechen. Bei Sharded-Clustern müssen Sie jedoch zunächst mehrere Voraussetzungen erfüllen, um das logische Backup zu automatisieren.

Darüber hinaus begrenzt die isolierte Fünf-Modul-Architektur von Bacula den Schadensumfang, wenn Ihre MongoDB-Datenbank kompromittiert wird, und ermöglicht eine schnelle Wiederherstellung, wenn die Architektur mit Netzwerksegmentierung, eindeutigen Anmeldedaten und beidseitigem TLS kombiniert wird.

Testversion herunterladen

Die wichtigsten Vorteile der MongoDB-Lösung für Datensicherung und -wiederherstellung

Konsistente Backups aktiver MongoDB-Datenbanken – Das MongoDB-Plugin von Bacula verhindert die inkonsistenten Artefakte, die beim einfachen Kopieren von Dateien entstehen, indem es das MongoDB-eigene Tool mongodump direkt steuert. Bei eigenständigen Servern entsteht so ein logischer Snapshot des Datenbankinhalts. Bei Replikatsätzen erzeugt das Plugin eine vollständig konsistente Wiederherstellungskette, indem es dem Dump Oplog-Metadaten hinzufügt.
Koordinierte logische Sicherung für shardierte MongoDB-Cluster – Das MongoDB-Plugin von Bacula bietet shardierten Cluster-Bereitstellungen einen koordinierten logischen Sicherungsablauf, ohne dass benutzerdefinierte Orchestrierungsskripte erforderlich sind. Es erfasst Anwendungsdaten über mongos sowie Routing-Metadaten für die logische Wiederherstellung der Anwendungsdaten. Die Konsistenz über die Shards hinweg hängt jedoch davon ab, dass der Balancer angehalten wird und Schreibvorgänge für die Dauer der Sicherung verhindert werden.

Granulare MongoDB-Wiederherstellung auf Datenbank- und Collection-Ebene – Mit dem MongoDB-Plugin können Sie bestimmte Datenbanken oder einzelne Collections filtern und wiederherstellen, ohne den gesamten Datenbankcluster wiederherstellen zu müssen. Dadurch verkürzen sich die Wiederherstellungszeiten erheblich, und das Risiko, dass neben beschädigten Daten auch intakte Daten überschrieben werden, wird deutlich verringert. *Die granulare Wiederherstellung auf Kollektions-Ebene gilt für logische Voll-Artefakte und kann nicht mit der Oplog-Wiedergabe kombiniert werden, was bedeutet, dass Sie eine bestimmte Kollektion nicht in einem einzigen Vorgang auf einen genauen Zeitpunkt zurücksetzen können.
Point-in-Time-Wiederherstellung für MongoDB-Replikatsätze – Da eine verpfuschte Schemamigration oder das versehentliche Löschen einer Sammlung bekanntermaßen stundenlange Schreibvorgänge zunichte machen kann, zeichnet das MongoDB-Plugin von Bacula bei jedem inkrementellen und differentiellen Job Segmente des Betriebsprotokolls auf, um eine präzise Point-in-Time-Wiederherstellung (PITR) zu ermöglichen. Mit dem Parameter replay_to können Sie die Wiedergabe an jedem beliebigen Punkt innerhalb des verfügbaren Oplog-Fensters anhalten. Diese Funktion ermöglicht es Ihnen, das Replica-Set auf den nächstgelegenen geschützten Zustand vor dem Vorfall wiederherzustellen.

Wichtigste Funktionen des MongoDB-Plugins von Bacula

Datenintegrität und Zugriffssicherheit

Überprüfung der Kettenkontinuität vor der Wiederherstellung – Bei jeder ausgelösten Wiederherstellung überprüft das MongoDB-Plugin automatisch die Integrität der Prüfsumme, die Kettenidentität, die Verknüpfung zum übergeordneten Element, den Quell-Fingerabdruck und die Oplog-Grenzen. Sollten Angaben fehlen oder nicht übereinstimmen, blockiert das Plugin die Wiederherstellung, bevor diese die Datenbank erreichen kann.
Unterstützung für TLS und MONGODB-X509-Authentifizierung – Das MongoDB-Plugin stellt eine Verbindung zu gesicherten MongoDB-Umgebungen her, ohne dass dabei Abstriche bei den Authentifizierungsstandards gemacht werden müssen. Es unterstützt TLS sowohl für die Java-Treiberverbindung als auch für die MongoDB-Datenbank-Tools-Ebene; SCRAM für die passwortbasierte Authentifizierung; sowie MONGODB-X509 für die zertifikatsbasierte Authentifizierung, wobei der MongoDB-Benutzername exakt mit dem Subject des Client-Zertifikats übereinstimmen muss. Darüber hinaus werden die Anmeldedaten über eine Passwortdatei verwaltet, um sie aus den Jobprotokollen und der Konfigurationsausgabe herauszuhalten.
Metadaten zu Manifest und Kette für die Nachvollziehbarkeit – Jeder MongoDB-Sicherungsjob erzeugt einen vollständigen, überprüfbaren Nachweis darüber, was gesichert wurde, einschließlich der Quellversion, der Topologie, der ausgewählten Datenbanken und der Prüfsummen. Diese Metadatendateien werden zusammen mit den Sicherungsartefakten im Bacula-Katalog unter /@mongodb gespeichert und stehen für Audits und die Wiederherstellungsplanung zur Verfügung, ohne dass die Live-Umgebung berührt werden muss.

Adaptive Backup-Infrastruktur

Unterstützung für Backups mit verschiedenen Topologien – Das Plugin unterstützt alle drei MongoDB-Bereitstellungstypen (nämlich Standalone-Server, Replica-Sets und Sharded-Cluster), und das Backup-Verhalten passt sich automatisch an die jeweilige Topologie an, ohne dass ein manueller Eingriff erforderlich ist. Standalone-Server erhalten ein vollständiges logisches Backup über mongodump. Replica-Sets erhalten ein Voll-Backup, das eine Wiederherstellungskette initiiert, gefolgt von inkrementellen und differentiellen Jobs, die Oplog-Segmente aufzeichnen. Sharded-Cluster werden über mongos gesichert, wobei neben den Anwendungsdaten auch Routing-Metadaten erfasst werden.
Dry-Run-Berichterstellung für Sicherung und Wiederherstellung – Der Befehl dry_run=yes erstellt einen vollständigen Bericht darüber, was die Sicherung oder Wiederherstellung beinhalten würde, ohne dabei etwas zu schreiben oder zu ändern, sodass Konfigurationsfehler oder Kompatibilitätsprobleme bereits lange vor der Ausführung des Auftrags in einer Live-Umgebung erkannt werden. Bei der Sicherung werden dabei die Verbindung, die Topologie, die Berechtigungen, die Tool-Kompatibilität und der verfügbare Arbeitsspeicher überprüft.

Der vollständige Funktionsumfang des MongoDB-Plugins

Die Wiederherstellung zu einem bestimmten Zeitpunkt ist zusammen mit den anderen zuvor aufgeführten Funktionen nur ein Teil des Gesamtbildes dessen, was das Plugin für die Sicherung und Wiederherstellung Ihrer MongoDB-Datenbank leisten kann. Nachfolgend sehen Sie die breite Palette an Funktionen, die das Plugin großen Unternehmen mit Millionen von gleichzeitigen Benutzern bietet.

Sicherungsfunktionen

Vollständige, inkrementelle und differentielle Sicherungen – Das Plugin unterstützt alle drei Job-Ebenen. Replica-Sets erhalten echte Oplog-basierte Ketten; bei eigenständigen und shardbasierten Bereitstellungen werden auf jeder Ebene logische Artefakte im Vollsicherungsstil erstellt.
Logische Sicherung über mongodump – Jede Sicherung ist ein logisches Artefakt, das vom MongoDB-eigenen Tool mongodump erzeugt wird und den tatsächlichen Inhalt der Datenbank zum Zeitpunkt der Auftragsausführung wiedergibt.
Filterung nach Datenbank und Sammlung – Mit Ein- und Ausschlussfiltern können Sie jeden Sicherungsauftrag auf bestimmte Datenbanken oder einzelne Sammlungen einschränken.
Erfassung von Routing-Metadaten in Sharded-Clustern – Bei Sharded-Bereitstellungen erfasst das Plugin neben den Anwendungsdaten auch Metadaten zur Shard-Zugehörigkeit und zum Routing, um die Wiederherstellungsplanung auf Anwendungsebene über mongos zu unterstützen. Dies umfasst ausschließlich die logische Wiederherstellung von Anwendungsdaten.

Wiederherstellungsfunktionen

Point-in-Time-Wiederherstellung für Replikatsätze – Der Parameter replay_to stoppt die Oplog-Wiedergabe an einem beliebigen Punkt innerhalb des verfügbaren Oplog-Fensters. Die Genauigkeit der Wiederherstellung hängt von der Oplog-Aufbewahrungsdauer, der Jobhäufigkeit und der zuletzt erfolgreich erfassten Kettengrenze ab.
Streaming-Wiederherstellung in mongorestore – Vollständige Archivdaten werden direkt aus dem Bacula-Speicher in mongorestore gestreamt, ohne dass zuvor vollständige Dump-Archive auf die lokale Festplatte geschrieben werden müssen.
Hostübergreifende Wiederherstellung – Das Plugin streamt Artefakte in mongorestore auf jedem gültigen Ziel, was Sandbox-Tests und Cluster-Migrationen unterstützt. Allerdings garantiert die Portabilität des logischen Formats nicht, dass jede Kombination aus Serverversion, Version der Datenbank-Tools, FCV, Indexdefinition oder Sammlungsfunktion wiederhergestellt werden kann.
Konfliktstrategie-Steuerung – Der Parameter conflict_strategy steuert, wie das Plugin mit vorhandenen Daten auf dem Wiederherstellungsziel umgeht. Sie können conflict_strategy=fail über die Bacula-Wiederherstellungssitzung für Validierungswiederherstellungen festlegen und conflict_strategy=drop nur dann, wenn die vorhandenen Zieldaten sicher ersetzt werden können.

Sicherheit

TLS-Verbindungsunterstützung – TLS wird sowohl auf der Ebene der Java-Treiberverbindung als auch auf der Ebene der MongoDB-Datenbank-Tools unterstützt.
SCRAM- und MONGODB-X509-Authentifizierung – Das Plugin unterstützt außerdem die passwortbasierte SCRAM-Authentifizierung sowie die zertifikatsbasierte MONGODB-X509-Authentifizierung, wobei der MongoDB-Benutzername wortwörtlich mit dem Betreff des Client-Zertifikats übereinstimmen muss.

Isolierung von Anmeldedaten über „password_file“ – Die Anmeldedaten für die Verbindung werden über eine password_file verwaltet. Sie sind nicht in URIs eingebettet, wodurch sie von Job-Protokollen und Konfigurationsausgaben getrennt bleiben.
Backup-Benutzer mit minimalen Berechtigungen – Das Plugin ist so konzipiert, dass es unter einem dedizierten MongoDB-Backup-Benutzer ausgeführt wird, dem nur die für den ausgewählten Backup-Modus erforderlichen Berechtigungen gewährt werden.

MongoDB-Plugin für Sicherung und Wiederherstellung: Vergleich der Topologien

Das MongoDB-Plugin passt sein Sicherungsverhalten an die Topologie der jeweiligen Bereitstellung an, mit der es verbunden ist. Die folgende Tabelle zeigt, was die einzelnen Topologien unterstützen, damit Sie Ihre Sicherungsstrategie und Ihre Erwartungen hinsichtlich der Wiederherstellung leichter planen können, bevor der erste Auftrag ausgeführt wird.

Funktionalität	Standalone	Replica-Set	Sharded Cluster
Vollständige Sicherung	Ja	Ja	Ja
Inkrementell / Differenziell	Logische Artefakte im Vollsicherungsstil (keine Oplog-Kette)	Echte oplog-basierte Kette	Wiederherstellung von Anwendungsdaten
Wiederherstellung zu einem bestimmten Zeitpunkt (PITR)	Nein	Ja – über „replay_to“	Nein
Oplog-Erfassung	Nein	Ja – inkrementelle und differentielle Jobs	Nein
Überprüfung der Kettenkontinuität	Nein	Ja – vor jeder Wiederherstellung	Nein
Erfassung von Routing-Metadaten	Nein	Nein	Ja – Shard-Zugehörigkeit und Routing-Konfiguration
Balancer Guardrail erforderlich	Nein	Nein	Ja (1) Der Balancer muss angehalten werden; (2) Chunk-Migrationen müssen deaktiviert sein; (3) Schreibvorgänge müssen für die Dauer des Dumps verhindert werden
Verbindungsziel	Primärer mongod	Schreibbarer Primärserver (Replica-Set-URI bevorzugt)	Nur mongos
Wiederherstellungsmethode	Vollständige logische Wiederherstellung über mongorestore	Validierte Kettenwiederholung über mongorestore	Anwendungswiederherstellung über mongos mit Routing-Vorbereitung

Wie schützt Bacula MongoDB-Backup-Daten vor Cyberbedrohungen?

Um Cyberkriminelle zu bekämpfen und Unternehmen vor Ransomware zu schützen, sichert Bacula Enterprise – auf das große Organisationen wie die NASA, die US-Marine und die US-Luftwaffe vertrauen – MongoDB-Backup-Daten durch direkte Integration mit WORM-konformen und unveränderlichen Speicherzielen. So wird verhindert, dass ein Angreifer, der über Zugangsdaten verfügt, Daten verändert, umbenennt oder – schlimmer noch – löscht, bis die konfigurierte Aufbewahrungsfrist abgelaufen ist.

Architektur und Zugriffskontrolle

Isolierte Fünf-Modul-Architektur – In der Fünf-Modul-Architektur von Bacula arbeiten der Datei-Daemon (Client), der Director, der Speicher-Daemon, die Konsole und die Katalogdatenbank als separate Komponenten. Diese Art der Trennung begrenzt den Ausbreitungsbereich einer kompromittierten Komponente, insbesondere in Kombination mit Netzwerksegmentierung, eindeutigen Anmeldedaten pro Komponente, gegenseitigem TLS und Zugriffskontrollen nach dem Prinzip der geringsten Berechtigungen.
Eingeschränkte Berechtigungen für den Datei-Daemon (Client) – Administratoren können über die Direktiven „AllowedBackupDirectories“, „AllowedRestoreDirectories“ und „AllowedScriptDirectories“ genau festlegen, aus welchen Verzeichnissen ein Client Backups erstellen, in welche er Wiederherstellungen durchführen und in welchen er Skripte ausführen darf. Der Datei-Daemon kann zudem im schreibgeschützten Modus ausgeführt werden, um unbefugte Änderungen von diesem System aus zu verhindern.
Rollenbasierte Zugriffskontrolle – Bacula unterstützt eine granulare rollenbasierte Zugriffskontrolle (RBAC) durch spezielle Zugriffskontrolllisten (ACLs), die präzise festlegen, was ein Konsolenbenutzer sehen und ändern darf. Diese Sicherheit wird über die Kontrollebenen „JobACL“, „CommandACL“, „PoolACL“ und „ScheduleACL“ durchgesetzt.
Multi-Faktor-Authentifizierung – Der Konsolenzugriff unterstützt TOTP-basierte MFA und entspricht RFC 6238, zusätzlich zur Standard-Passwort- und TLS-Authentifizierung. Der Zugriff über die Web-GUI unterstützt separat die Einmalpasswort-Authentifizierung, die auch biometrische Validierungsoptionen per Smartphone umfasst.

Unveränderlichkeit und Datenintegrität

Bacula-verwalteter Volumeschutz – Bacula legt bei dateibasierten Volumes während des ersten Sicherungslaufs das Attribut „Append-Only“ fest, um Datenverluste durch Überschreiben zu verhindern. Sobald ein Volume als „voll“ markiert ist, kann ein Unveränderlichkeits-Flag verhindern, dass es neu beschriftet oder wiederverwendet wird, bis seine Schutzfrist abgelaufen ist. Diese Kontrollen werden auf der Anwendungsebene durchgesetzt, und ihre Widerstandsfähigkeit gegenüber Angreifern hängt von den Betriebssystemrechten, der Dateisystemunterstützung, den Rechten des Storage-Daemons und der Konfiguration der Aufbewahrungsfristen ab.
Hardware- und Cloud-gestützte Unveränderlichkeit – Für eine Unveränderlichkeit, die selbst privilegiertem Zugriff auf Betriebssystemebene standhält, integriert Bacula gerätegesteuerte Unveränderlichkeit bei NetApp SnapLock, DataDomain RetentionLock und HPE StoreOnce sowie WORM im Compliance-Modus und Objektsperren bei AWS S3, Azure und Google Cloud Storage. Im Gegensatz zu Kontrollen auf Anwendungsebene werden diese auf Hardware- oder Cloud-Anbieter-Ebene durchgesetzt und können nicht durch Betriebssystem-Anmeldedaten außer Kraft gesetzt werden.
Jobüberprüfung und hashbasierte Integritätsprüfung – Bacula kann unbemerkte Beschädigungen erkennen, indem es SHA256- oder SHA512-Signaturen von Dateidaten berechnet und den aktuellen Zustand eines Volumes mit seinem Katalog-Eintrag vergleicht. Für eine adversarische Integritätsprüfung ist zu beachten, dass dieser Vergleich davon abhängt, dass der Katalog ebenso wie die Backup-Volumes unbeeinträchtigt bleibt.
Air-Gapped-Speicher – Bacula Enterprise arbeitet vollständig offline in vollständig isolierten Umgebungen ohne Abhängigkeit vom Internet. Der Director, die Speicher-Daemons und die Datei-Daemons können über getrennte Netzwerke verteilt werden, sodass MongoDB-Backup-Daten selbst im Falle einer Sicherheitsverletzung auf Netzwerkebene für externe Bedrohungen unzugänglich bleiben.

Verschlüsselung

Verschlüsselte Kommunikation – Bacula-Daemons authentifizieren sich mithilfe von SCRAM-SHA-256. In einer sicheren Umgebung sollte die TLS-Verschlüsselung für die gesamte Netzwerkkommunikation aktiviert sein; sie wird von allen Bacula-Komponenten unterstützt.
FIPS 140-3-Konformität – Bacula Enterprise unterstützt die FIPS 140-3-Konformität durch sein kryptografisches Modul, das OpenSSL-FIPS verwendet und plattformübergreifend zertifiziert ist. Das Modul kann plattformübergreifend in allen Bacula-Komponenten eingesetzt werden.
Verschlüsselung ruhender Daten – Der Speicher-Daemon kann ein gesamtes Speicherziel auf einmal verschlüsseln, unabhängig von der Datenquelle. Administratoren können die Verschlüsselung auch separat für einzelne Clients konfigurieren.

Erkennung von Bedrohungen

B Guardian Ransomware Detection – Baculas automatisiertes Sicherheitsanalysemodul „BGuardian“ überprüft die Konfigurationssicherheit, die Verwendung von Verschlüsselung, Muster für Backup-Poisoning und Dutzende weiterer Indikatoren für die Absicherung der gesamten Umgebung und erstellt Berichte sowie dauerhafte Warnmeldungen, sobald Probleme erkannt werden.
Malware- und Antiviren-Scans – Bacula bietet automatisierten Schutz vor Bedrohungen durch die Integration eines Antiviren-Plugins mit ClamAV, um gesicherte Dateien während der Verifizierungsaufträge nach der Sicherung auf Viren zu scannen.

Was bietet Ihnen die Bereitstellung von Bacula Enterprise?

Jede Bacula Enterprise-Bereitstellung bietet Ihnen die folgenden Funktionen in den Bereichen Wiederherstellung, Sicherung, Preisgestaltung und Plattformverwaltung.

Effiziente Backup-Funktionen

Adaptive Komprimierung – Die Komprimierungsalgorithmen sind pro Auftrag konfigurierbar, sodass Administratoren die Komprimierung je nach Datentyp und verfügbaren Ressourcen optimieren können.
Voll-, Differenz- und inkrementelle Backups – Bacula unterstützt die Backup-Stufen „Voll“, „Differenz“ und „Inkrementell“. Eine typische Strategie beginnt mit einem Voll-Backup, gefolgt von inkrementellen Backups, wodurch vermieden wird, dass wiederholt umfangreiche Voll-Backups nach einem festen Zeitplan durchgeführt werden müssen.
Progressive virtuelle Vollsicherungen – Bacula kann eine vorhandene Vollsicherung mit den darauf folgenden inkrementellen Sicherungen kombinieren, um eine neue synthetische Vollsicherung zu erstellen, ohne den Client erneut anzusprechen. Stattdessen liest der Prozess die Daten aus dem vorhandenen Sicherungsspeicher aus. Die Anweisung Backups To Keep kann diese Konsolidierung fortlaufend wiederholen.
Spooling auf Festplatte vor dem Schreiben auf Band – Bacula kann Sicherungsdaten zunächst in einen Festplattenspool schreiben, bevor sie als kontinuierlicher Datenstrom auf Band übertragen werden. Dies hilft, das ständige Anhalten und Starten des Bandlaufwerks zu vermeiden, das auftreten kann, wenn Daten zu langsam eintreffen, um das Laufwerk kontinuierlich schreiben zu lassen. Dieses Problem tritt besonders häufig bei inkrementellen und differentiellen Sicherungen auf, die tendenziell kleinere und weniger gleichmäßige Datenströme erzeugen als Vollsicherungen.
Bandbreitenbewusste Übertragungen – Nach der ersten Sicherung werden nur geänderte Daten über das Netzwerk übertragen. Dadurch bleibt der Netzwerkverkehr gering, ohne dass eine manuelle Bandbreitendrosselung oder Umgehungslösungen bei der Planung erforderlich sind.
Häufige Sicherungsplanung – Sicherungsaufträge können alle paar Minuten statt einmal täglich ausgeführt werden, wodurch sich das potenzielle Datenverlustfenster von Stunden auf Minuten verkürzt.
Kontinuierlicher Datenschutz – Die Anwendung cdp-client überwacht Dateien auf Änderungen und kopiert diese sofort in ein Spool-Verzeichnis. Der FileDaemon sendet diese Daten dann in festgelegten Intervallen an einen regulären Bacula-Sicherungsjob, sodass Änderungen innerhalb von Sekunden oder Minuten erfasst werden können, anstatt auf die nächste geplante Sicherung zu warten.

Ultraschnelle Wiederherstellungsfunktionen

Bare-Metal-Wiederherstellung auf Systemebene – Bacula Enterprise kann einen gesamten Server einschließlich Betriebssystem, Anwendungen, Konfiguration und Daten wiederherstellen, ohne dass zuvor eine manuelle Betriebssysteminstallation erforderlich ist.
Plattformübergreifende Datenwiederherstellung – Backup-Daten können auf einem anderen Betriebssystem als dem ursprünglichen wiederhergestellt werden. Dies bietet Teams mehr Flexibilität bei Hardware-Austausch, Migrationen oder anderen Wiederherstellungsszenarien.
Automatisierte Wiederherstellungsprüfung – Automatisierte Tests stellen sicher, dass die Sicherungsdaten wiederherstellbar sind, ohne dass ein Administrator einen separaten Validierungsprozess durchführen muss.
Geografische Backup-Replikation – Bacula behält standardmäßig eine einzige Backup-Kopie bei. Um zusätzliche Kopien an anderen Standorten zu erstellen, können Administratoren Kopier- oder Migrationsaufträge konfigurieren. Eine typische Konfiguration könnte darin bestehen, die Primärkopie auf lokalem Speicher zu behalten, eine zweite Kopie auf einem anderen Medientyp wie beispielsweise Cloud-Speicher zu erstellen und anschließend eine dritte Kopie an einen externen oder luftisolierten Standort zu senden. Diese Konfiguration trägt dazu bei, sicherzustellen, dass ein standortweiter Ausfall nicht alle verfügbaren Wiederherstellungskopien unzugänglich macht.

Kostenkontrolle und vorhersehbare Backup-Lizenzierung

Deduplizierung auf Blockebene – Doppelte Datenblöcke werden im gesamten Backup-Katalog nur einmal gespeichert, was den Speicherbedarf senkt, ohne dass Änderungen an Backup-Richtlinien oder -Zeitplänen erforderlich sind.
Workflows für mehrstufige Speicherung – Backup-Daten können je nach Alter automatisch zwischen verschiedenen Speicherebenen verschoben werden. Aktuelle Wiederherstellungspunkte können auf schnellerem Speicher verbleiben, während ältere Backups auf kostengünstigere Speicherorte verschoben werden.
Volumenunabhängige Lizenzierung – Die Lizenzkosten steigen nicht mit zunehmendem Datenvolumen. Teams können ihre Backup-Umgebung erweitern, ohne höhere Lizenzgebühren zahlen zu müssen.
Vorhersehbare Kosten – Feste Preise erleichtern die Planung von Infrastrukturbudgets, da keine variablen Lizenzgebühren an Speicherwachstum oder Änderungen der Arbeitslast gebunden sind.
Arbeitslastunabhängige Preisgestaltung – Die Größe von Datenbanken, die Anzahl der Server und die Menge des geschützten Speichers haben keinen Einfluss auf die Lizenzkosten.
Geringere Kosten bei Skalierung – Große oder schnell wachsende Umgebungen können geschützte Daten hinzufügen, ohne dass die Lizenzgebühren steigen. Im Vergleich zu kapazitätsbasierten Lizenzierungsmodellen können die Einsparungen mit zunehmendem Datenvolumen noch deutlicher ausfallen.

Backup-Management und -Administration

Doppelte Schnittstelle – BWeb bietet eine grafische Konsole für die tägliche Verwaltung und Überwachung von Jobs. Bconsole (User Agent) gewährt Betreibern vollständige Befehlszeilensteuerung für Skripterstellung, Automatisierung und erweiterte Konfiguration.
Grenzenlose Skalierbarkeit – Dieselbe Plattformarchitektur verwaltet Umgebungen von einer Handvoll Servern bis hin zu Tausenden von Servern – alles unter einer einzigen Verwaltungsebene.
Automatische Ressourcenerkennung – Die Plattform scannt die Infrastruktur, um Backup-Ziele automatisch zu identifizieren und zu katalogisieren. Der Schutzumfang bleibt auch bei wachsender Umgebung stets auf dem neuesten Stand.
Detaillierte Berichterstellung – Geplante Berichte erfassen in festgelegten Intervallen Job-Ergebnisse, Kapazitätstrends, den Compliance-Status und die Betriebsleistung.
Integration externer Systeme – Bacula lässt sich ohne zwingende kundenspezifische Entwicklungen mit Überwachungstools, IT-Ticketing-Systemen und Verzeichnisdiensten verbinden.

Häufig gestellte Fragen

Wie sichert man eine aktive MongoDB-Datenbank ohne Ausfallzeiten?

Bei Einzelservern und Replikatsätzen führt das Bacula Enterprise MongoDB-Plugin „mongodump“ auf einer aktiven Datenbank aus, ohne Lese- oder Schreibvorgänge zu unterbrechen, und die Datenbank bleibt während der gesamten Sicherungsaufträge voll funktionsfähig. Allerdings gilt die Ausfallfreiheitsgarantie nicht für Backups von Sharded-Clustern, da diese Backups Folgendes erfordern: (1) das Anhalten des Chunk-Balancers über `sh.stopBalancer()`, (2) das anschließende Deaktivieren geplanter Chunk-Migrationen und (3) das Verhindern von Schreibvorgängen und Schema-Transformationen für die Dauer des Dumps. Rechnen Sie damit, dass Schreibvorgänge während des Sicherungsfensters unterbrochen werden. Sichern Sie zuerst das Replika-Set des Konfigurationsservers und erfassen Sie anschließend jedes Shard-Replika-Set in möglichst kurz aufeinanderfolgenden Zeitabständen.

Was ist der Unterschied zwischen einer logischen und einer physischen Sicherung in MongoDB?

Eine logische Sicherung verwendet `mongodump`, um die Dokumente, Indizes und Schemata der Datenbank in portierbare BSON-Archivdateien zu exportieren. Diese Archive sind unabhängig von der zugrunde liegenden Speicher-Engine und können in der Regel auf einem anderen Server wiederhergestellt werden, wobei versionsübergreifende Wiederherstellungen von der Kompatibilität der MongoDB-Versionen, der Version der Datenbank-Tools und der Feature Compatibility Version (FCV) abhängen. Daher ist nicht bei jeder Kombination garantiert, dass sie funktioniert. Eine physische Sicherung hingegen kopiert die Rohdatendateien von der Festplatte, was bei sehr großen Datensätzen wesentlich schneller ist, das Archiv jedoch an die ursprüngliche Speicher-Engine und Version bindet.

Wie funktioniert die Point-in-Time-Wiederherstellung für MongoDB-Replikatsätze?

Die Point-in-Time-Wiederherstellung ist ausschließlich für Replikatsätze verfügbar. Wenn eine Wiederherstellung erforderlich ist, stoppt der Parameter `replay_to` die Oplog-Wiedergabe an einem beliebigen Punkt innerhalb des verfügbaren Oplog-Fensters und stellt den Replikatsatz auf den nächstgelegenen geschützten Zustand innerhalb dieses Fensters vor dem Auftreten eines Vorfalls wieder her. Standalone-Server und Sharded-Cluster unterstützen PITR über dieses Plugin nicht, da sie keine Oplog-Wiederherstellungskette in derselben Weise bereitstellen wie Replikatsätze. Wenn Sie eine bestimmte Sammlung auf einen bestimmten Zeitpunkt zurücksetzen müssen, empfiehlt es sich, zunächst die gesamte Replikatsatzkette auf einem Nicht-Produktionsziel wiederherzustellen und anschließend die erforderlichen Daten auf Anwendungsebene zu extrahieren und abzugleichen.

Kann man eine einzelne MongoDB-Sammlung wiederherstellen, ohne die gesamte Datenbank wiederherzustellen?

Ja. Das MongoDB-Plugin von Bacula unterstützt Ein- und Ausschlussfilter auf Datenbank- und Sammlungsebene, sodass ein Wiederherstellungsauftrag auf eine bestimmte Sammlung abzielen kann, ohne den Rest der Datenbank zu berühren. Dadurch bleiben die Wiederherstellungsfenster kurz und das Risiko wird minimiert, dass intakte Daten zusammen mit den beschädigten Daten, die ersetzt werden müssen, überschrieben werden. Eine vollständige Datenbankwiederherstellung ist bei Bedarf möglich, ist jedoch niemals die einzige Option.

Beachten Sie außerdem, dass die granulare Wiederherstellung auf Kollektionsebene für logische Voll-Artefakte gilt und nicht mit der Oplog-Wiedergabe kombiniert werden kann, was bedeutet, dass die Point-in-Time-Wiederherstellung stets im gesamten Umfang des Replikatsatzes erfolgt. Wenn Sie beides benötigen, stellen Sie sicher, dass Sie zunächst die gesamte Replikatsatzkette auf einem Nicht-Produktionsziel wiederherstellen und anschließend die benötigten Daten auf Anwendungsebene extrahieren.

Warum sollten Sie das Bacula-MongoDB-Plugin verwenden, anstatt „mongodump“ manuell auszuführen?

„mongodump“ allein ist ein leistungsfähiges Tool für einen einzelnen logischen Export. Allerdings hat es den Nachteil, dass es Ihnen nicht alle Funktionen bietet (zentralisierte Planung, automatisierte Aufbewahrung, Prüfsummenvalidierung, Metadaten der Wiederherstellungskette und vieles mehr), die nach dem Dump folgen. Das Bacula Enterprise MongoDB-Plugin bindet mongodump und mongorestore in die Policy-Engine von Bacula ein, sodass jeder MongoDB-Sicherungsauftrag ordnungsgemäß geplant, katalogisiert und validiert wird und über dieselbe Konsole wiederherstellbar ist, über die auch der Rest Ihrer Infrastruktur verwaltet wird.

Weitere Hilfe zum Thema MongoDB-Backup:

Suchen Sie nach Details zur Implementierung? Lesen Sie die vollständige MongoDB-Plugin-Dokumentation.
Sehen Sie sich die wichtigsten Funktionen der Backup- und Wiederherstellungssoftware von Bacula Enterprise an.
Verwenden Sie andere Datenbanken in Ihrer Infrastruktur? Bacula Enterprise bietet Lösungen für Oracle-, PostgreSQL-, MSSQL– und SAP-Datenbanken.
Sind Sie an Backups auf Bandmedien interessiert? Werfen Sie einen Blick auf unsere Band-Backup-Software.

MongoDB-Backup-Lösung der Enterprise-Klasse für groß angelegte Bereitstellungen

Durchführung von MongoDB-Sicherungen und detaillierten Wiederherstellungen über Server, Replikatsätze und Sharded-Cluster hinweg