So sichern Sie einen MongoDB-Docker-Container (2026)
MongoDB sicher zu sichern heißt eine Regel befolgen: dumpen, nicht kopieren. `mongodump --archive --oplog` erzeugt einen konsistenten, wiederherstellbaren Dump aus dem laufenden Container, den restic anschließend verschlüsselt off-site ablegt. --oplog zeichnet die Operationen während des Dumps auf, sodass mongorestore --oplogReplay einen zeitpunktkonsistenten Schnappschuss rekonstruieren kann. Alles, was /data/db im laufenden Betrieb kopiert, riskiert ein nicht wiederherstellbares Backup.
Was Dockstash erkennt
| Erkannte Env-Keys | MONGO_INITDB_ROOT_USERNAME, MONGO_INITDB_ROOT_PASSWORD, MONGO_INITDB_DATABASE |
|---|---|
| Standard-Port | 27017 |
| Live-Datenpfade (nie im Betrieb kopiert) | /data/db |
| Beispiel-Images | mongo:7, mongo:6, mongo:5, mongo |
MongoDB mit Dockstash sichern, Schritt für Schritt
Dockstash-Konto anlegen und das Dashboard öffnen
Registrieren Sie sich kostenlos auf app.dockstash.com/register. Der einmalige Einrichtungsassistent fragt nach Ihrem Storage-VPS (der Maschine, die die verschlüsselten Backups aufnimmt) und generiert ein Verschlüsselungspasswort — speichern Sie es sofort in einem Passwort-Manager, es wird genau einmal angezeigt.
Das Docker-Projekt mit MongoDB hinzufügen
Auf dem Projects-Bildschirm erkennt Dockstash automatisch jeden Compose-Projektordner des Servers (standardmäßig unter /var/www). Wählen Sie das Projekt mit Ihrem MongoDB-Service. Noch wird nichts gesichert — Sie sagen Dockstash nur, wo das Projekt liegt.
Prüfen, dass MongoDB erkannt wurde
Öffnen Sie das Projekt und schauen Sie auf den Plan-Tab. Dockstash liest docker-compose.yml, erkennt das mongo-Image und fügt eine Datenbank-Ebene mit dem richtigen Dump-Befehl hinzu — samt aufgelöstem Containernamen und den gefundenen Env-Keys (MONGO_INITDB_ROOT_USERNAME, MONGO_INITDB_ROOT_PASSWORD, MONGO_INITDB_DATABASE). Dateien, Datenbanken und Proxy-Configs lassen sich vor dem Speichern ein- oder ausschalten.
Optional: den Dump von Hand gegenprüfen
Wenn Sie vor der Automatisierung einen Beweis wollen, führen Sie denselben Dump aus, den Dockstash ausführen wird — mongodump schreibt ein einzelnes Archiv nach stdout, umgeleitet in einen Byte-Zähler. Eine große Byte-Zahl ungleich null beweist, dass das Archiv sauber strömt. Genau dieses Archiv wird gesichert, niemals das laufende Verzeichnis /data/db.
docker exec <mongo-container> sh -c 'mongodump --archive --oplog' | wc -cSpeicherziel bestätigen
Backups liegen als verschlüsselte restic-Snapshots auf Ihrem eigenen Storage-VPS, übertragen per SSH. Haben Sie den Assistenten abgeschlossen, ist das bereits konfiguriert; Host, Benutzer, Port oder SSH-Key ändern Sie jederzeit unter Settings → Storage.
Backup-Zeitplan festlegen
Wählen Sie im Schedule-Tab des Projekts täglich, wöchentlich oder einen eigenen Cron-Ausdruck (inline validiert). Täglich zu einer ruhigen Stunde ist für die meisten MongoDB-Projekte der richtige Standard. Ergänzen Sie einen wöchentlichen Prune-Zeitplan mit Ihrer Aufbewahrungsrichtlinie.
Das erste Backup jetzt ausführen
Klicken Sie auf Backup Now auf der Projektkarte. Dockstash führt mongodump mit --archive und --oplog im laufenden Container aus und streamt das Archiv direkt in restic — die Live-Ausgabe verfolgen Sie Zeile für Zeile im Log-Panel.
Snapshot bestätigen
Nach dem Lauf zeigt die Projektkarte die neue letzte Backup-Zeit, die Snapshot-Anzahl und die Repository-Größe. Öffnen Sie den Snapshots-Bildschirm: Der Wiederherstellungspunkt erscheint in der Zeitleiste — Ihr Beweis, dass das Backup off-site angekommen ist.
Der Dump-Befehl
mongodump --archive --oplogDer Restore-Befehl
mongorestore --archive --oplogReplay --drop--oplog zeichnet die Operationen während des Dumps auf, sodass mongorestore --oplogReplay einen zeitpunktkonsistenten Schnappschuss rekonstruieren kann.
Ein MongoDB-Backup wiederherstellen und beweisen, dass es funktioniert
Ein MongoDB-Backup wird erst real, wenn es wiederhergestellt wurde. Dockstash-Restores überschreiben Ihre Live-Datenbank standardmäßig nie — Sie stellen zuerst an einen frischen Staging-Ort wieder her, spielen dort das Archiv ein, prüfen die Daten und befördern sie bewusst.
Wiederherstellungspunkt wählen
Öffnen Sie Snapshots, wählen Sie das Projekt und durchstöbern Sie die Zeitleiste. Jede Zeile ist ein vollständiges mongodump-Archiv — alle Datenbanken und Collections plus die während des Dumps erfassten Oplog-Einträge — zusammen mit den Projektdateien desselben Laufs.
An einen neuen Ort wiederherstellen
Klicken Sie auf Restore und behalten Sie den Standardmodus „Restore to new location". Tippen Sie den Projektnamen zur Bestätigung. Archiv und Dateien landen im gewählten Zielpfad; spielen Sie das Archiv mit mongorestore samt --oplogReplay und --drop in einem Staging-Container ein — das Live-Projekt bleibt unberührt.
Wiederhergestellte Daten prüfen
Listen Sie im Testcontainer die Datenbanken mit mongosh auf, bestätigen Sie, dass jede zurück ist, und prüfen Sie stichprobenartig die Collections Ihrer App. Dokumentzahlen und jüngste Datensätze sind der schnellste Wahrheitstest.
docker exec <mongo-container> mongosh --quiet --eval "db.adminCommand({ listDatabases: 1 })"Bei Erfolg befördern
Wenn die wiederhergestellten Daten stimmen, richten Sie Ihre App darauf aus (oder wiederholen den Restore mit „Overwrite existing" — ein expliziter Opt-in). Besser: Lassen Sie den wöchentlichen Restore-Drill diesen Beweis automatisch erbringen.
Stolperfallen vermeiden
- Führen Sie restic nie auf den laufenden WiredTiger-Dateien in /data/db aus — mitten im Checkpoint kopiert sind sie inkonsistent und oft nicht mehr zu retten.
- --oplog verlangt ein Replica-Set-Mitglied (auch ein Ein-Knoten-Set); auf einem Standalone-mongod ist es ein No-op ohne Zeitpunkt-Garantie.
- Beim Restore muss --oplogReplay die --oplog-Dumps begleiten, sonst geht die Zeitpunkt-Konsistenz verloren.
Häufige MongoDB-Backup-Probleme
- Symptom
- Der Dump scheitert mit „--oplog mode only supported on replica set members" (oder ähnlich).
- Ursache
- Ihr mongod läuft standalone. --oplog braucht einen Oplog zum Lesen, und nur Replica-Set-Mitglieder führen einen — auf einem Standalone-Server gibt es nichts zu erfassen.
- Lösung
- Wandeln Sie in ein Ein-Knoten-Replica-Set um: mongod mit --replSet rs0 starten und einmal rs.initiate() ausführen. Gleicher Container, gleiche Daten — plus Zeitpunkt-Garantie.
- Symptom
- mongodump scheitert mit „Authentication failed", obwohl Compose MONGO_INITDB_ROOT_USERNAME setzt.
- Ursache
- Die MONGO_INITDB_*-Variablen legen den Benutzer nur bei der Erstinitialisierung eines leeren /data/db-Volumes an. Existierte das Volume bereits oder wurden die Zugangsdaten später geändert, stimmen die Compose-Werte nicht mehr.
- Lösung
- Authentifizieren Sie sich mit den tatsächlich in der Datenbank vorhandenen Zugangsdaten (mit mongosh prüfen) oder legen Sie den Benutzer neu an, und richten Sie dann die Compose-Env aus.
- Symptom
- mongorestore in einen Testcontainer scheitert mit einem Versions- oder Archivfehler.
- Ursache
- Das Archiv stammt von einem neueren Server oder mongodump, als das Restore-Ziel versteht — ein mongo:7-Archiv in mongo:5 wiederherzustellen ist nicht unterstützt.
- Lösung
- Stellen Sie in dieselbe Hauptversion wieder her (z. B. mongo:7) und halten Sie mongodump/mongorestore auf demselben Database-Tools-Release. Versionsupgrades macht der Server nach dem Restore, nicht mongorestore.
- Symptom
- Ein Backup-Lauf scheitert nach Crash oder Neustart an einem veralteten restic-Lock.
- Ursache
- Ein früherer Job starb mitten im Lauf und hinterließ das Repository gesperrt.
- Lösung
- Nichts manuell zu tun: Der nächste Lauf erkennt den verwaisten Lock und führt automatisch restic unlock aus. Scheitern Läufe weiterhin, prüfen Sie das Live-Log-Panel.
Mit Dockstash in einem Klick
Dockstash führt exakt den obigen Dump aus, übergibt ihn off-site an restic und drill-testet den Restore automatisch — kein Skript zu pflegen.
Zuletzt aktualisiert: July 2026
Häufig gestellte Fragen
Was macht --oplog eigentlich?
Es zeichnet die Operations-Log-Einträge auf, die während des mongodump-Laufs anfallen, und legt sie im Archiv ab. Beim Restore wendet --oplogReplay sie an, sodass der Dump einen einzigen konsistenten Zeitpunkt widerspiegelt statt einer Verschmierung über das Dump-Fenster.
Brauche ich ein Replica Set für konsistente Backups?
Für Zeitpunkt-Konsistenz ja — --oplog funktioniert nur auf einem Replica-Set-Mitglied. Viele Ein-Knoten-Deployments laufen genau deshalb als Ein-Mitglied-Replica-Set.
Warum nicht /data/db direkt kopieren?
WiredTiger schreibt kontinuierlich Checkpoints. Eine Datei-Kopie mitten im Checkpoint erfasst einen inkonsistenten Zustand, der häufig nicht startet. mongodump liest einen logischen, wiederherstellbaren Schnappschuss.
Wie stelle ich in eine saubere Datenbank wieder her?
mongorestore --archive --oplogReplay --drop löscht bestehende Collections vor dem Restore, damit sich alte und neue Daten nicht mischen. Dockstash stellt standardmäßig zuerst in ein Staging-Ziel wieder her.
Wie oft sollte ich MongoDB sichern?
Täglich ist der praktikable Standard; stündlich, wenn der Verlust eines Tages an Schreibzugriffen inakzeptabel ist. Im Free-Tarif sind Backups nur manuell; Pro erlaubt Zeitpläne bis stündlich, Business jeden Cron. Kombinieren Sie den Zeitplan mit einem wöchentlichen Restore-Drill.
Wo liegen die Backups eigentlich?
Auf Ihrem eigenen Storage-VPS, als verschlüsselte restic-Snapshots per SSH übertragen. Dockstash hält Ihre Daten nie in einer Dritt-Cloud — Sie zeigen auf eine Maschine unter Ihrer Kontrolle, und das Repository ist mit einem Passwort verschlüsselt, das nur Sie besitzen.
Woher weiß ich ohne manuellen Restore, dass das Backup wiederherstellbar ist?
Planen Sie einen Restore-Drill. Dockstash stellt den neuesten Snapshot in einen isolierten Arbeitsbereich wieder her, vergleicht jede Datei byteweise mit der Quelle und prüft den Dump — dann stempelt es ein Bestanden/Fehlgeschlagen-Badge aufs Projekt. Ein wöchentlicher Drill heißt: immer frischer Beweis.