Sauvegardes pour systèmes NoSQL (MongoDB, Cassandra) : points de cohérence, sauvegardes incrémentielles et restauration

Les bases de données NoSQL sont souvent perçues en exploitation comme « faciles à mettre à l’échelle » – lors des sauvegardes survient la désillusion. « Un dump suffit » fonctionne rarement pour les systèmes distribués, et même un cycle de sauvegarde réussi dit peu sur la possibilité de RESTaurer un état cohérent. C’est précisément l’objet de cet article : les sauvegardes pour les systèmes NoSQL (à l’exemple de MongoDB et Cassandra) requièrent des points de cohérence planifiés consciemment (états de données définis et cohérents), une stratégie incrémentale solide et surtout un processus de RESTauration qui RESTe reproductible sous contrainte de temps.

Le focus porte sur ce dont les administrateurs et opérateurs ont réellement besoin au quotidien : prérequis, pièges typiques, étapes de vérification, mise en œuvre, dépannage et stratégie de repli. Là où des commandes sont utiles, des blocs copiables sont fournis – sans se perdre dans le marketing d’outils ou les détails internes de frameworks.

Backups für NoSQL-Systeme in der Praxis

De nombreux systèmes NoSQL sont distribués (plusieurs nœuds/Nodes), utilisent la réplication (les données sont stockées de manière redondante) et autorisent l‘ eventual consistency (convergence différée dans le temps). C’est bon pour la disponibilité – mauvais pour les méthodes naïves de sauvegarde.

Exemples d’erreurs typiques en exploitation :

• „Backup ist durchgelaufen, RESTore ist kaputt“ : les données n’étaient pas cohérentes au moment de la sauvegarde (p. ex. snapshot sans checkpoint propre ou sans position de transaction/log adaptée).
• Clusterweiter Zustand fehlt : seuls les fichiers de données ont été sauvegardés, mais pas les métadonnées/la configuration du cluster (configuration du replica set, Keyfiles, TLS-Keys, schéma/indexs, informations de token/topologie).
• Inkremetal-Kette ist unbrauchbar : un segment manque, la rotation des logs a été trop agressive, ou la fenêtre temporelle ne se recoupe pas (p. ex. pour MongoDB la portée de l’Oplog est trop courte).
• RESTore dauert zu lange : le RTO (Recovery Time Objective) est ignoré jusqu’au déclenchement du cas réel – puis les reconstructions, réparations, rejouages ou la bande passante réseau bloquent le processus.

La conséquence : la sauvegarde NoSQL est moins « copier des fichiers » qu‘ un état de données défini plus un chemin de retour traçable – tests inclus.

Grundbegriffe: Konsistenzpunkt, RPO/RTO und „Incremental“ im NoSQL-Kontext

Konsistenzpunkt signifie : il existe un instant/état auquel les données sont présentées de sorte que le processus de base de données les accepte au démarrage et qu’elles s’emboîtent logiquement. Dans les bases de données classiques, cela s’obtient via des Write-Ahead-Logs (WAL) et des checkpoints. Dans les systèmes NoSQL il existe des équivalents – mais ils diffèrent.

RPO (Recovery Point Objective) est la perte de données maximale tolérable en temps (p. ex. 15 minutes). RTO (Recovery Time Objective) est le temps maximal tolérable pour la remise en service (p. ex. 2 heures). Ces deux valeurs déterminent si l’on doit privilégier des snapshots, du log-shipping, des stratégies incrémentales, la réplication ou des combinaisons de ces approches.

Inkrementelles Backup signifie en pratique : vous ne sauvegardez pas à chaque fois l’intégralité des données, mais seulement les modifications depuis le dernier point de sauvegarde. Pour NoSQL cela signifie souvent log-basiert (p. ex. MongoDB Oplog) ou datei-/segmentbasiert (p. ex. Cassandra SSTables plus Commitlog). Important : « incrémental » n’est fiable que dans la mesure où la chaîne de reconstruction et sa validation le sont.

Konsistenzpunkte in MongoDB: Snapshots, Checkpoints und Oplog

MongoDB nutzt je nach Version/Storage-Engine üblicherweise WiredTiger. WiredTiger erstellt Checkpoints (konsistente Zustände auf Disk) und nutzt zusätzlich Journaling (Wiederanlauf-Logik). Für Backups ist entscheidend, welches Ziel Sie verfolgen:

• Crash-consistent : les fichiers de données sont copiés en exploitation (p. ex. snapshot de stockage). MongoDB kann beim Start aus Journal/Recovery einen konsistenten Stand herstellen – das ist aber nicht automatisch ein « sauberer » Applikations-Konsistenzpunkt über mehrere Knoten hinweg.
• Consistent par réplication / par point dans le temps : vous sauvegardez un état correspondant à un point défini de l’Oplog (Oplog = Operation Log, un journal circulaire des changements répliqués im Replica Set). Damit können Sie gezielt bis zu einem Zeitpunkt wiederherstellen (similaire au PITR, Point-in-Time-Recovery).

Modèle éprouvé : sauvegarde depuis un nœud Secondary (oder Hidden) Node

Dans les Replica Sets, il est courant d’effectuer la sauvegarde depuis un Secondary ou un nœud Hidden (Hidden = participe à la réplication, bedient aber keine Reads). Avantage : moins de charge sur le Primary. Risque : si le Secondary accuse un fort retard (Replication Lag), vous sauvegarderez un état nettement plus ancien als le Primary – relevant für Ihr RPO.

Prüfen Sie vor dem Backup mindestens: Replikationsstatus, Lag, Oplog-Fenster. Beispielkommandos:

mongosh --quiet --eval 'rs.printReplicationInfo()'
mongosh --quiet --eval 'rs.status().members.map(m => ({name:m.name, state:m.stateStr, optimeDate:m.optimeDate, health:m.health}))'

Warum das hilft: rs.printReplicationInfo() zeigt u. a. die Oplog-Zeitspanne („log length“). Wenn Ihr inkrementeller Ansatz auf Oplog basiert, muss die Oplog-Reichweite größer sein als Ihr Backup-Intervall plus Puffer (Wartungsfenster, Störungen, Verzögerungen).

Snapshot-Backup: konsistent bekommen, ohne MongoDB zu stoppen

Si vous utilisez des snapshots de stockage (LVM, ZFS, SAN/Array, Cloud-Volume-Snapshot), l’objectif est un état du système de fichiers à un instant précis. Das ist zunächst nur « crash-consistent ». Für MongoDB ist das häufig ausreichend, wenn Sie das Journal mit sichern und der Snapshot sauber atomar ist (keine halbfertigen Writes über mehrere Volumes).

Règles pratiques aus dem Betrieb :

• Ein Volume pro MongoDB-Datenpfad (oder Snapshot über alle beteiligten Volumes synchron). Wenn Daten und Journal getrennt liegen, müssen beide in denselben Snapshot-Zeitpunkt fallen.
• Keine Dateikopie per rsync im laufenden Betrieb als „Billig-Backup“. Das wirkt oft, bis es das erste Mal nicht wirkt.

Si votre objectif est la RESTauration jusqu’à un point précis dans le temps, vous avez en plus besoin d’une chaîne basée sur l’oplog ou d’un mécanisme qui enregistre la position du journal. Un snapshot sans point de référence peut certes être démarré, mais ne peut pas être déroulé de façon déterministe « jusqu’à 10:37:15 ».

Incrémentiel dans MongoDB : l’Oplog comme flux de modifications – avec deux écueils

Pour les « Incrementals », l’Oplog est la solution évidente : il contient les opérations répliquées. Deux écueils typiques :

• L’Oplog est une structure circulaire : si votre oplog est sous-dimensionné, il écrase les anciennes entrées. Dans ce cas votre chaîne incrémentielle se brise, même si tous les jobs de sauvegarde sont « verts ».
• Changements de topologie et de rôle : les failovers, scénarios de rollback ou les resynchronisations peuvent faire qu’un nœud possède un historique différent. Dans de tels cas, « poursuivre l’Oplog » sans source claire est risqué.

Opérationnellement, cela signifie : dimensionnez la fenêtre de l’Oplog pour qu’elle couvre plusieurs cycles de sauvegarde, et surveillez le lag ainsi que la portée de l’Oplog. De plus, les tests de RESTauration doivent toujours inclure une phase de « log-replay », sinon le PITR RESTe théorique.

Points de cohérence dans Cassandra : SSTables, Commitlog et logique de snapshot

Apache Cassandra est un système distribué de type wide-column. Les données arrivent d’abord dans le Memtable (structure en RAM) puis sont écrites sur disque sous forme de SSTables (Sorted String Tables, segments de fichiers immuables). Il existe en outre le Commitlog (Write-Ahead-Log), qui sécurise les écritures jusqu’à leur flush dans les SSTables.

Pour les sauvegardes, cela signifie :

• Un état cohérent se compose souvent de SSTables plus des segments de Commitlog correspondants (si vous voulez garantir une sauvegarde jusqu’à la dernière écriture).
• « Snapshot » dans Cassandra signifie généralement : hardlinks/copies des SSTables actuelles par keyspace/table – pas forcément un snapshot au niveau du stockage.
• Parce que Cassandra est distribué, la cohérence à l’échelle du cluster est plus difficile : un snapshot sur le nœud A n’est pas automatiquement le même état que sur le nœud B.

Snapshots Cassandra : rapides, mais seulement aussi bons que votre chemin de RESTauration

Cassandra peut générer des snapshots par nœud, typiquement via nodetool. C’est rapide, car les SSTables sont immuables et souvent seuls des hardlinks sont créés. Exemple :

# Snapshot pour un keyspace sur un nœud
nodetool snapshot --tag nightly_2026-08-19 my_keyspace

# Liste des snapshots disponibles
nodetool listsnapshots

Pourquoi cela fonctionne : Les SSTables ne sont plus modifiés après leur écriture. Un snapshot référence exactement ces fichiers. Quand cela échoue : Lorsque, lors du RESTore, vous ne savez pas précisément quels SSTables appartiennent à quel moment et à quelle topologie, ou si vous ne disposez de snapshots que d’une partie des nœuds (selon le facteur de réplication et la distribution des tokens).

Inkrementelle Backups in Cassandra: „incremental backups“ vs. wirklich inkrementell

Cassandra propose „incremental backups“ en tant que fonctionnalité, où les nouveaux SSTables sont en outre hardlinkés/copiés dans un répertoire de sauvegarde. C’est utile, mais pas un concept de sauvegarde complet : vous avez toujours besoin de snapshots comme base de référence et devez contrôler la chaîne (rétention, nettoyage, RESTauration).

Aspects opérationnels importants :

• Compaction (processus en arrière-plan de fusion des SSTables) génère de nouveaux SSTables et rend obsolètes les anciens. Cela influence quels fichiers vous devez sauvegarder et la rapidité de croissance des répertoires de sauvegarde.
• Commitlog : selon vos exigences RPO/RTO, il peut être nécessaire de sauvegarder des segments de commitlog ou au moins de s’assurer que les snapshots sont pris après un flush, afin de minimiser les dépendances au commitlog.
• Repair : Cassandra nécessite des repairs réguliers (synchronisation entre réplicas). Un RESTore sans stratégie de repair ultérieure peut conduire à des incohérences « silencieuses ».

Incrementals sauber aufbauen: Drei Strategien, die in der Praxis funktionieren

Chez MongoDB et Cassandra, les mécanismes diffèrent, mais la planification suit souvent des schémas similaires. Trois stratégies récurrentes en exploitation :

1) Full + Log-Shipping (PITR-nah)

Vous réalisez régulièrement une sauvegarde complète (snapshot/dump) et sauvegardez en continu les logs/flux de modifications. Pour MongoDB, c’est typiquement basé sur l’Oplog ; pour Cassandra plutôt orienté commitlog (ou via des approches externes de streaming/CDC, si disponibles). Avantage : bon RPO. Inconvénient : le RESTore est plus complexe, car les replays et l’ordre doivent être exacts.

2) Full + „Block-/Datei-Incremental“ (Storage-/Backup-System macht Deltas)

Dans ce cas, un système de sauvegarde prend en charge la déduplication et les incrémentaux au niveau des blocs (par ex. au niveau du système de fichiers). Avantage : moins de logique spécifique à la base de données. Risque : vous obtenez des « deltas », mais pas de cohérence applicative garantie si le point de consistance n’est pas correctement produit (quiesce/checkpoint/snapshots coordonnés).

3) Replikation ist nicht Backup – aber sinnvoller Baustein

La réplication (Replica Set, Multi-DC dans Cassandra) protège principalement contre les pannes de nœud et augmente la disponibilité. Elle ne remplace pas une sauvegarde, car les erreurs logiques (suppressions, jobs défectueux, ransomware utilisant des identifiants valides) sont répliquées. En pratique, on combine réplication et sauvegardes pour réduire le RTO et utiliser les sauvegardes comme « dernier recours ».

RESTore-Realität: Was Sie zusätzlich zu den Daten immer sichern müssen

Beaucoup de problèmes de RESTore ne proviennent pas de fichiers de données manquants, mais d’un manque d’« environnement opérationnel ». Définissez ce qui fait partie d’un état RESTaurable :

• Configuration : mongod.conf / cassandra.yaml, options JVM, paramètres de stockage, réseau, authentification.
• Matériel de sécurité : certificats/clefs TLS, keyfiles, keystores/truststores, références KMS/Vault, mots de passe/secrets (avec un concept de sauvegarde dédié).
• Métadonnées du cluster : nom du Replica Set, Seed-Nodes, token/rack/DC-topologie (Cassandra), définitions d’auth/RBAC.

Une bonne pratique consiste à stocker ces artefacts versionnés (z. B. dans un Git-Repo sécurisé) et à les inclure également dans la sauvegarde, afin que la RESTauration RESTe possible même en cas de défaillance d’un outil ou du dépôt.

Pratique : vérifications préalables (Preflight) avant chaque sauvegarde NoSQL

Preflight signifie : vous vérifiez des conditions qui ne seront plus réparables ultérieurement. Les vérifications sont courtes, mais elles permettent de gagner des heures lors de la RESTauration.

Preflight MongoDB : réplication, Oplog, stockage, verrous

• Replica Set stable, pas de re-sync, pas de lag persistant
• Fenêtre d’oplog supérieure à l’intervalle de sauvegarde + marge
• Assez d’espace libre pour Snapshot/Export et pour test de RESTauration
• Pas de maintenance (z. B. Index-Rebuild) en conflit avec la fenêtre de snapshot

# Basisstatus und Oplog-Fenster prüfen
mongosh --quiet --eval 'rs.status().ok'
mongosh --quiet --eval 'rs.printReplicationInfo()'

# Optional: wichtige Server-Infos (Version, Storage Engine)
mongosh --quiet --eval 'db.serverStatus().version'
mongosh --quiet --eval 'db.serverStatus().storageEngine'

Preflight Cassandra : état du cluster, compactions en attente, repair/streaming

• Tous les Nodes «UN» (Up/Normal), pas de nœuds instables
• Pas de gros flux de streaming ni de compactions en attente excessives
• Schéma de nommage/étiquette de sauvegarde cohérents (pour rattachement ultérieur)

nodetool status
nodetool tpstats
nodetool compactionstats

Interprétation : Un Snapshot pendant une compaction massive n’est pas fondamentalement «faux», mais il faut s’attendre à une croissance et à des durées d’exécution plus longues. Pour les exploitants, l’essentiel est : les Snapshots doivent être planifiables, pas «ça tourne un jour ou l’autre».

Planifier la RESTauration : séquence d’étapes, vérifications et stratégie de repli

La RESTauration n’est pas une commande unique, mais une séquence contrôlée. Un runbook de RESTauration avec des gates clairs (Go/No-Go) et un plan de repli a fait ses preuves.

Gates de RESTauration : trois points de contrôle à ne pas négliger

1. Artefacts complets ? Données + config + éléments de sécurité + informations de version. Des clés manquantes ou une config erronée feront perdre du temps par la suite.
2. Environnement cible conforme ? Versions compatibles (MongoDB/Cassandra), kernel/filesystem adaptés, performance du stockage suffisante. Une RESTauration sur «n’importe quelle VM» est souvent le début d’une longue nuit de travail.
3. Validation après RESTauration : le service démarre, le cluster est stable, contrôles de consistance/intégrité, tests smoke applicatifs, monitoring de nouveau au vert.

Stratégie de repli : si la RESTauration n’aboutit pas correctement

Prévoyez une stratégie de repli définie, plutôt que d’improviser ad hoc :

• RESTauration parallèle : RESTauration dans un environnement isolé (VLAN/Namespace séparé), puis bascule contrôlée (DNS/Load-Balancer). Cela évite qu’une RESTauration incomplète n’écrase les données de production.
• Phase en lecture seule : si possible, mettez les applications en lecture seule (ou en mode dégradé) pour arrêter les modifications de données avant de «revenir en arrière».

Dépannage: pièges fréquents pour les sauvegardes MongoDB et Cassandra

MongoDB: Oplog trop petit, failover au mauvais moment, snapshot sans journal

Symptôme: le replay incrémental impossible, car des lacunes dans l’Oplog apparaissent.

Cause: la fenêtre de l’Oplog ne couvre pas l’intervalle, ou vous sauvegardez depuis un nœud au parcours instable (Rollback).

Contremesures:

• Augmenter la dimension de l’Oplog et la surveiller (tendance sur plusieurs jours/semaines).
• Fixer la source de sauvegarde (p. ex. Hidden Secondary) et prendre en compte les scénarios de failover dans la logique de sauvegarde.
• Concevoir la stratégie de snapshot de sorte que le journal et les chemins de données soient sauvegardés de manière consistante ensemble.

Cassandra: snapshot uniquement sur certains nodes, ordre incorrect, lacune de Repair

Symptôme: le RESTore démarre, mais les données sont incomplètes ou les requêtes renvoient des résultats différents selon le nœud.

Cause: le snapshot n’a pas été coordonné à l’échelle du cluster (pour toutes les répliques pertinentes) ou le RESTore a été mis en service sans stratégie de Repair en aval.

Contremesures:

• Automatiser le runbook de snapshot par nœud et collecter le succès de manière centralisée (ne pas « espérer via SSH »).
• Associer systématiquement le RESTore à un plan post-RESTore défini (p. ex. Repair/validation), adapté au facteur de réplication et au niveau de consistance.
• Maintenir proprement la rétention et le nettoyage: discipline stricte sur les tags/périodes, sinon la chaîne n’est plus traçable.

Validation des sauvegardes: comment tester la RESTaurabilité sans risquer la production

«Sauvegarde réussie» n’est qu’un signal indiquant que les données ont été écrites. Ce n’est qu’un test qui démontre si elles sont RESTaurables. Pour les bases NoSQL, une approche par paliers est recommandée:

• Test de RESTore technique: réinjecter les données dans un environnement isolé, démarrage de la DB, formation du cluster, fonctions de base opérationnelles.
• Tests de logique / smoke: requêtes d’exemple, comptages, échantillonnages (p. ex. collections / keyspaces importants), méthodes optionnelles de checksum/comparaison.
• Mesure du RTO: chronométrer (Download/Decrypt/RESTore/Rebuild/Repair). Si le RTO n’est pas satisfaisant, vous devez optimiser les chemins de RESTore, pas seulement augmenter la fréquence des sauvegardes.

Important au quotidien: les tests de RESTore n’ont pas besoin de tout vérifier à chaque fois. Mais un exercice complet devrait avoir lieu régulièrement, au cours duquel l’équipe exécute le processus, documente les logs et les durées, et améliore le runbook.

Checklist: standard minimal pour les sauvegardes MongoDB et Cassandra

• Valeurs cibles définies: RPO/RTO par écrit, incluant les exceptions (fenêtres de maintenance, larges déploiements).
• Nœud source défini: MongoDB privilégie Secondary/Hidden, Cassandra plan de snapshot par nœud.
• Point de cohérence documenté: horodatage/date, position Oplog/log, ID de snapshot, informations de version.
• Chaîne incrémentale surveillée: fenêtre d’Oplog, rétention des logs, croissance du stockage, effets de compaction.
• Configuration & sécurité sauvegardées: configurations, clés, certificats, références de secrets.
• Runbook de RESTauration disponible: séquence d’étapes, jalons de validation, procédure de repli, responsabilités.
• Tests de RESTauration réguliers: isolés, documentés, avec mesure du RTO.

Conclusion : la sauvegarde NoSQL est un projet de RESTauration — pas seulement une exécution de sauvegarde

Pour MongoDB et Cassandra, ce n’est pas le « si », mais le « comment » qui compte : les points de cohérence doivent être créés intentionnellement et être traçables, les sauvegardes incrémentales exigent une chaîne robuste (Oplog/Logs/SSTables) et la RESTauration doit exister comme un processus pratiqué. Si vous mettez en place des contrôles préalables, des métadonnées propres et des exercices de RESTauration réguliers, les sauvegardes passent d’un exercice obligatoire à un outil opérationnel fiable — même à 03:00 du matin, quand personne n’a le temps pour des expérimentations.

Pour ce sujet, les sauvegardes MongoDB et Cassandra sont également importantes. Cet article replace ces aspects de manière compréhensible et montre ce qui compte au quotidien.