TOC

So richten Sie geplante MongoDB-Sicherungen in DigitalOcean-Räumen ein

Einführung

Regelmäßige Datenbanksicherungen sind ein entscheidender Schritt zum Schutz vor unbeabsichtigten Datenverlustereignissen. Im Allgemeinen gibt es zwei große Kategorien von Sicherungen: Sicherungen auf Dateisystemebene ("physisch") und logische Sicherungen.

Bei Sicherungen auf Dateisystemebene wird zu einem bestimmten Zeitpunkt ein Snapshot der zugrunde liegenden Datendateien erstellt, und die Datenbank kann mithilfe des in den Snapshot-Dateien erfassten Status ordnungsgemäß wiederhergestellt werden. Sie tragen dazu bei, große Datenbanken schnell zu sichern, insbesondere wenn sie zusammen mit Snapshots des Dateisystems wieLVM snapshots oder Snapshots des Blockspeichervolumens wieDigitalOcean Block Storage Snapshots verwendet werden.

Bei logischen Sicherungen wird ein Tool verwendet (z. mongodump oderpg_dump) zum Exportieren von Daten aus der Datenbank in Sicherungsdateien, die dann unter Verwendung eines entsprechenden Wiederherstellungstools (z. mongorestore oderpg_restore). Sie bieten eine differenzierte Kontrolle darüber, welche Daten gesichert und wiederhergestellt werden sollen, und Sicherungen können häufig auf Datenbankversionen und -installationen übertragen werden. Da logische Sicherungstools alle Daten lesen, die im Speicher gesichert werden, können sie langsam sein und für besonders große Datenbanken eine nicht triviale zusätzliche Last verursachen.

Das Entwerfen einer wirksamen Sicherungs- und Wiederherstellungsstrategie umfasst häufig den Kompromiss zwischen Leistungseinbußen, Implementierungskosten und Datenspeicherkosten mit Wiederherstellungsgeschwindigkeit, Datenintegrität und Sicherungsumfang. Die optimale Lösung hängt von Ihrem Wiederherstellungspunkt und Ihrer Zeit inobjectivesowie von der Skalierung und Architektur der Datenbank ab.

In diesem Handbuch wird gezeigt, wie Sie eine MongoDB-Datenbank mitmongodump, einem integrierten logischen Sicherungstool, sichern. Anschließend zeigen wir, wie Sie die resultierenden serialisierten Datensicherungsdateien komprimieren und inDigitalOcean Spaces, einen hochredundanten Objektspeicher, hochladen. Wir zeigen auch, wie Sie den Sicherungs- und Upload-Vorgang regelmäßig mit Bash undcronplanen und schließlich mit einem Beispielszenario für die Datenwiederherstellung abschließen.

Am Ende dieses Lernprogramms haben Sie das Framework für eine erweiterbare automatisierte Sicherungsstrategie implementiert, mit der Sie bei Datenverlust in Ihrer Anwendung eine schnelle Wiederherstellung durchführen können. Bei kleineren bis mittelgroßen Datenbanken können Sie mit logischen Sicherungen mitmongodumpgenau steuern, welche Daten gesichert und wiederhergestellt werden sollen. Durch die Speicherung dieser komprimierten Backup-Archive in DigitalOcean Spaces wird sichergestellt, dass sie in einem dauerhaften Objektspeicher sofort verfügbar sind, sodass Ihre Anwendungsdaten geschützt sind und im Falle eines Datenverlusts schnell wiederhergestellt werden können.

[.note] #Note: Bei Verwendung des Toolsmongodump kann es zu Leistungseinbußen kommen, insbesondere bei hoch geladenen Datenbanken. Sie sollten dieses Verfahren zuerst mit einer Nichtproduktionsdatenbank mit simulierter Last testen, um zu überprüfen, ob diese Methode in Ihrer Produktionsbereitstellung funktioniert.
#

Voraussetzungen

Bevor Sie mit diesem Handbuch beginnen, stellen Sie sicher, dass folgende Voraussetzungen erfüllt sind:

Sobald Sie sich bei Ihrem Droplet angemeldet, MongoDB aktiviert und Ihren Space erstellt haben, können Sie loslegen.

[[Schritt-1 - Testdaten einfügen]] == Schritt 1 - Testdaten einfügen

Wenn Sie von einer sauberen MongoDB-Installation ausgehen und noch keine Daten gespeichert haben, sollten Sie zunächst einige Beispieldaten zu Testzwecken in die Sammlung eines Dummyrestaurantseinfügen. Wenn Sie bereits einige Sammlungen und Dokumente in Ihrer Datenbank gespeichert haben, können Sie diesen Schritt überspringen und mitStep 2 fortfahren.

Stellen Sie zunächst mit der MongoDB-Shell eine Verbindung zur laufenden Datenbank her: 

mongo

Sie sehen die folgende Mongo-Shell-Eingabeaufforderung: 

MongoDB shell version: 3.2.19
connecting to: test
Welcome to the MongoDB shell.
For interactive help, type "help".
For more comprehensive documentation, see
    http://docs.mongodb.org/
Questions? Try the support group
    http://groups.google.com/group/mongodb-user
Server has startup warnings:
2018-04-11T20:30:57.320+0000 I CONTROL  [initandlisten]
2018-04-11T20:30:57.320+0000 I CONTROL  [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/defrag is 'always'.
2018-04-11T20:30:57.320+0000 I CONTROL  [initandlisten] **        We suggest setting it to 'never'
2018-04-11T20:30:57.320+0000 I CONTROL  [initandlisten]
>

Standardmäßig stellt die Shell eine Verbindung zur Datenbanktesther.

Lassen Sie uns die in dertest-Datenbank vorhandenen Sammlungen auflisten: 

show collections

Da wir noch nichts in die Datenbank eingefügt haben, gibt es keine Sammlungen und wir werden ohne Ausgabe zur Eingabeaufforderung zurückgebracht.

Fügen Sie ein Dokument in die Sammlung eines Dummyrestaurantsein, das automatisch erstellt wird (da es noch nicht vorhanden ist): 

db.restaurants.insert({'name': 'Pizzeria Sammy'})

Sie sehen die folgende Ausgabe: 

OutputWriteResult({ "nInserted" : 1 })

Dies zeigt an, dass der Einfügevorgang erfolgreich war.

Lassen Sie uns noch einmal Sammlungen auflisten: 

show collections

Wir sehen jetzt unsere neu erstellterestaurants-Sammlung: 

Outputrestaurants

Drücken SieCTRL +D, um die MongoDB-Shell zu verlassen.

Nachdem wir einige Beispieldaten in der Datenbank gespeichert haben, können wir sie jetzt sichern.

[[Schritt-2 - Verwenden Sie Mongodump, um Mongodb-Daten zu sichern]] == Schritt 2 - Verwenden Siemongodump, um MongoDB-Daten zu sichern

Wir werden jetzt das integrierte Dienstprogrammmongodumpverwenden, um eine gesamte MongoDB-Datenbank in einer komprimierten Archivdatei zu sichern (oder zu "sichern").

Erstellen wir zunächst ein temporäres Verzeichnis mit dem Namenbackup, um das vonmongodump erstellte Archiv zu speichern: 

mkdir backup

Sichern wir nun dietest-Datenbank in dieser MongoDB-Instanz in einer komprimierten Archivdatei mit dem Namentest_dump.gz. Wenn Ihre Instanz andere Datenbanken enthält, können Sietest nach dem--db-Flag durch einen anderen Datenbanknamen ersetzen. Sie können auch das--db-Flag weglassen, umall-Datenbanken in Ihrer MongoDB-Instanz zu sichern.

[.note] #Note: Der folgende Befehl sollte vom Terminal undnot der Mongo-Shell ausgeführt werden.
# 

mongodump --db test --archive=./backup/test_dump.gz --gzip

Hier verwenden wir das Flag--archive, um anzugeben, dass alle Daten in einer einzelnen Archivdatei (deren Speicherort durch den Parameterarchive angegeben wird) und--gzip gespeichert werden sollen Flag, um anzugeben, dass wir diese Datei komprimieren möchten. Darüber hinaus können Sie optional die Flags--collection oder--query verwenden, um eine bestimmte Sammlung oder Abfrage zum Archivieren auszuwählen. Weitere Informationen zu diesen Flags finden Sie untermongodumpdocumentation.

Nach dem Ausführen des Befehls dump wird die folgende Ausgabe angezeigt: 

Output2018-04-13T16:29:32.191+0000    writing test.restaurants to archive './backup/test_dump.gz'
2018-04-13T16:29:32.192+0000    done dumping test.restaurants (1 document)

Dies zeigt an, dass unsere Testdaten erfolgreich gespeichert wurden.

Im nächsten Schritt laden wir dieses Sicherungsarchiv in den Objektspeicher hoch.

[[Schritt 3 - Laden des Backup-Archivs in Digitalocean-Spaces hoch]] == Schritt 3 - Laden Sie das Backup-Archiv in DigitalOcean Spaces hoch

Um dieses Archiv in unseren DigitalOcean Space hochzuladen, müssen wir das Tools3cmdverwenden, das wir inPrerequisitesinstalliert und konfiguriert haben.

Wir werden zuerst die Konfiguration vons3cmdtesten und versuchen, auf unseren Backup-Speicherplatz zuzugreifen. In diesem Tutorial verwenden wirmongo-backup-demo als Space-Namen. Geben Sie jedoch den tatsächlichen Namen Ihres Space ein: 

s3cmd info s3://mongo-backup-demo/

Sie sehen die folgende Ausgabe: 

Outputs3://mongo-backup-demo/ (bucket):
   Location:  nyc3
   Payer:     BucketOwner
   Expiration Rule: none
   Policy:    none
   CORS:      none
   ACL:       3587522: FULL_CONTROL

Dies zeigt an, dass die Verbindung erfolgreich war unds3cmd Objekte in den Space übertragen können.

Übertragen wir das in Schritt 2 erstellte Archiv mit dem Befehlput in unser Space: 

s3cmd put ./backup/test_dump.gz s3://mongo-backup-demo/

Es wird eine Ausgabe für die Dateiübertragung angezeigt: 

Outputupload: './backup/test_dump.gz' -> 's3://mongo-backup-demo/test_dump.gz'  [1 of 1]
 297 of 297   100% in    0s    25.28 kB/s  done

Sobald die Übertragung abgeschlossen ist, überprüfen wir, ob die Datei erfolgreich in unseren Space übertragen wurde, indem wir den Space-Inhalt auflisten: 

s3cmd ls s3://mongo-backup-demo/

Sie sollten die Backup-Archivdatei sehen: 

Output2018-04-13 20:39       297   s3://mongo-backup-demo/test_dump.gz

Zu diesem Zeitpunkt haben Sie die MongoDB-Datenbank vontesterfolgreich gesichert und das Sicherungsarchiv in Ihren DigitalOcean Space übertragen.

Im nächsten Abschnitt erfahren Sie, wie Sie das obige Verfahren mit Bash skripten, damit wir es mitcron planen können.

[[Schritt-4 - Erstellen und Testen eines Sicherungsskripts]] == Schritt 4 - Erstellen und Testen eines Sicherungsskripts

Nachdem wir unsere MongoDB-Datenbank in einer komprimierten Archivdatei gesichert und diese Datei in unseren Space übertragen haben, können wir diese manuellen Schritte in einem einzigen Bash-Skript kombinieren.

Sicherungsskript erstellen

Wir werden zuerst ein Skript schreiben, das die Befehlemongodump unds3cmd put kombiniert, und ein paar zusätzliche Schnickschnack hinzufügen, wie z. B. einige Protokollierungen (unter Verwendung von "Echo").

Öffnen Sie eine leere Datei in Ihrem bevorzugten Texteditor (hier verwenden wirnano): 

nano backup_mongo.sh

Fügen Sie die folgenden Codefragmente ein und achten Sie darauf, die relevanten Werte so zu aktualisieren, dass sie sich auf Ihren eigenen Space-, Datenbank- und Dateinamen beziehen. Wir nennen die Dateibackup_mongo.sh, aber Sie können diese Datei beliebig benennen. Das vollständige Skript finden Sie auch am Ende dieses Abschnitts.

Lass uns dieses Skript Stück für Stück durchgehen:

backup_mongo.sh

#!/bin/bash

set -e
...

Hier weist#!/bin/bash die Shell an, das Skript als Bash-Code zu interpretieren. set -e weist den Interpreter an, sofort zu beenden, wenn einer der Skriptbefehle fehlschlägt.

backup_mongo.sh

...

SPACE_NAME=mongo-backup-demo
BACKUP_NAME=$(date +%y%m%d_%H%M%S).gz
DB=test

...

In diesem Abschnitt legen wir drei Variablen fest, die wir später verwenden werden:

  • SPACE_NAME: Der Name des DigitalOcean-Bereichs, in den wir unsere Sicherungsdatei hochladen

  • BACKUP_NAME: Der Name des Sicherungsarchivs. Hier setzen wir es auf eine grundlegende Datum-Uhrzeit-Zeichenfolge.

  • DB: Gibt an, welche MongoDB-Datenbank das Skript sichern soll. Wenn Sie die gesamte MongoDB-Instanz (alle Datenbanken) sichern, wird diese Variable nicht verwendet.

backup_mongo.sh

...

date
echo "Backing up MongoDB database to DigitalOcean Space: $SPACE_NAME"

echo "Dumping MongoDB $DB database to compressed archive"
mongodump --db $DB --archive=$HOME/backup/tmp_dump.gz --gzip

echo "Copying compressed archive to DigitalOcean Space: $SPACE_NAME"
s3cmd put $HOME/backup/tmp_dump.gz s3://$SPACE_NAME/$BACKUP_NAME

...

Anschließend drucken wir Datum und Uhrzeit (zu Protokollierungszwecken) und beginnen die Sicherung, indem wir den oben getesteten Befehlmongodumpausführen. Wir speichern das Backup-Archiv erneut in~/backup/.

Als nächstes verwenden wirs3cmd, um dieses Archiv an den Speicherort zu kopieren, der durch diese beiden VariablenSPACE_NAME undBACKUP_NAME angegeben wird. Wenn unser Space-Name beispielsweisemongo-backup-demo lautet und das aktuelle Datum und die aktuelle Uhrzeit2018/04/12 12:42:21 sind, wird die Sicherung180412_124221.gz genannt und immongo-backup-demo-Space gespeichert .

backup_mongo.sh

...

echo "Cleaning up compressed archive"
rm $HOME/backup/tmp_dump.gz

echo 'Backup complete!'

Hier entfernen wir das Sicherungsarchiv aus dem Verzeichnis~/backup, da wir es erfolgreich in unseren Space kopiert haben. Die endgültige Ausgabe zeigt an, dass die Sicherung abgeschlossen ist.

Nach dem Kombinieren all dieser Codefragmente sollte das vollständige Skript folgendermaßen aussehen:

backup_mongo.sh

#!/bin/bash

set -e

SPACE_NAME=mongo-backup-demo
BACKUP_NAME=$(date +%y%m%d_%H%M%S).gz
DB=test

date
echo "Backing up MongoDB database to DigitalOcean Space: $SPACE_NAME"

echo "Dumping MongoDB $DB database to compressed archive"
mongodump --db $DB --archive=$HOME/backup/tmp_dump.gz --gzip

echo "Copying compressed archive to DigitalOcean Space: $SPACE_NAME"
s3cmd put $HOME/backup/tmp_dump.gz s3://$SPACE_NAME/$BACKUP_NAME

echo "Cleaning up compressed archive"
rm $HOME/backup/tmp_dump.gz

echo 'Backup complete!'

Speichern Sie diese Datei, wenn Sie fertig sind.

Als Nächstes testen wir dieses Skript, um zu überprüfen, ob alle Unterbefehle funktionieren.

Backup-Skript testen

Lassen Sie uns schnell das Skriptbackup_mongo.shausführen.

Machen Sie zuerst das Skript ausführbar: 

chmod +x backup_mongo.sh

Führen Sie nun das Skript aus: 

./backup_mongo.sh

Sie werden die folgende Ausgabe sehen: 

OutputMon Apr 16 22:20:26 UTC 2018
Backing up MongoDB database to DigitalOcean Space: mongo-backup-demo
Dumping MongoDB test database to compressed archive
2018-04-16T22:20:26.664+0000    writing test.restaurants to archive '/home/sammy/backup/tmp_dump.gz'
2018-04-16T22:20:26.671+0000    done dumping test.restaurants (1 document)
Copying compressed archive to DigitalOcean Space: mongo-backup-demo
upload: '/home/sammy/backup/tmp_dump.gz' -> 's3://mongo-backup-demo/180416_222026.gz'  [1 of 1]
 297 of 297   100% in    0s     3.47 kB/s  done
Cleaning up compressed archive
Backup complete!

Wir haben erfolgreich ein Backup-Shell-Skript erstellt und können es nun mitcron planen.

[[Schritt-5 - Planen Sie tägliche Backups mit Cron]] == Schritt 5 - Planen Sie tägliche Backups mit Cron

Um eine nächtliche Ausführung des Sicherungsskripts zu planen, verwenden wircron, ein Dienstprogramm zur Jobplanung, das in Unix-ähnliche Betriebssysteme integriert ist.

Zunächst erstellen wir ein Verzeichnis zum Speichern der Protokolle für unser Sicherungsskript. Als Nächstes fügen wir das Sicherungsskript zur Konfigurationsdatei von crontab (cron) hinzu, damitcron die nächtliche Ausführung plant. Dacron jede reguläre Häufigkeit unterstützt, können Sie optional wöchentliche oder monatliche Sicherungen planen.

Protokollierungsverzeichnis erstellen

Erstellen wir ein Verzeichnis zum Speichern Ihrer Sicherungsskript-Protokolldateien. Mit diesen Protokollen können wir das Sicherungsskript regelmäßig überprüfen, um sicherzustellen, dass alles in Ordnung ist, und das Debuggen durchführen, falls ein Befehl fehlschlägt.

Erstellen Sie ein Unterverzeichnismongo_backup in/var/log (gemäß der für die Protokollierung verwendeten Konvention): 

sudo mkdir /var/log/mongo_backup

Machen Sie dieses Verzeichnis nun für unseren Unix-Benutzer beschreibbar. In diesem Fall lautet der Name unseres Benutzerssammy. Sie sollten jedoch den entsprechenden Nicht-Root-Benutzernamen mit Sudo-Berechtigungen für Ihren Server verwenden. 

sudo chown sammy:sammy /var/log/mongo_backup

Unser Unix-Benutzersammy kann jetzt in/var/log/mongo_backup schreiben. Da der Cronjob alssammy ausgeführt wird, kann er jetzt seine Protokolldateien in dieses Verzeichnis schreiben.

Lassen Sie uns den geplanten Cronjob erstellen.

Cronjob erstellen

Um den Cronjob zu erstellen, bearbeiten wir die Datei mit der Liste der geplanten Jobs, die als "Crontab" bezeichnet wird. Beachten Sie, dass es mehrere Crontabs gibt, eine pro Benutzer, und eine systemweite Crontab bei/etc/crontab. In diesem Tutorial führen wir das Sicherungsskript als Benutzersammyaus. Abhängig von Ihrem Anwendungsfall können Sie ihn auf der systemweiten Crontab ausführen.

Öffnen Sie die Crontab zum Bearbeiten: 

crontab -e

Sie sehen das folgende Menü, in dem Sie Ihren bevorzugten Texteditor auswählen können: 

Outputno crontab for sammy - using an empty one

Select an editor.  To change later, run 'select-editor'.
  1. /bin/ed
  2. /bin/nano        <---- easiest
  3. /usr/bin/vim.basic
  4. /usr/bin/vim.tiny

Choose 1-4 [2]: no crontab for sammy - using an empty one

Wählen Sie Ihren bevorzugten Editor aus. Umnano zu wählen, geben Sie2 ein. Fügen Sie nun die folgende Zeile an die Datei an, und folgen Sie dabei dem auskommentierten Abschnitt:

crontab -e 

# For more information see the manual pages of crontab(5) and cron(8)
#
# m h  dom mon dow   command

0 2 * * * /home/sammy/mongo_backup.sh >>/var/log/mongo_backup/mongo_backup.log 2>&1

Stellen Sie sicher, dass Sie am Ende der Crontab einen nachgestellten Zeilenumbruch einfügen. Speichern und schließen Sie die Datei.

Sie sehen die folgende Ausgabe: 

Outputno crontab for sammy - using an empty one
crontab: installing new crontab

Das Sicherungsskript wird jetzt jeden Morgen um 2:00 Uhr ausgeführt. Sowohlstdout als auchstderr (die Ausgabe- und Fehlerströme) werden weitergeleitet und an eine Protokolldatei mit dem Namenmongo_backup.log in dem zuvor erstellten Protokollverzeichnis angehängt.

Sie können0 2 * * * (jede Nacht um 2:00 Uhr in Cron-Syntax ausführen) auf die gewünschte Sicherungshäufigkeit und -zeit ändern. Weitere Informationen zu cron und seiner Syntax finden Sie in unserem Tutorial zuHow To Use Cron To Automate Tasks On A VPS.

Wir schließen dieses Lernprogramm mit einer kurzen Wiederherstellungsübung ab, um sicherzustellen, dass unsere Sicherungen funktionsfähig sind.

[[Schritt-6 - Durchführen einer Testwiederherstellung]] == Schritt 6 - Führen Sie eine Testwiederherstellung durch

Jede Sicherungsstrategie sollte ein Wiederherstellungsverfahren enthalten, das routinemäßig getestet wird. Hier testen wir schnell eine Wiederherstellung aus der komprimierten Sicherungsdatei, die wir in DigitalOcean-Bereiche hochgeladen haben.

Zuerst laden wirtest_dump.gz von unserem Space in das Home-Verzeichnis in unserem MongoDB-Droplet herunter: 

s3cmd get s3://mongo-backup-demo/test_dump.gz

Sie werden die folgende Ausgabe sehen: 

Outputdownload: 's3://mongo-backup-demo/test_dump.gz' -> './test_dump.gz'  [1 of 1]
 297 of 297   100% in    0s  1305.79 B/s  done

Wenn Sie dieses Lernprogramm mit einer neuen MongoDB-Instanz begonnen haben, werden Sie sich daran erinnern, dass sie nur dietest-Datenbank enthielt, die wiederum die einzige Datenbank war, die wir gesichert haben.

Zu Demonstrationszwecken löschen wir jetzt diese Testdatenbank, damit wir eine saubere Wiederherstellung durchführen können. Wenn wir diesen ersten Schritt nicht ausführen, werden beim Wiederherstellen die Originaldokumente gefunden, die übersprungen werden. In Ihrem speziellen Anwendungsfall ist es möglicherweise akzeptabel, nur neue Dokumente wiederherzustellen. Für die Zwecke dieses Lernprogramms möchten wir jedoch eine vollständige Wiederherstellung in einer leeren Datenbank explizit testen.

Stellen Sie mithilfe dermongo-Shell eine Verbindung zu Ihrer MongoDB-Instanz her: 

mongo

Jetzt istusedietest-Datenbank und löscht sie aus der MongoDB-Instanz: 

use test
db.dropDatabase()

Die folgende Ausgabe bestätigt den Rückgang vontest: 

Output{ "dropped" : "test", "ok" : 1 }

Beenden Sie nun die Shell vonmongo und führen Sie den Befehlmongorestore aus: 

mongorestore --gzip --archive=test_dump.gz --db test

Hier geben wir an, dass die Quellensicherungsdatei komprimiert und in Form einer Archivdatei vorliegt (denken Sie daran, dass wir beim Aufrufen vonmongodump die Flags--archive und--gzip verwendet haben) und dass wir dies tun würden möchte in dertest Datenbank wiederherstellen.

Sie werden die folgende Ausgabe sehen: 

Output2018-04-16T23:10:07.317+0000    creating intents for archive
2018-04-16T23:10:07.453+0000    reading metadata for test.restaurants from archive 'test_dump.gz'
2018-04-16T23:10:07.497+0000    restoring test.restaurants from archive 'test_dump.gz'
2018-04-16T23:10:07.541+0000    restoring indexes for collection test.restaurants from metadata
2018-04-16T23:10:07.541+0000    finished restoring test.restaurants (1 document)
2018-04-16T23:10:07.541+0000    done

Dies zeigt an, dass die Wiederherstellung vontesterfolgreich war.

Lassen Sie uns abschließend bestätigen, dass unsere ursprünglichenrestaurants-Daten erfolgreich wiederhergestellt wurden.

Öffnen Sie die MongoDB-Shell und fragen Sie dierestaurants-Sammlung ab: 

db.restaurants.find()

Sie sollten das Objekt sehen, das wir im ersten Schritt dieses Tutorials gespeichert haben: 

Output{ "_id" : ObjectId("5ace7614dbdf8137afe60025"), "name" : "Pizzeria Sammy" }

Sie haben diese MongoDB-Sicherungsstrategie jetzt erfolgreich implementiert und getestet.

Fazit

In diesem Tutorial haben wir gelernt, wie Sie eine Strategie für nächtliche logische MongoDB-Sicherungen implementieren und testen.

Dieser Leitfaden kann auf viele Arten erweitert oder geändert werden. Hier sind einige schnelle Vorschläge:

  • Abhängig von Ihren Wiederherstellungspunktzielen (RPOs) können Sie die vorgeschlagene Sicherungshäufigkeit erhöhen oder verringern, um sie an Ihr Datenwiederherstellungsfenster anzupassen.

  • Eine weitere hilfreiche Ergänzung wäre eine Warnfunktion, die ausgelöst wird, wenn ein Backup-Skript-Unterbefehl fehlschlägt (z. Diese Funktion kann eine E-Mail an einen regelmäßig überwachten Alert-Posteingang senden.

  • Dieses Skript behandelt das Löschen von Spaces-Objekten nicht. Möglicherweise möchten Sie Backups bereinigen, die älter als etwa 6 Monate sind.

  • Abhängig von Ihrem Anwendungsfall in der Produktion möchten Sie möglicherweise komplexerebackup rotation scheme implementieren.

Da bei der Prozedur vonmongodumpalle gespeicherten Daten schnell durchgelesen werden müssen, eignet sich diese Sicherungsmethode am besten für kleine bis mittlere Datenbanken, insbesondere für Teilsicherungen wie eine bestimmte Sammlung oder Ergebnismenge. Für größere Bereitstellungen werden Sicherungen auf Dateisystemebene empfohlen. Weitere Informationen zu MongoDB-Sicherungen auf Dateisystemebene finden Sie in diesem Lernprogramm zuHow To Back Up MongoDB Using Droplet Snapshots. Weitere Informationen zu verschiedenen Methoden zum Sichern einer MongoDB-Datenbank finden Sie inMongoDB manual.

Die in diesem Lernprogramm vorgestellte Lösung nutztmongodump für die detaillierte Steuerung der Abdeckung von Sicherungsdaten und DigitalOcean Spaces für eine kostengünstige und dauerhafte Langzeitdatenspeicherung. Weitere Informationen zum Sicherungsdienstprogramm vonmongodumpfinden Sie inreference pageim MongoDB-Handbuch. Um mehr über DigitalOcean Spaces zu erfahren, können SieAn Introduction To DigitalOcean Spaces lesen.

Related