MongoDB : backup et restore avec des exemples pratiques

Intro

Cette version française explique MongoDB backup and restore with practical examples avec le même objectif pratique que l article source : aider le lecteur à comprendre le contexte, les décisions à prendre et les points à vérifier avant de passer à l action.

La protection des données MongoDB n’est réelle que si vous prouvez régulièrement que vous pouvez les restaurer. Ce guide fournit des étapes concrètes, copié-collé, pour réaliser des MongoDB backup, effectuer des MongoDB restore en toute sécurité, conduire des MongoDB validation, planifier un MongoDB rollback propre, et répéter le MongoDB disaster recovery. Vous terminerez avec un pilote local éprouvé et un chemin clair vers la production.

Public visé :

• Développeurs, consultants DevOps et équipes à fort enjeu qui veulent un plan fiable et sans drame
• Toute personne souhaitant un workflow répétable, testable localement en premier

Ce que vous allez faire :

• Prendre des sauvegardes cohérentes MongoDB (mongodump et snapshots système de fichiers)
• Restaurer vers une cible sûre, valider à fond, et planifier un cutover propre
• Répéter des scénarios de désastre et mesurer votre RTO/RPO

Vue d'ensemble du workflow

Un workflow de production fiable reste simple et explicite :

1. Choisir la méthode de sauvegarde

• mongodump pour les sauvegardes logiques ; utilisez --oplog pour les replica sets
• Snapshots de système de fichiers pour les charges à fort débit et les clusters shardés

1. Planifier et stocker les backups

• Exécuter sur une secondary si possible, compresser et chiffrer au repos, conserver plusieurs générations

1. Tester régulièrement les restores

• Restaurer dans un espace de noms de staging, jamais directement en production

1. Valider les résultats

• Comptages, hashes, requeates échantillons, index, utilisateurs/roles, fCV

1. Planifier le rollback et le cutover

• Restaurer dans des collections parallèles, puis échanger les noms de façon atomique

1. Répéter le disaster recovery

• Chronométrer chaque étape, corriger les goulots, documenter le runbook

Exemples de backup (replica set)

Créez des utilisateurs à privilèges minimaux pour le backup et le restore.

// Dans mongosh sur la primary
use admin
// Utilisateur de backup
db.createUser({
  user: "backup",
  pwd: "REDACTED_STRONG_PW",
  roles: [ { role: "backup", db: "admin" } ]
})
// Utilisateur de restore (uniquement sur non-prod ou cible DR)
db.createUser({
  user: "restore",
  pwd: "REDACTED_STRONG_PW",
  roles: [ { role: "restore", db: "admin" } ]
})

Aides d’environnement :

export RS_URI='mongodb://backup: REDACTED_STRONG_PW@rs0/yourdb?replicaSet=rs0&authSource=admin'
export TS=$(date -u +%Y%m%dT%H%M%SZ)
mkdir -p backups

Dump complet d’une base depuis une secondary avec oplog pour la sécurité point-in-time :

mongodump \
  --uri "$RS_URI" \
  --readPreference secondaryPreferred \
  --db yourdb \
  --archive "backups/yourdb-$TS.archive" \
  --gzip \
  --oplog

Dump d’une collection (filtrer un sous-ensemble actif pour réduire la taille) :

mongodump \
  --uri "$RS_URI" \
  --db yourdb \
  --collection orders \
  --archive "backups/yourdb-orders-$TS.archive" \
  --gzip

Chiffrez l’archive au repos (exemple GnuPG) :

gpg --symmetric --cipher-algo AES256 "backups/yourdb-$TS.archive"
shred -u "backups/yourdb-$TS.archive"  # supprimer le clair de manière sûre

Idée de rétention :

• Conserver N quotidiens, W hebdomadaires, M mensuels
• Stocker des copies offsite et tester aussi les restores depuis l’offsite

Exemples de backup (snapshots)

mongod standalone : verrouiller, snapshotter, déverrouiller.

// Dans mongosh sur le nf3ud
use admin
db.adminCommand({ fsync: 1, lock: true })

Prenez un snapshot LVM, EBS ou à un autre niveau stockage, puis :

// Retour dans mongosh
db.fsyncUnlock()

Clusters shardés : désactivez le balancer et prenez un snapshot de chaque shard et config server de façon cohérente.

// Dans mongosh connecté à mongos
sh.stopBalancer()
// Vérifier l’état : sh.getBalancerState() doit eatre false

Après des snapshots synchronisés sur tous les shards et config servers, réactivez le balancer :

sh.startBalancer()

Notes :

• mongodump --oplog fonctionne pour les replica sets, pas pour un cluster shardé via mongos
• Pour la cohérence inter-shard, préférez des snapshots coordonnés ou une solution de backup managée

Exemples de restore

Restaurez toujours vers une cible sûre (base de staging ou nouveau namespace) et validez avant tout cutover.

Restauration basique d’une archive de base complète :

export RESTORE_URI='mongodb://restore: REDACTED_STRONG_PW@primary/yourdb?authSource=admin'

mongorestore \
  --uri "$RESTORE_URI" \
  --archive "backups/yourdb-$TS.archive" \
  --gzip \
  --nsFrom 'yourdb.*' \
  --nsTo   'yourdb_restored.*' \
  --drop \
  --writeConcern '{"w":"majority","wtimeout":60000}'

Restauration sélective d’une seule collection :

mongorestore \
  --uri "$RESTORE_URI" \
  --archive "backups/yourdb-orders-$TS.archive" \
  --gzip \
  --nsInclude 'yourdb.orders' \
  --drop

Récupération point-in-time (PITR) avec un dump contenant l’oplog :

• La commande mongodump ci-dessus a écrit un segment d’oplog dans l’archive
• Vous pouvez rejouer cet oplog lors du restore, en limitant éventuellement par timestamp

# Restore base + rejouage oplog jusqu’au plus récent de l’archive
mongorestore \
  --uri "$RESTORE_URI" \
  --archive "backups/yourdb-$TS.archive" \
  --gzip \
  --oplogReplay

Limiter l’oplog à un timestamp (format : seconds[:ordinal]) :

# Exemple : s'arreater à l’époque UNIX 1719931200
mongorestore \
  --uri "$RESTORE_URI" \
  --archive "backups/yourdb-$TS.archive" \
  --gzip \
  --oplogReplay \
  --oplogLimit 1719931200

Astuce : restaurez dans un namespace différent (yourdb_pitr.*) pour comparer avant tout échange.

Contrôles de validation après restore

Exécutez des vérifications rapides et déterministes avant de déclarer un restore valide.

1. Comptages

// Comparer source vs restaurée (exécuter sur chacune)
use yourdb
const expected = db.orders.countDocuments({})
// Sur le namespace restauré
use yourdb_restored
const actual = db.orders.countDocuments({})
printjson({ expected, actual, ok: expected === actual })

1. Hashes (par collection)

// Sur chaque environnement
db.adminCommand({ dbHash: 1, collections: ["orders"] })

1. Index

db.orders.getIndexes()

1. Requeates représentatives

db.orders.find({ status: "open" }).limit(5).toArray()
db.orders.aggregate([{ $match: { createdAt: { $gte: ISODate("2026-01-01") } } }, { $count: "n" }])

1. Utilisateurs et rôles

use admin
db.getUsers()

1. Feature compatibility version (fCV)

use admin
db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 })

Script Node.js de sanity check (optionnel) :

// verify.js
const { MongoClient } = require('mongodb');
(async () => {
  const srcUri = process.env.SRC_URI;         // ex. mongodb://.../yourdb
  const dstUri = process.env.DST_URI;         // ex. mongodb://.../yourdb_restored
  const coll = 'orders';
  const src = new MongoClient(srcUri);
  const dst = new MongoClient(dstUri);
  try {
    await src.connect();
    await dst.connect();
    const srcCount = await src.db().collection(coll).countDocuments();
    const dstCount = await dst.db().collection(coll).countDocuments();
    console.log({ srcCount, dstCount, match: srcCount === dstCount });
    process.exit(srcCount === dstCount ? 0 : 2);
  } catch (e) {
    console.error(e);
    process.exit(1);
  } finally {
    await src.close();
    await dst.close();
  }
})();

Plan de rollback et cutovers

Évitez de restaurer directement en production. Préférez :

1. Restaurer vers des collections parallèles dans la meame base (suffixe _new)
2. Chauffer les caches avec des lectures
3. Échanger les noms de collection de manière atomique
4. Conserver les anciennes collections pour un revert rapide, puis nettoyer

Plan de renommage (droits admin requis) :

use admin
// Échanger orders_new -> orders avec sauvegarde de l’ancien
// Étape 1 : archiver l’ancien nom de collection
db.adminCommand({ renameCollection: 'yourdb.orders', to: 'yourdb.orders_old', dropTarget: true })
// Étape 2 : promouvoir la nouvelle collection
db.adminCommand({ renameCollection: 'yourdb.orders_new', to: 'yourdb.orders', dropTarget: true })

Notes :

• renameCollection fonctionne au sein de la meame base de données
• Faites une collection à la fois pour un rollback clair
• En cas de rollback, inversez les étapes de renommage

Plan de disaster recovery

Définissez vos objectifs :

• RTO : durée maximale acceptable d’un restore
• RPO : quantité de données que vous pouvez perdre

Bonnes pratiques :

• Réplication : exécutez des replica sets sur des domaines de défaillance distincts
• Backups : conservez des copies chiffrées, versionnées, offsite
• PITR : combinez des dumps ou snapshots réguliers avec l’archivage de l’oplog
• Runbooks : documentez hôtes, URIs, gestion des identifiants, commandes et critères de succès
• Répétitions : menez des exercices trimestriels de restore, chronométrez, corrigez les goulots
• Monitoring : alertez sur échecs de jobs de backup, écarts de données et capacité de stockage

Pilotage local

Démarrez petit et mesurable avant de monter en charge :

Périmètre

• Une base (yourdb), une collection critique (orders), taille cible de quelques Go max

Étapes

1. Prendre un mongodump avec --oplog depuis une secondary d’un replica set
2. Restaurer dans yourdb_restored sur un cluster de dev
3. Lancer le script de validation (counts, hashes, requeates échantillons)
4. Consigner taille du dump, temps de dump, temps de restore, résultats de validation
5. Documenter et optimiser si nécessaire (compression, parallélisme, index)

Critères de sortie

• Le restore passe toutes les vérifications
• Le temps de bout en bout respecte votre budget RTO pour le pilote
• Les membres de l’équipe peuvent répéter le processus sans aide

Erreurs courantes et correctifs

Correctif : planifiez des exercices mensuels ou trimestriels avec validation.

• Erreur : ne pas tester les restores.

Correctif : ajoutez toujours --oplog avec mongodump sur un replica set.

• Erreur : ignorer --oplog pour les replica sets.

Correctif : utilisez des snapshots coordonnés avec le balancer stoppé, ou une solution managée.

• Erreur : sauvegarder un cluster shardé via mongos en attendant une cohérence inter-shard.

Correctif : restaurez dans un namespace de staging, validez, puis basculez par renommage.

• Erreur : restaurer directement en production.

Correctif : comparez getIndexes et db.getUsers.

• Erreur : oublier les index ou les utilisateurs dans la validation.

Correctif : lisez depuis une secondary avec --readPreference secondaryPreferred.

• Erreur : surcharger la primary pendant le backup.

Correctif : chiffrer au repos, restreindre l’accès, faire tourner les clés.

• Erreur : artefacts de backup non sécurisés.

Conclusion

Vous avez maintenant un workflow pratique de MongoDB backup et restore :

• Pour les replica sets, utilisez mongodump avec --oplog et restaurez avec validation
• Pour les clusters shardés, préférez des snapshots coordonnés
• Validez : counts, hashes, requeates échantillons, index et utilisateurs
• Planifiez le rollback avec des renommages de collections, et répétez le DR pour prouver RTO/RPO

Prochaines étapes

• Mettre en œuvre le plan de pilotage local cette semaine
• Automatiser la validation et ajouter du monitoring des échecs
• Élargir le périmètre et la fréquence une fois le pilote validé