Backup per sistemi NoSQL (MongoDB, Cassandra): punti di consistenza, backup incrementali e ripristino

I database NoSQL sono spesso percepiti in esercizio come „facili da scalare“ – la delusione arriva con il backup. „Un dump basta“ funziona raramente nei sistemi distribuiti, e anche un ciclo di backup andato a buon fine dice poco sul fatto che da esso si possa ripristinare uno stato consistente. Proprio a questo punto si rivolge questo contributo: backup per sistemi NoSQL (a titolo esemplificativo MongoDB e Cassandra) richiedono punti di consistenza pianificati consapevolmente (stati di dati definiti e coerenti), una strategia incrementale solida e, soprattutto, un processo di RESTore che rimanga riproducibile sotto pressione temporale.

Il focus è su ciò che amministratori e operatori necessitano realmente nella pratica: prerequisiti, trappole tipiche, passaggi di verifica, implementazione, troubleshooting e una strategia di fallback. Dove i comandi sono utili, sono forniti blocchi copiabili – senza perdersi nel marketing degli strumenti o negli internals dei framework.

Backup per sistemi NoSQL nella pratica

Molti sistemi NoSQL sono distribuiti (più nodi), utilizzano replicazione (i dati sono memorizzati in modo ridondante) e permettono la consistenza eventuale (allineamento ritardato nel tempo). Questo è positivo per la disponibilità – negativo per metodi di backup ingenui.

Tipici problemi operativi:

• „Il backup è terminato, il RESTore è rotto“: i dati non erano consistenti al momento del salvataggio (p.es. snapshot senza checkpoint pulito o senza la posizione corretta di transazione/log).
• Manca lo stato a livello di cluster: sono stati salvati solo i file di dati, ma non i metadati/la configurazione del cluster (Replikaset-Config, Keyfiles, TLS-Keys, schema/indici, Token/Topology-Infos).
• La catena incrementale è inutilizzabile: manca un segmento, la rotazione dei log è stata troppo aggressiva, oppure le finestre temporali non si sovrappongono (per MongoDB p.es. la portata dell Oplog è troppo ridotta).
• Il RESTore richiede troppo tempo: l’RTO (Recovery Time Objective) viene ignorato fino al verificarsi dell’emergenza – allora bloccano rebuild, repair, replay o la banda di rete.

La conseguenza: il backup NoSQL non è semplicemente «copiare file», ma uno stato di dati definito più una procedura riproducibile per tornare a quello stato – incluso il test.

Concetti di base: punto di consistenza, RPO/RTO e „incrementale“ nel contesto NoSQL

Punto di consistenza significa: esiste un istante/stato in cui i dati sono presenti in modo tale che il processo del database, all’avvio, li accetti come validi e che siano logicamente coerenti. Nelle basi dati classiche ciò si ottiene tramite Write-Ahead-Logs (WAL) e checkpoint. Nei sistemi NoSQL esistono equivalenti – ma differiscono.

RPO (Recovery Point Objective) è la perdita massima di dati tollerabile in termini di tempo (p.es. 15 minuti). RTO (Recovery Time Objective) è il tempo massimo di ripristino tollerabile (p.es. 2 ore). Entrambi i valori determinano se conviene puntare su snapshot, log-shipping, strategie incrementali, replica o combinazioni.

Backup incrementale significa nella pratica: non si salva ogni volta l’intero insieme di dati, ma solo le modifiche dall’ultimo punto di backup. Nei NoSQL questo significa spesso a base di log (p.es. MongoDB Oplog) o basato su file/segmenti (p.es. Cassandra SSTables più commitlog). Importante: „incrementale“ è valido solo quanto la catena di ricostruzione e la sua convalida.

Konsistenzpunkte in MongoDB: Snapshots, Checkpoints und Oplog

A seconda della versione/engine di storage, MongoDB utilizza di norma WiredTiger. WiredTiger crea checkpoint (stati coerenti su disco) e utilizza inoltre il journaling (meccanismo di recovery). Per i backup è determinante capire quale obiettivo si persegue:

• Crash-consistente: i file di dati vengono copiati a caldo (es. snapshot dello storage). MongoDB può all’avvio ricostruire uno stato coerente dal journal/dal recovery – tuttavia questo non corrisponde automaticamente a un punto di consistenza applicativa „pulito“ tra più nodi.
• Consistente rispetto a replica/istante temporale: si esegue il backup di uno stato che corrisponde a un definito istante dell’Oplog (Oplog = operation log, un registro circolare delle modifiche replicate nel Replica Set). Ciò consente di ripristinare fino a un punto temporale specifico (simile a PITR, Point-in-Time-Recovery).

Pratica consolidata: backup da un Secondary (o Hidden) Node

Nei Replica Set è consuetudine eseguire la copia di sicurezza da un Secondary o da un Hidden Node (Hidden partecipa alla replica ma non serve letture). Vantaggio: minore carico sul Primary. Rischio: se la Secondary è molto in ritardo (Replication Lag), si esegue il backup di uno stato nettamente più vecchio rispetto al Primary – condizionando il vostro RPO.

Verificate prima del backup almeno: stato della replica, lag, finestra dell’Oplog. Comandi di esempio:

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}))'

Perché questo aiuta: rs.printReplicationInfo() mostra, tra l’altro, l’intervallo temporale dell’Oplog („log length“). Se il vostro approccio incrementale si basa sull’Oplog, la copertura dell’Oplog deve essere più ampia del vostro intervallo di backup più un margine (finestre di manutenzione, incidenti, ritardi).

Snapshot di backup: ottenere consistenza senza fermare MongoDB

Se utilizzate snapshot dello storage (LVM, ZFS, SAN/array, snapshot di volumi cloud), l’obiettivo è uno stato puntuale del file system. Questo è inizialmente solo „crash-consistente“. Per MongoDB spesso è sufficiente se includete il journal nel backup e lo snapshot sia atomico e pulito (assenza di scritture parziali su più volumi).

Regole pratiche derivate dall’esercizio operativo:

• Un volume per percorso dati di MongoDB (o snapshot sincronizzato su tutti i volumi coinvolti). Se dati e journal sono separati, entrambi devono appartenere allo stesso istante di snapshot.
• Nessuna copia di file con rsync a caldo come „backup economico“. Spesso funziona, finché non smette di funzionare la prima volta.

Se il vostro obiettivo è la ripristino a un punto temporale esatto, avete inoltre bisogno di una catena basata sull’Oplog o di un meccanismo che conservi la posizione del log. Uno snapshot privo di punto di riferimento può essere avviato, ma non è possibile riportarlo in modo deterministico „fino alle 10:37:15“.

Incrementale in MongoDB: Oplog come stream di modifiche – con due criticità

Per gli „incrementali“ l’Oplog è la scelta ovvia: contiene le operazioni replicate. Due insidie tipiche:

• L’Oplog è un ring: se l’Oplog è dimensionato troppo piccolo sovrascrive le voci più vecchie. Questo interrompe la vostra catena incrementale, anche se tutti i job di backup risultano „verdi“.
• Cambiamenti di topologia e ruolo: failover, scenari di rollback o re-sync possono portare a che un nodo abbia una cronologia diversa. In tali casi è rischioso „proseguire l’Oplog“ senza una fonte chiara.

Operativamente questo significa: dimensionate la finestra dell’Oplog in modo che copra più cicli di backup e monitorate il lag e la portata dell’Oplog. Inoltre i test di RESTore dovrebbero includere sempre una fase di „log replay“, altrimenti il PITR RESTa teorico.

Punti di consistenza in Cassandra: SSTables, Commitlog e logica degli snapshot

Apache Cassandra è un sistema wide-column distribuito. I dati arrivano prima nel Memtable (struttura in RAM) e vengono poi scritti su disco come SSTables (Sorted String Tables, segmenti di file immutabili). Inoltre esiste il Commitlog (Write-Ahead-Log), che protegge le scritture finché non vengono in SSTables „flushed“.

Per i backup questo significa:

• Uno stato consistente consiste spesso di SSTables più i segmenti corrispondenti del Commitlog (se volete proteggere fino all’ultima scrittura).
• Per „Snapshot“ in Cassandra si intende di norma: hardlink/copie delle SSTables correnti per keyspace/tabella – non necessariamente uno snapshot a livello di storage.
• Poiché Cassandra è distribuito, la consistenza a livello di cluster è più complessa: uno snapshot sul nodo A non corrisponde automaticamente allo stesso stato sul nodo B.

Snapshot di Cassandra: veloci, ma validi solo quanto il vostro percorso di ripristino

Cassandra può creare snapshot per nodo, tipicamente tramite nodetool. È veloce perché le SSTables sono immutabili e spesso vengono creati solo hardlink. Esempio:

# Snapshot für einen Keyspace auf einem Node
nodetool snapshot --tag nightly_2026-08-19 my_keyspace

# Auflistung vorhandener Snapshots
nodetool listsnapshots

Perché questo funziona: gli SSTables non vengono modificati dopo essere stati scritti. Uno snapshot fa riferimento esattamente a questi file. Quando fallisce: se durante il RESTore non si sa con precisione quali SSTables appartengono a quale momento e a quale topologia, o se si hanno snapshot solo di una parte dei nodi (a seconda del fattore di replica e della distribuzione dei token).

Backup incrementali in Cassandra: „incremental backups“ vs. realmente incrementale

Cassandra offre gli „incremental backups“ come funzionalità, in cui i nuovi SSTables vengono inoltre hardlinkati/copiati in una directory di backup. Questo è utile, ma non è un concetto di backup completo: avete comunque bisogno degli snapshot come baseline e dovete controllare la catena (retention, cleanup, ripristino).

Aspetti operativi importanti:

• Compaction (processo in background per unire gli SSTables) genera nuovi SSTables e rende obsoleti quelli vecchi. Questo influenza quali file è necessario salvare e quanto velocemente crescono le directory di backup.
• Commitlog: a seconda dei requisiti di RPO/RTO può essere necessario salvare i segmenti del commitlog o almeno garantire che gli snapshot vengano presi dopo un flush, per minimizzare le dipendenze dal commitlog.
• Repair: Cassandra richiede repair regolari (allineamento tra repliche). Un RESTore senza una strategia di repair successiva può portare a inconsistenze “silenti”.

Costruire gli incrementali in modo corretto: tre strategie che funzionano nella pratica

In MongoDB e Cassandra i meccanismi sono diversi, ma la pianificazione segue spesso schemi simili. Tre strategie ricorrenti in esercizio:

1) Full + Log-Shipping (vicino a PITR)

Si crea regolarmente un backup completo (snapshot/dump) e si salvano in modo continuo i log/flussi di modifica. In MongoDB questo è tipicamente basato su Oplog, in Cassandra più orientato al commitlog (o tramite approcci di streaming/CDC esterni, se disponibili). Vantaggio: buon RPO. Svantaggio: il RESTore è più complesso, perché replay e ordine devono essere corretti.

2) Full + „Block-/File-Incremental“ (il sistema di storage/backup genera i delta)

Qui un sistema di backup si occupa di deduplicazione e incrementali a blocchi (p.es. a livello di file system). Vantaggio: meno logica specifica del DB. Rischio: si ottengono “delta”, ma non una consistenza applicativa garantita se il punto di consistenza non è creato in modo pulito (quiesce/checkpoint/snapshot coordinati).

3) La replica non è un backup — ma è un elemento sensato

La replica (Replica Set, Multi-DC in Cassandra) protegge primariamente dagli outage dei nodi e aumenta la disponibilità. Non sostituisce un backup, perché i guasti logici (cancellazioni, job difettosi, ransomware con credenziali valide) vengono replicati. In pratica si combina la replica con i backup per ridurre l’RTO e usare i backup come “ultima istanza”.

Realtà del RESTore: cosa dovete sempre salvare oltre ai dati

Molti problemi di RESTore non nascono dalla mancanza dei file dati, ma dalla mancanza dell’“ambiente operativo”. Definite cosa appartiene a uno stato recuperabile:

• Configurazione: mongod.conf / cassandra.yaml, opzioni JVM, parametri per storage, rete, autenticazione.
• Materiale di sicurezza: certificati/chiavi TLS, keyfile, keystore/truststore, riferimenti a KMS/Vault, password/secret (con un proprio concetto di backup).
• Metadati del cluster: nome del Replica Set, seed nodes, topologia token/rack/DC (Cassandra), definizioni di auth/RBAC.

Un buon approccio è archiviare questi artefatti versionati (ad es. in un Git-Repo protetto) e includerli anche nel backup, così il ripristino RESTa possibile anche in caso di guasti a tool/repository.

Guida pratica: controlli preflight prima di ogni backup NoSQL

Preflight significa: verificate condizioni che in seguito non si possono più riparare. I controlli sono brevi, ma fanno risparmiare ore al momento del ripristino.

MongoDB Preflight: replica, Oplog, storage, lock

• Replica Set stabile, nessun Re-Sync, nessun lag persistente
• Finestra dell’Oplog più ampia dell’intervallo di backup + margine
• Spazio libero sufficiente per snapshot/export e per il test di ripristino
• Nessuna manutenzione (es. rebuild degli indici) in conflitto con la finestra di 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'

Cassandra Preflight: Cluster health, pending compactions, repair/streaming

• Tutti i nodi „UN“ (Up/Normal), nessun nodo instabile
• Nessuna grande attività di streaming o pending compactions fuori controllo
• Tag/nome dei backup coerente (per una successiva correlazione)

nodetool status
nodetool tpstats
nodetool compactionstats

Interpretazione: Uno snapshot durante compaction massiccia non è intrinsecamente „sbagliato“, ma bisogna prevedere crescita e tempi di esecuzione più lunghi. Per gli operatori è cruciale: gli snapshot devono essere pianificabili, non „funzionare a caso“.

Pianificare il ripristino: sequenza, verifiche e strategia di fallback

Il ripristino non è un singolo comando, ma una sequenza controllata. Si è dimostrato utile un runbook di ripristino con gate chiari (Go/No-Go) e un piano di fallback.

Gate di ripristino: tre punti di verifica da non saltare

1. Artefatti completi? Dati + configurazione + materiale di sicurezza + informazioni sulle versioni. Chiavi mancanti o configurazioni errate costeranno tempo in seguito.
2. L’ambiente di destinazione è corretto? Versioni compatibili (MongoDB/Cassandra), kernel/filesystem adeguati, performance dello storage sufficienti. Un ripristino su „qualsiasi VM“ è spesso l’inizio di molte notti di lavoro.
3. Validazione dopo il ripristino: servizio avviato, cluster stabile, controlli di consistenza/integrità, smoke test delle applicazioni, monitoring di nuovo verde.

Strategia di fallback: se il ripristino non va a buon fine

Pianificate una strategia di fallback definita, invece di improvvisare ad hoc:

• RESTore parallelo: ripristino in un ambiente isolato (VLAN/Namespace separato), quindi commutazione controllata (DNS/Load-Balancer). Così evitate che un ripristino incompleto sovrascriva i dati di produzione.
• Fase di sola lettura: se possibile, impostate le applicazioni in sola lettura (o in modalità degradate) per bloccare le modifiche ai dati prima di tornare indietro.
• Ultimo backup noto valido: Definite quale generazione è considerata „Known Good“ (esiste un test di RESTore) e documentate il percorso fino ad essa.

Troubleshooting: insidie comuni nei backup di MongoDB e Cassandra

MongoDB: Oplog troppo piccolo, failover al momento sbagliato, Snapshot senza journal

Sintomo: Replay incrementale non possibile perché si formano lacune nell’Oplog.

Causa: La finestra dell’Oplog non copre l’intervallo, oppure eseguite il backup da un nodo con cronologia instabile (rollback).

Contromisure:

• Aumentare la dimensione dell’Oplog e monitorarla (trend su giorni/settimane).
• Fissare la sorgente di backup (p.es. Hidden Secondary) e considerare scenari di failover nella logica di backup.
• Progettare la strategia di snapshot in modo che journal e percorsi dei dati vengano salvati coerentemente insieme.

Cassandra: snapshot solo su alcuni nodi, ordine errato, lacuna nel repair

Sintomo: Il RESTore parte, ma i dati sono incompleti o le query RESTituiscono risultati diversi a seconda del nodo.

Causa: Lo snapshot non è stato coordinato a livello di cluster (per tutti i replicati rilevanti) oppure il RESTore è stato messo in esercizio senza una strategia di repair successiva.

Contromisure:

• Automatizzare il runbook di snapshot per nodo e raccogliere centralmente lo stato di successo (non „sperare tramite SSH“).
• Collegare sempre il RESTore a un piano post-RESTore definito (p.es. repair/validazione), allineato al fattore di replica e al livello di consistenza.
• Mantenere pulite retention e cleanup: disciplina rigorosa su tag/intervalli temporali, altrimenti la catena non è più tracciabile.

Validazione del backup: come testare la recuperabilità senza rischiare la produzione

„Backup riuscito“ è solo un segnale che i dati sono stati scritti. Se sono recuperabili lo dimostra solo un test. Per NoSQL è consigliato un approccio a più livelli:

• Test di RESTore tecnico: ripristinare i dati in un ambiente isolato, il DB parte, il cluster si forma, le funzioni di base funzionano.
• Test di logica / smoke: query di esempio, conteggi, campionamenti (p.es. collection/keyspace importanti), opzionalmente metodi di checksum/confronto.
• Misurazione RTO: cronometrare (download/decrypt/RESTore/rebuild/repair). Se l’RTO non è adeguato, ottimizzate i percorsi di RESTore, non solo aumentate la frequenza dei backup.

Importante per la routine: i test di RESTore non devono verificare „tutto“ ogni volta. Però dovrebbe svolgersi regolarmente un drill completo in cui il team esegue il processo, documenta log e tempi e migliora il runbook.

Checklist: standard minimo per i backup di MongoDB e Cassandra

• Valori target definiti: RPO/RTO per iscritto, incluse eccezioni (finestra di manutenzione, grandi deployment).
• Nodo sorgente definito: MongoDB preferisce Secondary/Hidden, Cassandra richiede un piano di snapshot per nodo.
• Punto di consistenza documentato: istante/data, Oplog-/Log-Position, Snapshot-ID, informazioni sulla versione.
• Catena incrementale monitorata: finestra Oplog, retention dei log, crescita dello storage, effetti di compaction.
• Configurazioni & Security protette: configurazioni, chiavi, certificati, riferimenti ai secret.
• Runbook di RESTore disponibile: sequenza di passi, gate, rollback, responsabilità.
• Test di ripristino regolari: isolati, documentati, con misurazione dell’RTO.

Fazit: NoSQL-Backup ist ein RESTore-Projekt – nicht nur ein Sicherungslauf

Con MongoDB e Cassandra non è il «se», ma il «come»: i punti di consistenza devono essere generati consapevolmente e resi verificabili, gli incrementali richiedono una catena robusta (Oplog/Logs/SSTables) e il ripristino deve esistere come processo consolidato e praticato. Se stabilite Preflight-Checks, metadati accurati e prove regolari di ripristino, i backup passano da un’esercitazione obbligatoria a una risorsa operativa affidabile – anche quando alle 03:00 di notte nessuno ha tempo per esperimenti.

Per questo tema sono inoltre importanti Mongodb Backup e Cassandra Backup. L’articolo inquadra questi aspetti in modo comprensibile e mostra cosa conta nella pratica quotidiana.