TOC

Comment configurer des sauvegardes MongoDB planifiées sur des espaces DigitalOcean

introduction

Les sauvegardes régulières de la base de données sont une étape cruciale de la protection contre les événements non intentionnels de perte de données. En général, il existe deux grandes catégories de sauvegardes: les sauvegardes au niveau du système de fichiers («physiques») et les sauvegardes logiques.

Les sauvegardes au niveau du système de fichiers impliquent la capture instantanée des fichiers de données sous-jacents à un moment donné, permettant ainsi à la base de données de récupérer de manière nette en utilisant l'état capturé dans les fichiers instantanés. Ils contribuent à la sauvegarde rapide de bases de données volumineuses, en particulier lorsqu'ils sont utilisés en tandem avec des instantanés de système de fichiers, tels queLVM snapshots, ou des instantanés de volume de stockage en bloc, tels queDigitalOcean Block Storage Snapshots.

Les sauvegardes logiques impliquent l’utilisation d’un outil (par exemple, mongodump oupg_dump) pour exporter les données de la base de données dans des fichiers de sauvegarde, qui sont ensuite restaurés à l'aide d'un outil de restauration correspondant (par ex. mongorestore oupg_restore). Ils offrent un contrôle granulaire sur les données à sauvegarder et à restaurer. Les sauvegardes sont souvent portables entre les versions et les installations de base de données. Comme les outils de sauvegarde logiques lisent toutes les données sauvegardées en mémoire, ils peuvent être lents et entraîner une charge supplémentaire non triviale pour des bases de données particulièrement volumineuses.

Concevoir une stratégie de sauvegarde et de restauration efficace implique souvent un compromis entre impact sur les performances, coûts de mise en œuvre et de stockage des données, avec vitesse de restauration, intégrité des données et couverture de sauvegarde. La solution optimale dépendra de votre point de récupération et du tempsobjectives et de l'échelle et de l'architecture de la base de données.

Dans ce guide, nous allons montrer comment sauvegarder une base de données MongoDB à l'aide demongodump, un outil de sauvegarde logique intégré. Nous montrerons ensuite comment compresser et télécharger les fichiers de sauvegarde de données sérialisés résultants dansDigitalOcean Spaces, un magasin d'objets hautement redondant. Nous allons également montrer comment planifier régulièrement l'opération de sauvegarde et de téléchargement à l'aide de Bash et decron, et enfin conclure avec un exemple de scénario de récupération de données.

À la fin de ce didacticiel, vous aurez implémenté le cadre d’une stratégie de sauvegarde automatisée extensible qui vous permettra de récupérer rapidement si votre application devait subir une perte de données. Pour les bases de données de taille petite à moyenne, les sauvegardes logiques utilisantmongodump vous offrent un contrôle précis sur les données à sauvegarder et à restaurer. Le stockage de ces archives de sauvegarde compressées dans DigitalOcean Spaces garantit leur disponibilité immédiate dans un magasin d'objets durables, de sorte que les données de votre application soient protégées et rapidement récupérables en cas d'événement de perte de données.

[.note] #Note: Il peut y avoir un impact sur les performances lors de l'utilisation de l'outilmongodump, en particulier sur les bases de données très chargées. Vous devez d'abord tester cette procédure en utilisant une base de données hors production avec une charge simulée pour vérifier que cette méthode fonctionnera dans votre déploiement de production.
#

Conditions préalables

Avant de commencer avec ce guide, assurez-vous de disposer des conditions préalables suivantes:

Une fois que vous êtes connecté à votre Droplet, que MongoDB est opérationnel et que votre espace est créé, vous êtes prêt à commencer.

[[step-1 -—- insert-test-data]] == Étape 1 - Insérer les données de test

Si vous partez d'une nouvelle installation de MongoDB et que vous n'avez pas encore stocké de données, vous devez d'abord insérer des exemples de données dans une collection facticerestaurants à des fins de test. Si vous avez déjà des collections et des documents stockés dans votre base de données, n'hésitez pas à ignorer cette étape et à passer àStep 2.

Commencez par vous connecter à la base de données en cours d’exécution à l’aide du shell MongoDB: 

mongo

L’invite suivante du shell Mongo s’affiche: 

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]
>

Par défaut, le shell se connecte à la base de donnéestest.

Listons les collections présentes dans la base de donnéestest: 

show collections

Comme nous n’avons encore rien inséré dans la base de données, il n’existe aucune collection et nous sommes ramenés à l’invite sans sortie.

Insérons un document dans une collection facticerestaurants, qui sera automatiquement créée (car elle n’existe pas encore): 

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

Vous verrez le résultat suivant: 

OutputWriteResult({ "nInserted" : 1 })

Cela indique que l'opération d'insertion a réussi.

Reprenons la liste des collections: 

show collections

Nous voyons maintenant notre nouvelle collectionrestaurants: 

Outputrestaurants

Pour quitter le shell MongoDB, appuyez surCTRL +D.

Maintenant que nous avons stocké des exemples de données dans la base de données, nous sommes prêts à les sauvegarder.

[[step-2 -—- use-mongodump-to-back-up-mongodb-data]] == Étape 2 - Utilisezmongodump pour sauvegarder les données MongoDB

Nous allons maintenant utiliser l'utilitaire intégrémongodump pour sauvegarder (ou «vider») une base de données MongoDB entière dans un fichier d'archive compressé.

Commençons par créer un répertoire temporaire appelébackup pour stocker l’archive créée parmongodump: 

mkdir backup

Maintenant, sauvegardons la base de donnéestest de cette instance MongoDB dans un fichier d'archive compressé appelétest_dump.gz. Si votre instance contient d'autres bases de données, vous pouvez remplacertest par un autre nom de base de données après l'indicateur--db. Vous pouvez également omettre l'indicateur--db pour sauvegarder les bases de donnéesall dans votre instance MongoDB.

[.note] #Note: La commande suivante doit être exécutée depuis le terminal etnot le shell Mongo.
# 

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

Ici, nous utilisons l'indicateur--archive pour spécifier que nous souhaitons enregistrer toutes les données dans un seul fichier d'archive (dont l'emplacement est spécifié par le paramètrearchive), et les--gzip flag pour spécifier que nous souhaitons compresser ce fichier. De plus, vous pouvez éventuellement utiliser les indicateurs--collection ou--query pour sélectionner une collection ou une requête donnée à archiver. Pour en savoir plus sur ces indicateurs, consultez lesmongodumpdocumentation.

Après avoir exécuté la commande dump, vous verrez la sortie suivante: 

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)

Cela indique que nos données de test ont été vidées avec succès.

Dans l'étape suivante, nous allons télécharger cette archive de sauvegarde sur le stockage d'objets.

[[step-3 -—- upload-the-backup-archive-to-digitalocean-spaces]] == Étape 3 - Téléchargement de l'archive de sauvegarde vers DigitalOcean Spaces

Pour télécharger cette archive dans notre espace DigitalOcean, nous devrons utiliser l'outils3cmd, que nous avons installé et configuré dans lePrerequisites.

Nous allons d'abord tester notre configuration des3cmd et tenter d'accéder à notre espace de sauvegarde. Dans ce didacticiel, nous utiliseronsmongo-backup-demo comme nom d'espace, mais vous devez renseigner le nom réel de votre espace: 

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

Vous verrez le résultat suivant: 

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

Ce qui indique que la connexion a réussi et ques3cmd peut transférer des objets vers l'espace.

Transférons l'archive que nous avons créée à l'étape 2 vers notre espace à l'aide de la commandeput: 

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

Vous verrez une sortie de transfert de fichier: 

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

Une fois le transfert terminé, nous vérifierons que le fichier a bien été transféré dans notre espace en répertoriant son contenu: 

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

Vous devriez voir le fichier d’archive de sauvegarde: 

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

À ce stade, vous avez réussi à sauvegarder la base de données MongoDB detest et à transférer l'archive de sauvegarde sur votre espace DigitalOcean.

Dans la section suivante, nous verrons comment écrire la procédure ci-dessus à l'aide de Bash afin de pouvoir la planifier à l'aide decron.

[[step-4 -—- create-and-test-backup-script]] == Étape 4 - Créer et tester un script de sauvegarde

Maintenant que nous avons sauvegardé notre base de données MongoDB dans un fichier d’archive compressé et transféré ce fichier dans notre espace, nous pouvons combiner ces étapes manuelles dans un seul script Bash.

Créer un script de sauvegarde

Nous allons d'abord écrire un script combinant les commandesmongodump ets3cmd put, et ajouter quelques cloches et sifflets supplémentaires, comme une journalisation (en utilisant `echo`s).

Ouvrez un fichier vide dans votre éditeur de texte préféré (ici, nous utiliseronsnano): 

nano backup_mongo.sh

Collez les extraits de code suivants en veillant à mettre à jour les valeurs pertinentes pour faire référence à vos propres noms d'espace, de base de données et de fichier. Nous appellerons le fichierbackup_mongo.sh, mais vous pouvez nommer ce fichier comme vous le souhaitez. Vous pouvez également trouver le script complet à la fin de cette section.

Passons en revue ce script pièce par pièce:

backup_mongo.sh

#!/bin/bash

set -e
...

Ici,#!/bin/bash dit au shell d'interpréter le script comme du code Bash. set -e dit à l'interpréteur de quitter immédiatement si l'une des commandes de script échoue.

backup_mongo.sh

...

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

...

Dans cette section, nous définissons trois variables que nous utiliserons plus tard:

  • SPACE_NAME: le nom de l'espace DigitalOcean dans lequel nous importons notre fichier de sauvegarde

  • BACKUP_NAME: nom de l'archive de sauvegarde. Ici, nous définissons une chaîne de base date-heure.

  • DB: spécifie la base de données MongoDB que le script sauvegardera. Si vous sauvegardez l’ensemble de l’instance MongoDB (toutes les bases de données), cette variable ne sera pas utilisée.

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

...

Nous imprimons ensuite la date et l'heure (à des fins de journalisation), et commençons la sauvegarde en exécutant la commandemongodump que nous avons testée ci-dessus. Nous sauvegardons à nouveau l'archive de sauvegarde dans~/backup/.

Nous utilisons ensuites3cmd pour copier cette archive à l'emplacement spécifié par ces deux variablesSPACE_NAME etBACKUP_NAME. Par exemple, si notre nom d'espace estmongo-backup-demo et que la date et l'heure actuelles sont2018/04/12 12:42:21, la sauvegarde sera nommée180412_124221.gz et elle sera enregistrée dans l'espacemongo-backup-demo .

backup_mongo.sh

...

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

echo 'Backup complete!'

Ici, nous supprimons l'archive de sauvegarde du répertoire~/backup car nous l'avons copiée avec succès dans notre espace, la sortie finale indiquant que la sauvegarde est terminée.

Après avoir combiné tous ces extraits de code, le script complet doit ressembler à ceci:

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!'

Veillez à enregistrer ce fichier lorsque vous avez terminé.

Nous allons ensuite tester ce script pour vérifier que toutes les sous-commandes fonctionnent.

Tester le script de sauvegarde

Exécutons rapidement le scriptbackup_mongo.sh.

Tout d’abord, rendez le script exécutable: 

chmod +x backup_mongo.sh

Maintenant, lancez le script: 

./backup_mongo.sh

Vous verrez la sortie suivante: 

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!

Nous avons réussi à créer un script shell de sauvegarde et pouvons maintenant passer à sa planification à l’aide decron.

[[step-5 -—- schedule-daily-backups-using-cron]] == Étape 5 - Planifier des sauvegardes quotidiennes à l'aide de Cron

Pour planifier une exécution nocturne du script de sauvegarde, nous utiliseronscron, un utilitaire de planification de travaux intégré aux systèmes d'exploitation de type Unix.

Tout d’abord, nous allons créer un répertoire pour stocker les journaux de notre script de sauvegarde. Ensuite, nous allons ajouter le script de sauvegarde à la crontab (fichier de configuration decron) afin quecron le planifie pour une exécution nocturne. Étant donné quecron prend en charge toute fréquence régulière, vous pouvez éventuellement planifier des sauvegardes hebdomadaires ou mensuelles.

Créer un répertoire de journalisation

Créons un répertoire pour stocker vos fichiers journaux de script de sauvegarde. Ces journaux nous permettront de vérifier périodiquement le script de sauvegarde pour nous assurer que tout va bien, et de déboguer si une commande échouait.

Créez un sous-répertoiremongo_backup dans/var/log (par convention utilisée pour la journalisation): 

sudo mkdir /var/log/mongo_backup

Rendez ce répertoire accessible en écriture à notre utilisateur Unix. Dans ce cas, le nom de notre utilisateur estsammy, mais vous devez utiliser le nom d’utilisateur non root approprié avec les privilèges sudo pour votre serveur. 

sudo chown sammy:sammy /var/log/mongo_backup

Notre utilisateur Unixsammy peut désormais écrire dans/var/log/mongo_backup. Puisque le cronjob fonctionnera en tant quesammy, il peut maintenant écrire ses fichiers journaux dans ce répertoire.

Créons le travail prévu.

Créer un Cronjob

Pour créer le cronjob, nous allons modifier le fichier contenant la liste des travaux planifiés, appelé "crontab". Notez qu'il existe plusieurs crontabs, un par utilisateur, et un crontab à l'échelle du système à/etc/crontab. Dans ce didacticiel, nous exécuterons le script de sauvegarde en tant qu'utilisateursammy; en fonction de votre cas d'utilisation, vous pouvez choisir de l'exécuter à partir de la crontab à l'échelle du système.

Ouvrez la crontab pour l'édition: 

crontab -e

Le menu suivant vous permet de choisir votre éditeur de texte préféré: 

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

Sélectionnez votre éditeur préféré; pour choisirnano entrez2. Maintenant, ajoutez la ligne suivante au fichier, en suivant la section commentée:

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

Assurez-vous d'inclure une fin de ligne à la fin de la crontab. Enregistrez et fermez le fichier.

Vous verrez le résultat suivant: 

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

Le script de sauvegarde sera maintenant exécuté à 2 heures du matin tous les matins. Lesstdout etstderr (les flux de sortie et d'erreur) seront acheminés et ajoutés à un fichier journal appelémongo_backup.log dans le répertoire des journaux que nous avons créé précédemment.

Vous pouvez modifier0 2 * * * (exécuter tous les soirs à 2 h 00 dans la syntaxe cron) en fonction de la fréquence et de l'heure de sauvegarde souhaitées. Pour en savoir plus sur cron et sa syntaxe, consultez notre tutoriel surHow To Use Cron To Automate Tasks On A VPS.

Nous terminerons ce didacticiel par un exercice de récupération rapide pour nous assurer que nos sauvegardes sont fonctionnelles.

[[step-6 -—- perform-a-test-recovery]] == Étape 6 - Effectuer un test de récupération

Toute stratégie de sauvegarde doit contenir une procédure de récupération testée régulièrement. Ici, nous allons rapidement tester une restauration à partir du fichier de sauvegarde compressé que nous avons chargé dans des espaces DigitalOcean.

Tout d'abord, nous allons téléchargertest_dump.gz de notre espace vers le répertoire personnel de notre droplet MongoDB: 

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

Vous verrez la sortie suivante: 

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

Si vous avez commencé ce didacticiel avec une nouvelle instance de MongoDB, vous vous souviendrez qu'elle ne contenait que la base de donnéestest, qui était à son tour la seule base de données que nous ayons sauvegardée.

À des fins de démonstration, nous allons maintenant supprimer cette base de données de test afin de pouvoir effectuer une restauration complète. Si nous n’effectuons pas cette première étape, la procédure de restauration rencontrera les documents originaux, qu’elle sautera. Dans votre cas d'utilisation particulier, restaurer uniquement les nouveaux documents peut être acceptable, mais pour les besoins de ce didacticiel, nous souhaitons tester explicitement une restauration complète dans une base de données vide.

Connectez-vous à votre instance MongoDB à l'aide du shellmongo: 

mongo

Maintenant,use la base de donnéestest et supprimez-la de l'instance MongoDB: 

use test
db.dropDatabase()

Vous verrez la sortie suivante confirmant la baisse detest: 

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

Maintenant, quittez le shellmongo et exécutez la commandemongorestore: 

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

Ici, nous spécifions que le fichier de sauvegarde source est compressé et sous forme de «fichier archive» (rappelons que nous avons utilisé les indicateurs--archive et--gzip lors de l'appel demongodump), et que nous aime restaurer dans la base de donnéestest.

Vous verrez la sortie suivante: 

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

Cela indique que la restauration detest a réussi.

Pour conclure, confirmons que nos données initiales derestaurants ont été restaurées avec succès.

Ouvrez le shell MongoDB et interrogez la collectionrestaurants: 

db.restaurants.find()

Vous devriez voir l'objet que nous avons enregistré dans la première étape de ce tutoriel: 

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

Vous avez maintenant implémenté et testé avec succès cette stratégie de sauvegarde MongoDB.

Conclusion

Dans ce didacticiel, nous avons appris à mettre en œuvre et à tester une stratégie pour les sauvegardes logiques MongoDB nocturnes.

Ce guide peut être étendu ou modifié de nombreuses manières. Voici quelques suggestions rapides:

  • Selon vos objectifs de point de récupération (RPO), vous pouvez augmenter ou diminuer la fréquence de sauvegarde suggérée pour correspondre à votre fenêtre de récupération de données.

  • Un autre ajout utile serait une fonction d’alerte déclenchée en cas d’échec d’une sous-commande de script de sauvegarde (par exemple, cette fonction pourrait envoyer un courrier électronique à une boîte de réception d’alerte régulièrement surveillée).

  • Ce script ne gère pas la suppression d'objet Spaces. Vous voudrez peut-être supprimer les sauvegardes plus anciennes que 6 mois environ.

  • Vous souhaiterez peut-être implémenter unbackup rotation scheme plus complexe, en fonction de votre cas d'utilisation de production.

Comme la procéduremongodump implique la lecture rapide de toutes les données sauvegardées, cette méthode de sauvegarde est la plus appropriée pour les bases de données de petite à moyenne taille, en particulier pour les sauvegardes partielles telles qu'une collection spécifique ou un jeu de résultats. Les sauvegardes au niveau du système de fichiers sont recommandées pour les déploiements plus importants. Pour en savoir plus sur les sauvegardes MongoDB au niveau du système de fichiers, consultez ce tutoriel surHow To Back Up MongoDB Using Droplet Snapshots. Pour en savoir plus sur les différentes méthodes de sauvegarde d'une base de données MongoDB, vous pouvez consulter lesMongoDB manual.

La solution présentée dans ce didacticiel exploitemongodump pour un contrôle granulaire de la couverture des données de sauvegarde et DigitalOcean Spaces pour un stockage de données rentable et durable à long terme. Pour en savoir plus sur l'utilitaire de sauvegarde demongodump, consultez sesreference page dans le manuel MongoDB. Pour en savoir plus sur les espaces DigitalOcean, vous pouvez lireAn Introduction To DigitalOcean Spaces.

Related