Guida completa al backup e al ripristino del database MongoDB

Introduzione: Perché i backup sono importanti per MongoDB?

Quando si utilizza MongoDB in produzione, il backup è essenziale: può fare la differenza tra il recupero da un incidente e la perdita permanente dei dati. Un database come MongoDB, che contiene informazioni sugli utenti, sulle transazioni, sui prodotti o sullo stato delle app, è un database in cui l’integrità dei dati si traduce direttamente in continuità aziendale. I processi di backup e ripristino dei dati MongoDB sono alla base di tale integrità.

Un singolo guasto hardware, una cancellazione involontaria o un’infezione da ransomware potrebbero causare una perdita significativa di dati. In questi casi, non esisterebbero nemmeno opzioni di recupero valide, se non esiste una strategia di backup forte e affidabile. La qualità di un piano di backup di MongoDB implementato oggi determinerà la velocità con cui i sistemi potranno tornare online dopo un eventuale guasto, come purtroppo accade alla maggior parte dei sistemi.

Quali sono i rischi di non avere una strategia di backup affidabile?

Ci sono tre categorie di rischio principali nel gestire un sistema MongoDB senza una strategia di backup:

• Operativo
• Finanziario
• Reputazionale

Tutte queste categorie hanno un qualche tipo di effetto che si accumulerà nel tempo e diventerà molto più difficile da risolvere dopo eventi di perdita di dati.

Il rischio operativo è il più immediato. Quando un nodo primario si guasta, una raccolta cade o una migrazione fallisce – il cluster viene lasciato in uno stato incoerente. Il database di backup MongoDB previsto non esiste, quindi il team deve eseguire un recupero forense dai registri delle applicazioni o dalle esportazioni frammentate, se esistono.

L‘esposizione finanziaria segue da vicino. Gli obblighi di conformità imposti da normative come GDPR, HIPAA e SOC 2 significano che un guasto di backup sarà un incidente di conformità, non un semplice guasto tecnico. Audit successivi, multe e notifiche di violazione obbligatorie possono essere ricondotte a pratiche di backup e ripristino di MongoDB mal implementate o inesistenti.

Le modalità di fallimento più comuni che le organizzazioni incontrano includono:

• Cadute accidentali di collezioni – uno sviluppatore esegue db.collection.drop() nell’ambiente sbagliato.
• Migrazioni di schemi sbagliate – uno script di trasformazione corrompe i documenti in scala prima che l’errore venga individuato
• Ransomware e attacchi all’infrastruttura – i dati crittografati diventano inaccessibili senza una copia offline
• Guasto hardware senza ridondanza – un nodo standalone si guasta senza replica e senza snapshot recente
• Corruzione silenziosa – i problemi di integrità dei dati passano inosservati fino a quando non è necessario un backup, a quel punto anche i backup esistenti potrebbero essere danneggiati.

I danni alla reputazione sono più difficili da quantificare, ma non per questo sono meno reali. Sia gli utenti individuali che quelli aziendali che affidano i loro dati a una piattaforma si aspettano che questi rimangano al sicuro. Un evento di perdita di dati ampiamente segnalato – anche se causato da un problema di infrastruttura piuttosto che da un intento malevolo – danneggia la fiducia degli utenti a tal punto da richiedere anni per essere riscattato e ricostruito.

In che modo i tipi di distribuzione di MongoDB influiscono sulle esigenze di backup (standalone, set di replica, cluster sharded)?

La topologia di distribuzione di MongoDB attualmente in uso determina i possibili metodi di backup disponibili, il livello di complessità e le garanzie di coerenza disponibili. Le tre principali topologie esistenti sono standalone, replica set e cluster sharded, tutte con requisiti di backup diversi.

Le implementazioni standalone sono le più semplici per il backup, ma comportano il rischio intrinseco più elevato. Non essendoci un sistema secondario su cui fare il fail over durante l’esecuzione dei backup, qualsiasi processo di backup ad alta intensità di I/O entrerà in competizione diretta con il traffico di produzione. Le istantanee del sistema di file con supporto della semantica copy-on-write sono le più appropriate in questa situazione, come LVM o ZFS (entrambi sono istantanei e non dannosi).

I set di repliche introducono un elevato grado di flessibilità operativa. Il processo di backup di MongoDB può essere scaricato su un nodo secondario, mantenendo il carico di lavoro del backup isolato da quello primario. Anche i backup basati su Oplog diventano possibili in questo caso, consentendo il ripristino point-in-time a qualsiasi momento utilizzando la finestra di conservazione di Oplog – qualcosa che le implementazioni standalone non possono fornire.

L’oplog è un registro con data e ora di ogni operazione di scrittura nel database, che MongoDB può utilizzare per scopi di replica, riproducendolo per ripristinare i dati a qualsiasi punto precedente nel tempo.

I cluster sharded richiedono il coordinamento più attento. Ogni shard è trattato come un set di replica indipendente, motivo per cui è necessario catturare tutti gli shard e il set di replica del server di configurazione nello stesso punto logico nel tempo per ottenere un backup coerente a livello di cluster. La funzione di chunk balancer deve essere messa in pausa prima di iniziare un backup, e la coerenza tra gli shard sarebbe difficile da garantire senza un coordinamento esplicito. MongoDB Atlas Backup (il servizio di database cloud gestito di MongoDB) gestisce la maggior parte di queste attività in modo automatico, ma i cluster sharded autogestiti richiedono comunque un’orchestrazione manuale o uno strumento di terze parti.

Quale obiettivo di tempo di ripristino (RTO) e quale obiettivo di punto di ripristino (RPO) devo considerare?

RTO e RPO sono le due metriche che definiscono ciò che una strategia di backup deve offrire. Il Recovery Time Objective ( RTO) è la durata massima accettabile tra un evento di guasto e il ripristino del servizio normale. Il Recovery Point Objective (RPO) è la quantità massima accettabile di perdita di dati, espressa come punto nel tempo. Entrambi i valori devono essere definiti prima ancora di tentare di selezionare gli strumenti di backup o i modelli di pianificazione: questi sono i requisiti per i quali servono tutte le altre decisioni.

La maggior parte delle organizzazioni riesce a definire i propri RTO e RPO solo dopo aver sperimentato un’interruzione di dimensioni sostanziali, che le costringe a definire questi parametri sotto pressione. Ad esempio, un’applicazione rivolta ai clienti che elabora gli ordini in modo continuativo non può tollerare quattro ore di downtime o sei ore di perdita di dati. Molte configurazioni di backup che non sono mai state sottoposte a stress test produrrebbero esattamente questi risultati.

Utilizzi il seguente schema per stabilire gli obiettivi di base:

Una pipeline di backup e ripristino del database MongoDB con RPO di cinque minuti sarà completamente diversa da una pipeline con RPO di 24 ore. Il backup continuo basato su Oplog è necessario per consentire punti di ripristino inferiori alle ore, perché cattura ogni operazione di scrittura in tempo quasi reale. Le strategie di soli snapshot (acquisizione di snapshot a determinati intervalli) producono un punto di recupero pari alla frequenza di snapshot – il che significa che un programma di snapshot di quattro ore produce un RPO di quattro ore nel caso peggiore.

Gli RTO sono altrettanto sensibili quando si tratta di scegliere una strategia di backup. Il ripristino di 2 TB di un archivio mongodump dallo storage di oggetti richiederebbe diverse ore per essere completato. Nel frattempo, il ripristino da un’istantanea del filesystem che risiede sullo storage a blocchi collegato richiederebbe solo pochi minuti. Il processo di ripristino di MongoDB stesso – non solo il formato di backup – deve essere preso in considerazione in tutti i calcoli di RTO. I team che documentano e testano regolarmente i loro framework di ripristino hanno maggiori probabilità di raggiungere gli obiettivi RTO quando è importante.

Come si inserisce il backup di MongoDB in una più ampia strategia di protezione dei dati aziendali?

Il backup è solo un aspetto di una strategia di protezione, non è la totalità. Mentre il backup di MongoDB comprende i dati a livello di database (collezioni, indici, utenti e impostazioni di configurazione), la resilienza aziendale richiede anche una copertura adeguata dello stato dell’applicazione, della gestione dei segreti e delle dipendenze tra servizi. La strategia di backup MongoDB che un’azienda sceglie di implementare deve essere definita tenendo presente questo obiettivo generale.

Perché il backup a livello di database non è sufficiente per la resilienza aziendale?

Un backup completo di MongoDB cattura l’intero contenuto del motore del database. Non cattura i seguenti elementi:

• La configurazione dell’applicazione, che indica al database come comportarsi.
• Certificati TLS che proteggono le connessioni al database
• Variabili d’ambiente che memorizzano le credenziali
• Stato dell’infrastruttura, che descrive la topologia di rete in cui viene eseguito.

Il ripristino di un backup di MongoDB in un ambiente instabile o mal configurato creerà un database funzionante a cui la sua applicazione non potrà connettersi o autenticarsi.

Per essere resilienti, le aziende dovranno tenere conto di ciascuno dei seguenti aspetti:

1. Configurazione e segreti dell’applicazione – file di ambiente, voci del Vault, stringhe di connessione e chiavi API da cui dipendono i servizi.
2. Stato dell’infrastruttura – definizioni di Terraform o CloudFormation che descrivono l’ambiente di rete, di calcolo e di archiviazione.
3. Coerenza dei dati tra servizi – record correlati in altri database o code di messaggi che devono allinearsi con il punto di ripristino MongoDB
4. La configurazione stessa di MongoDB – le definizioni dei set di replica, i ruoli degli utenti e gli indici personalizzati che non sempre vengono catturati da un mongodump di base

Come si integrano i backup MongoDB con le piattaforme di backup aziendali?

Non esiste un supporto “incorporato” per MongoDB nella maggior parte delle soluzioni di backup aziendali. L’integrazione si ottiene in genere attraverso uno dei tre meccanismi principali: ganci pre/post backup che attivano mongodump o un’istantanea prima che la piattaforma catturi il filesystem, plugin basati su agenti che il fornitore della piattaforma fornisce o supporta, o orchestrazione guidata da API in cui la piattaforma di backup chiama uno script esterno che gestisce le fasi specifiche di MongoDB.

Le piattaforme con cui le organizzazioni integrano più comunemente MongoDB includono:

• Bacula Enterprise. Integrazione basata su plugin con supporto di scripting pre-job; adatta agli ambienti regolamentati che richiedono tracce di audit.
• Veeam. Approccio basato sulle istantanee; la coerenza di MongoDB richiede un’elaborazione consapevole dell’applicazione o script di pre-congelamento.
• Commvault. Integrazione con IntelliSnap per le istantanee a livello di blocco; supporta le topologie di set di replica e cluster sharded.
• NetBackup (Veritas). Basato su agenti con pianificazione dei criteri; plugin MongoDB disponibile per i livelli di licenza aziendali.

In che modo i sistemi di backup centralizzati riducono il rischio operativo?

Se ogni team è responsabile della gestione del proprio processo di backup di MongoDB, si avranno pianificazioni variabili, conservazione incoerente e nessun modo per sapere se i backup hanno avuto successo. I sistemi di backup centralizzati impongono l’uniformità dei criteri su tutte le istanze del database, il che elimina la classe di incidenti che si verificano quando il lavoro di backup di un team si interrompe silenziosamente per settimane.

Il vantaggio operativo non riguarda solo la visibilità, ma anche la responsabilità. Un sistema centralizzato che tiene traccia di ogni lavoro di backup, verifica ogni istantanea terminata e si attiva in caso di guasto, crea una traccia chiaramente documentata, spesso necessaria ai fini dell’audit di conformità. La gestione dei backup MongoDB distribuita tra i vari team tende a produrre lacune che vengono scoperte solo quando c’è una necessità urgente di ripristino.

Quali sono le strategie di backup MongoDB disponibili?

La strategia di backup del database MongoDB più appropriata dipenderà dalla topologia di distribuzione, dalla finestra di perdita dei dati tollerabile e dalla complessità operativa. Le tre strategie di backup di base descritte di seguito – backup logico, backup fisico e ripristino point-in-time basato su oplog – non si escludono a vicenda. Due o tutte e tre le opzioni sono utilizzate in tandem nella maggior parte degli ambienti di produzione.

Che cos’è il backup logico e quando dovrebbe usare mongodump/mongorestore?

Il backup logico prende un’istantanea dei dati MongoDB come documenti BSON che vengono scritti in file da mongodump. Mongorestore è poi in grado di ripristinare questi dati in qualsiasi altra istanza MongoDB compatibile. Questo processo è topologia-agnostico, non richiede l’accesso a un file system e genera un output portatile che può essere esaminato, filtrato o ripristinato in base alla raccolta.

Il backup di MongoDB prodotto da mongodump cattura documenti, indici, utenti e ruoli. Non cattura l’oplog o le transazioni in volo, il che significa che questa istantanea point-in-time è coerente solo nel momento in cui il dump viene completato – mentre il processo stesso può richiedere minuti o addirittura ore (su grandi insiemi di dati).

Il backup logico è la scelta giusta quando:

• La portabilità è importante – spostare i dati da una versione all’altra di MongoDB o da un cloud provider all’altro.
• È necessario un ripristino selettivo – ripristinare una singola raccolta senza toccare il resto del database
• Il set di dati è piccolo – inferiore a ~100GB, dove la durata del dump non crea un rischio significativo di coerenza
• Non è disponibile l’accesso al filesystem – ambienti di hosting gestiti in cui le API di snapshot non sono esposte

Per le implementazioni di grandi dimensioni e con un elevato carico di scrittura, il mongodump da solo è raramente sufficiente come strategia primaria di backup e ripristino di MongoDB.

Che cos’è il backup fisico e quando dovrebbe utilizzare le istantanee del filesystem?

Il backup fisico esegue una copia dei file di dati grezzi che MongoDB scrive sul filesystem (i file del motore di archiviazione WiredTiger, il journal e gli indici) a livello di filesystem/block. Gli strumenti adatti per ottenere questo risultato includono le istantanee LVM in Linux, le istantanee AWS EBS e la funzione ZFS send/receive.

Poiché il backup è istantaneo e avviene al di fuori del processo di mongoDB – i backup sono molto più veloci da creare rispetto a mongodump su grandi insiemi di dati e il database stesso è quasi del tutto ignaro del fatto che il backup è in corso, in termini di prestazioni.

Il prerequisito chiave per il backup fisico è la coerenza del filesystem. MongoDB deve trovarsi in uno stato di checkpoint pulito o deve avere il journaling abilitato (una misura predefinita con WiredTiger) per far sì che l’istantanea rappresenti uno stato recuperabile. Il tentativo di creare un’istantanea senza tenere conto di questo aspetto, risulterebbe in un backup che potrebbe anche non avviarsi durante una procedura di disaster recovery di MongoDB.

Il backup fisico è la scelta giusta quando:

• Le dimensioni del set di dati sono grandi – dove la durata del mongodump creerebbe un divario di coerenza inaccettabile.
• L’RTO è stretto – i ripristini a livello di blocco sono più veloci della reimportazione a livello di documento.
• L’infrastruttura supporta snapshot atomici – ambienti EBS, LVM o ZFS in cui sono disponibili snapshot copy-on-write.
• Il ripristino dell’intero cluster è lo scenario previsto, piuttosto che il ripristino selettivo a livello di collezione.

Come funzionano i backup point-in-time e i metodi basati su oplog?

Il ripristino point-in-time funziona accoppiando un’istantanea di base con il replay oplog per ripristinare un’implementazione MongoDB in qualsiasi punto specifico all’interno della finestra di conservazione oplog. I nodi secondari utilizzano oplog per la replica, mentre i backup lo utilizzano per colmare il divario tra l’istantanea di base e il punto di ripristino target.

Il processo funziona come segue: un’istantanea di base viene acquisita al momento T, catturando lo stato completo del database. L’oplog viene poi acquisito continuamente o a intervalli dal momento T in poi. Al momento del ripristino, viene utilizzata prima l’istantanea di base e poi le voci dell’oplog vengono riprodotte fino al timestamp di destinazione, creando uno stato del database accurato per quel momento esatto.

Ci sono due vincoli pratici che regolano questo approccio. Il primo è il fatto che l’oplog ha un tetto massimo, in quanto le voci più vecchie vengono sovrascritte una volta che devono essere inserite nuove voci, quindi la finestra di recupero sarà sempre limitata dalle dimensioni dell’oplog e dal volume di scrittura. Il secondo vincolo riguarda il fatto che il ripristino point-in-time richiede un set di replica – in quanto le implementazioni standalone non hanno oplog e non possono supportare questo metodo senza Atlas o una soluzione di terze parti.

Quando utilizzare il backup incrementale di MongoDB rispetto al backup completo?

Un backup completo copia l’intero set di dati ad ogni esecuzione. Un backup incrementale copia solo le modifiche apportate dall’ultimo backup, sia tramite l’oplog tailing che il tracking delle modifiche a livello di blocco. L’opzione migliore per ogni organizzazione varia notevolmente a seconda delle dimensioni del set di dati, della frequenza di backup e del costo di archiviazione.

Una tipica strategia di backup consiste nell’utilizzare un backup completo settimanale con backup incrementali giornalieri o orari, offrendo un compromesso tra spazio richiesto e complessità di ripristino. Ogni backup completo reinizializza la catena incrementale e limita l’età dell’incremento, riducendo in una certa misura la portata della corruzione.

Quali strumenti e servizi supportano il backup e il ripristino del database MongoDB?

L’ecosistema di backup e ripristino di MongoDB comprende un gran numero di elementi, suddivisi in gruppi: servizi cloud gestiti, utility native da riga di comando, strumenti a livello di filesystem e piattaforme aziendali di terze parti. Ognuna di queste opzioni ha una posizione distinta sullo spettro “semplicità operativa – controllo”.

Quali sono i pro e i contro di MongoDB Atlas Backup?

MongoDB Atlas Backup è un servizio di backup completamente gestito che viene fornito con i cluster Atlas. Il servizio funziona in modo continuo, non richiede alcuna configurazione dopo l’attivazione e supporta anche il ripristino basato su timestamp in qualsiasi momento durante il periodo di conservazione. È il modo più semplice per implementare un piano di backup MongoDB pronto per la produzione per i team che già utilizzano MongoDB Atlas.

Le funzionalità più degne di nota di Atlas Backup sono riassunte nella tabella seguente.

La portabilità è la più grande limitazione di Atlas Backup. Se una soluzione è stata configurata per un cluster – non viene trasferita a un’implementazione autogestita, e tutti i ripristini devono essere condotti tramite l’interfaccia Atlas o l’API (inaccessibile tramite gli strumenti mongorestore standard). Questo singolo vincolo può essere un ostacolo per le organizzazioni che lavorano con mandati multi-cloud o con requisiti normativi incentrati sulla residenza dei dati.

Come funziona MongoDB Atlas Backup to S3 e quando si dovrebbe usare?

MongoDB Atlas Backup to S3 è una funzione di esportazione di istantanee, non un flusso di replica continua. Può essere invocato manualmente o in base ad una pianificazione. Una volta attivato, Atlas esegue un’istantanea coerente del cluster, scrivendola in un bucket S3 specificato in un formato che rende possibile il ripristino di tali dati in un secondo momento con gli strumenti standard di MongoDB. L’istantanea esportata prodotta come risultato è disaccoppiata da Atlas stesso, il che la rende appropriata per l’archiviazione a lungo termine, la copia tra regioni o come parte dei requisiti di conservazione della conformità.

È anche importante essere chiari su ciò che questa funzione è e non è. Atlas Backup non fornisce lo streaming in tempo reale delle modifiche dell’oplog su S3. L’esportazione viene effettuata in un momento specifico e l’intervallo tra tali esportazioni rappresenta l’RPO effettivo per qualsiasi cosa che si affidi esclusivamente alle copie S3. I team che necessitano di punti di ripristino inferiori all’ora devono trattare queste esportazioni S3 come un livello di archiviazione secondario, non come un meccanismo primario di recupero dei dati.

I backup di Atlas dovrebbero essere utilizzati quando c’è la necessità di conservazione a lungo termine o di portabilità al di fuori di Atlas. Non si affidi ad esso come unico metodo di backup di MongoDB in produzione, soprattutto quando gli RPO sono già abbastanza stringenti.

Come si confronta il mongodump/mongorestore con il mongorestore con oplog replay?

Il mongodump normale prende una singola istantanea logica coerente del database. Il ripristino tramite mongorestore riproduce l’istantanea così com’è – creando un database che viene riportato al suo stato esatto al momento del completamento del dump, senza alcuna opzione di ripristino a qualsiasi altro punto.

mongorestore con oplog replay estende il risultato di cui sopra applicando le operazioni dell’oplog all’istantanea ripristinata, riportando il database ad una data desiderata. Questa funzionalità critica è ciò che rende possibile il ripristino point-in-time per le distribuzioni autogestite.

Il flag oplog replay(–oplogReplay) obbliga mongorestore ad applicare direttamente qualsiasi voce oplog inclusa nel dump una volta completato il processo di ripristino del documento. Questa opzione è resa possibile dall’utilizzo di un flag specifico(–oplog) per catturare l’oplog stesso insieme a mongodump.

Come si possono utilizzare in modo sicuro le istantanee a livello di sistema (LVM, EBS, ZFS) con MongoDB?

Il requisito di coerenza per la validità di un backup fisico di MongoDB sono i file di dati che rappresentano un checkpoint WiredTiger pulito. Il motivo per cui WiredTiger può essere utilizzato è che scrive i dati in background e mantiene un journal. Se dovesse scattare un’istantanea dei file di dati mentre il motore è in funzione, l’istantanea sarebbe recuperabile, a condizione che il journaling sia abilitato (come lo è sempre per impostazione predefinita). Non deve necessariamente essere un’istantanea dei dati mentre Mongo è fermo, ma deve essere un’istantanea atomica a livello di filesystem.

Il modo in cui si ottiene questo livello di atomicità dipende dallo strumento:

• Istantanee LVM – istantanee copy-on-write di un volume logico; istantanee e coerenti se i dati MongoDB e il journal risiedono sullo stesso volume. La suddivisione tra i volumi richiede lo snapshot di entrambi contemporaneamente.
• Istantanee Amazon EBS – istantanee a livello di blocco attivate tramite API AWS; adatte a MongoDB ospitato nel cloud con dati su volumi EBS. La coerenza multi-volume richiede l’utilizzo di gruppi di snapshot multi-volume EBS.
• Invio/ricezione ZFS – le istantanee ZFS sono atomiche per design e catturano l’intero set di dati in uno stato coerente. Sono ideali per le implementazioni on-premises in cui ZFS è il filesystem sottostante.

L’unico scenario che può essere considerato non sicuro in queste circostanze è quando MongoDB viene utilizzato senza journaling su un filesystem non ZFS. Fortunatamente, questo tipo di configurazione è rara nelle implementazioni moderne, ma vale comunque la pena di fare un doppio controllo prima di affidarsi ai backup di MongoDB basati su snapshot durante la produzione.

Esistono strumenti di backup di terze parti e quali funzioni offrono?

Alcune soluzioni di terze parti integrano o forniscono un’alternativa alle funzioni di backup integrate di MongoDB, soprattutto negli ambienti aziendali autogestiti in cui Atlas non viene utilizzato:

• Percona Backup for MongoDB (PBM) – open-source, supporta il backup logico e fisico, il ripristino del replay oplog e il coordinamento del cluster sharded. L’alternativa self-hosted più capace ad Atlas Backup.
• Bacula Enterprise – piattaforma di backup aziendale con integrazione di MongoDB tramite scripting pre/post job e supporto di plugin; forti funzioni di audit trail e conformità per ambienti regolamentati.
• Ops Manager (MongoDB) – la piattaforma di gestione on-premises di MongoDB che include il backup continuo con ripristino point-in-time basato su oplog; richiede una distribuzione separata di Ops Manager.
• Dbvisit Replicate – strumento di acquisizione dei dati di modifica che può svolgere una funzione di backup per MongoDB, trasmettendo le modifiche a un target secondario.
• Servizi di snapshot cloud-native – AWS Backup, Azure Backup e Google Cloud Backup supportano tutti snapshot a livello di volume che possono includere le directory di dati MongoDB, se configurati correttamente.

Un punto di partenza comune per la maggior parte delle distribuzioni autogestite che non dispongono di una piattaforma di backup aziendale esistente è Percona Backup for MongoDB. È gratuito da usare, viene sviluppato attivamente e dispone delle funzioni principali necessarie per il flusso di lavoro completo di backup e ripristino del database MongoDB.

Come si può integrare il backup di MongoDB con Bacula Enterprise per la protezione aziendale?

Bacula Enterprise è una soluzione di backup completa che consente alle organizzazioni di centralizzare la protezione dei dati in ambienti eterogenei composti da server fisici, macchine virtuali, istanze cloud e database.

L‘integrazione del backup di MongoDB con Bacula si ottiene attraverso lo scripting pre e post lavoro. Bacula avvia un mongodump o un’istantanea del sistema di file prima di eseguire il backup dei file generati e poi esegue azioni di conservazione dei dati, crittografia e trasferimento remoto in base alla politica preconfigurata.

Ciò che Bacula apporta a una strategia di protezione dei dati MongoDB e che gli strumenti nativi non forniscono:

• Pianificazione centralizzata e applicazione dei criteri – i lavori di backup di MongoDB vengono eseguiti con la stessa pianificazione e lo stesso quadro di conservazione di ogni altro carico di lavoro nell’ambiente, eliminando l’incoerenza che deriva dai lavori cron gestiti da un team.
• Tracciati di audit e rapporti di conformità – ogni lavoro di backup viene registrato con timestamp, stato di successo e volume di dati, producendo il record verificabile richiesto dai settori regolamentati.
• Archiviazione e trasporto crittografati – i dati sono crittografati a riposo e in transito per impostazione predefinita, con gestione delle chiavi a livello di piattaforma anziché per database
• Alerting e escalation dei guasti – i lavori di backup MongoDB falliti vengono a galla attraverso la stessa pipeline di alerting dei guasti dell’infrastruttura, anziché passare inosservati in un registro di script.
• Supporto di copie multi-sito e air-gapped – Bacula supporta tape, object storage e target di siti remoti, il che è prezioso per le organizzazioni che richiedono copie di backup MongoDB offline o air-gapped come parte della loro postura di protezione contro il ransomware.

Si tratta anche di una transizione senza soluzione di continuità per le organizzazioni che già si affidano a Bacula Enterprise per le loro esigenze di backup. Invece di costruire un’altra infrastruttura di backup separata, il processo di backup MongoDB è facilmente integrato nel sistema esistente, con una significativa riduzione della proliferazione di strumenti e della complessità di gestione.

Come si esegue un backup sicuro per diverse topologie MongoDB?

Un metodo di backup MongoDB adatto a un singolo server non garantisce necessariamente l’integrità e l’assenza di interruzioni del servizio quando viene applicato a un set di repliche o a un cluster sharded senza adattamento. Una delle ragioni principali è il gran numero di fattori che cambiano a seconda della topologia MongoDB scelta.

Come si esegue il backup di un set di replica senza impattare sulla disponibilità?

Il backup del set di replica si basa su un unico principio principale: non eseguire mai un backup ad alta intensità di risorse contro il primario quando è possibile evitarlo. Il primario riceve tutto il traffico di scrittura e un processo di backup che combatte per il suo I/O è la fonte di latenza percepita da tutti gli utenti dell’applicazione. L’opzione migliore è un secondario dedicato – configurato come membro nascosto, idealmente, in modo che non riceva traffico ed esista solo per le attività operative come il backup.

Il processo di backup sicuro del set di replica segue questo ordine:

1. Verificare il ritardo di replica sul secondario di destinazione prima di iniziare. Un secondario in ritardo produce un backup che non riflette lo stato attuale dei dati – controlli rs.printSecondaryReplicationInfo() e confermi che il ritardo è entro limiti accettabili.
2. Selezioni un secondario nascosto o a bassa priorità come destinazione del backup, per evitare di sottrarre capacità di lettura ai membri che servono le applicazioni.
3. Avvia il backup – mongodump o un’istantanea del sistema di file – contro la directory di dati o l’endpoint di connessione del secondario.
4. Acquisisca l’oplog insieme al backup, se è necessario un ripristino point-in-time. Utilizzi –oplog con mongodump, oppure registri l’intervallo di timestamp dell’oplog che corrisponde alla finestra dell’istantanea.
5. Verifichi il backup prima di ruotare le vecchie copie. Un backup che non è mai stato verificato non è un backup, ma una supposizione.

C’è anche un caso limite interessante che vale la pena notare: se tutti i secondari sono in ritardo a causa di un picco di traffico di scrittura, potrebbe essere meglio ritardare completamente il backup piuttosto che rischiare di creare un’istantanea incoerente.

Come si esegue il backup di un cluster sharded e si coordina la coerenza a livello di shard?

Il backup di cluster sharded è lo scenario di backup di MongoDB più complicato da gestire. Questo perché è necessario ottenere un punto coerente nel tempo tra più set di repliche in esecuzione in momenti diversi e indipendenti l’uno dall’altro. Ogni shard ha il proprio oplog e il proprio stato, e il set di replica del server di configurazione è il luogo in cui vengono archiviati i metadati del cluster che mappano i chunk agli shard. Un backup che riesce a catturare gli shard in momenti diversi è inutile per impostazione predefinita, poiché crea un’immagine del cluster incoerente.

Il processo di coordinamento richiede i seguenti passaggi:

• Arrestare il bilanciatore di chunk utilizzando sh.stopBalancer() prima che inizi qualsiasi attività di backup. Un bilanciatore attivo migra i chunk tra gli shard durante il backup, il che produce uno stato in cui lo stesso documento potrebbe apparire in due istantanee dello shard o in nessuna.
• Disattivi qualsiasi migrazione di chunk programmata per la durata della finestra di backup, per evitare che il ribilanciamento automatico riprenda a metà della cattura.
• Esegua prima il backup del set di replica del server di configurazione. Il server di configurazione detiene la mappa dei chunk autorevole; la cattura prima degli shard assicura che i metadati riflettano lo stato del cluster precedente al backup.
• Acquisisca ogni set di replica shard utilizzando lo stesso processo secondario-primo descritto sopra, il più vicino possibile nel tempo.
• Registri il timestamp oplog per ogni shard al momento dell’acquisizione. Questi timestamp sono necessari se il ripristino point-in-time deve allineare gli stati degli shard durante il recupero.
• Riabiliti il bilanciatore una volta confermato il completamento di tutti i backup degli shard.

MongoDB Atlas realizza tutto questo per i cluster sharded ospitati da Atlas in modo automatico. Per quanto riguarda gli ambienti autogestiti, Percona Backup for MongoDB ha l’opzione di eseguire un backup coordinato del cluster sharded senza la necessità di gestire manualmente il bilanciatore.

Come si assicura che i backup siano coerenti quando si utilizza il journaling e WiredTiger?

Il motore WiredTiger (motore di archiviazione predefinito per MongoDB) scrive i dati tramite una combinazione di checkpoint e journaling. Almeno una volta ogni 60 secondi (o quando il journal raggiunge una certa soglia di dimensione), WiredTiger scrive un checkpoint coerente su disco. Tutte le scritture su disco vengono registrate tra i checkpoint. Pertanto, i file di dati + il journal conterranno sempre l’intero stato recuperabile del sistema.

Per il backup di MongoDB basato su snapshot, questo significa che è possibile ripristinare in modo sicuro un’istantanea del filesystem scattata in qualsiasi momento mentre il journaling è abilitato. L’istantanea può trovarsi tra due checkpoint, ma WiredTiger riprodurrà il journal automaticamente all’avvio per raggiungere la coerenza.

L’unico requisito è che sia il journal che la directory dei dati devono trovarsi nella stessa operazione di snapshot. Non è possibile eseguire un’istantanea separata della directory dei dati e un’altra istantanea della directory del journal – questo rompe la garanzia di ripristino.

Quali sono i passaggi per ripristinare MongoDB dai backup?

Una strategia di backup da cui non è mai stato effettuato un ripristino non è testata per definizione. Il processo di ripristino richiede lo stesso livello di documentazione e pratica del processo di backup, poiché ogni momento in cui è necessario non è mai tranquillo.

Come si ripristina un database di backup MongoDB e si conservano gli utenti e i ruoli?

Le informazioni sugli utenti e sui ruoli in MongoDB sono contenute nel database di amministrazione e non nelle collezioni che governano. Un’operazione di mongorestore contro un database specifico non ripristinerà gli utenti e i ruoli per quel database. Un ripristino completo (che riscrive anche il database amministrativo ) può rimuovere inconsapevolmente gli utenti esistenti o duplicare quelli in conflitto.

Il processo di ripristino più sicuro con la conservazione di utenti e ruoli consiste in:

1. Interrompere tutte le connessioni applicative all’istanza di destinazione prima di iniziare il ripristino. Le connessioni attive durante un ripristino creano condizioni di gara tra le scritture in arrivo e il processo di ripristino.
2. Ripristini prima il database di destinazione, escludendo il database amministrativo : mongorestore –db <dbname> –drop <dump_path>/<dbname>.
3. Ispezioni il databaseadmin scaricato prima di ripristinarlo – in particolare le collezioni system.users e system.roles – per verificare che non ci siano conflitti con gli utenti esistenti sull’istanza di destinazione.
4. Ripristini gli utenti e i ruoli in modo selettivo utilizzando mongorestore –db admin –collection system.users e system.roles, piuttosto che ripristinare l’intero database amministrativo in un unico passaggio.
5. Verifichi l’assegnazione dei ruoli dopo il ripristino eseguendo db.getUsers() e confermando che gli account del servizio applicativo hanno i privilegi previsti.
6. Riabiliti le connessioni alle applicazioni solo al termine della verifica.

Si consiglia di utilizzare il flag –drop (abbandona ogni collezione prima del ripristino) quando si esegue un ripristino completo. Tuttavia, deve essere usato con cautela quando si esegue il ripristino in un’istanza che contiene già i dati che desidera conservare.

Come si ripristina un’istantanea fisica e si riportano i membri in un set di replica?

Il ripristino di un’istantanea fisica prevede due fasi distinte: prima devono essere ripristinati i file di dati e poi il nodo deve essere aggiunto nuovamente al set di replica.

Considerare questo processo come un unico processo è spesso la causa di molti problemi.

Fase 1 – Ripristino dell’istantanea:

1. Arrestare completamente il processo mongod sul nodo di destinazione prima di toccare qualsiasi file di dati.
2. Cancellare la directory dati esistente per evitare che WiredTiger incontri file di archiviazione in conflitto all’avvio.
3. Montare o copiare l’istantanea nella directory dati, assicurandosi che sia i file dati che la directory journal siano presenti e intatti.
4. Avviare mongod in modalità standalone – senza il flag –replSet – per consentire a WiredTiger di completare il suo passaggio di ripristino e raggiungere un checkpoint pulito prima di riprendere le operazioni di set di replica.

Fase 2 – Reintegrazione nel set di replica:

1. Spenga il mongod standalone una volta che il passaggio di ripristino è stato completato in modo pulito.
2. Riavvii mongod con il flag–replSet ripristinato al nome originale del set di replica.
3. Aggiunga nuovamente il membro utilizzando rs.add() dal primario, se è stato rimosso, o permetta che si ricongiunga automaticamente se era solo temporaneamente offline.
4. Monitorare il progresso della sincronizzazione iniziale – se l’istantanea è sufficientemente recente, il membro applicherà solo le voci dell’oplog che ha perso, anziché eseguire una sincronizzazione iniziale completa da zero.

Nota importante: un’istantanea più vecchia della finestra di conservazione dell’oplog attiverà un processo di sincronizzazione iniziale completo, indipendentemente da altre circostanze, che può essere un processo lungo quando si tratta di dataset grandi e complessi.

Come si esegue un ripristino point-in-time utilizzando i backup oplog o cloud?

Il ripristino point-in-time è un processo in due fasi, indipendentemente dal fatto che venga eseguito tramite oplog replay su un cluster autogestito o tramite l’interfaccia Atlas. La prima fase prepara la scena, prendendo un’istantanea completa dello stato del cluster prima del punto di ripristino. La seconda fase prende questa istantanea e la fa avanzare riproducendo solo le operazioni tra l’istantanea e il timestamp di destinazione.

Per il recupero autogestito basato su oplog, mongorestore accetta il flag –oplogReplay insieme a un dump acquisito con –oplog. Il flag –oplogLimit specifica il timestamp massimo – in secondi dall’epoca – oltre il quale le voci oplog non vengono più applicate. L’identificazione del timestamp corretto richiede l’ispezione dei registri oplog o delle applicazioni per individuare l’ultima operazione ‘buona’ prima dell’evento che ha innescato il ripristino.

Per il ripristino point-in-time di Atlas, l’intero processo si svolge utilizzando l’interfaccia utente o l’API di Atlas. Si seleziona un timestamp di destinazione all’interno della finestra di conservazione, Atlas costruisce il ripristino internamente e il cluster recuperato viene fornito come un’istanza nuova. Il cluster originale non viene sovrascritto per impostazione predefinita, preservando la sua capacità di confrontare gli stati prima di impegnarsi nel punto di ripristino.

In entrambi gli scenari, l’unico passo che tutti i team tendono a saltare quando sono sotto pressione è la verifica dello stato recuperato, prima di smantellare la macchina di produzione. Questa fase è anche quella che scopre indici mancanti, permessi utente errati e recuperi incompleti prima di arrivare in produzione.

Come si gestiscono le discrepanze di versione tra il backup e le versioni di MongoDB di destinazione?

Esiste un pericolo reale nel ripristinare un backup di MongoDB da un intervallo di versioni a un altro. Il formato di archiviazione di WiredTiger può cambiare, così come lo schema oplog e i flag di compatibilità delle funzioni, causando il mancato completamento del backup o un database che si avvia ma non funziona correttamente.

Alcuni degli esempi più comuni di scenari di ripristino sono:

Il flag Feature Compatibility Version (FCV) è il meccanismo che MongoDB utilizza per limitare l’accesso alle funzioni specifiche della versione. Un database ripristinato da un backup 6.0 su un’istanza 7.0 inizierà con FCV impostato su 6.0, limitando l’accesso alle funzioni solo di 7.0 fino a quando non viene eseguito esplicitamente setFeatureCompatibilityVersion .

Non aggiorni FCV prima che il database ripristinato sia stato convalidato – non è possibile tornare indietro una volta impostato.

Quando il disallineamento di versione è inevitabile, è meglio ripristinare i dati in un sistema con la stessa versione della fonte di backup, convalidare i dati e poi eseguire un aggiornamento standard in-place.

Come automatizzare e programmare i backup di MongoDB in modo affidabile?

Un backup di MongoDB che richiede una persona che lo avvii non è una strategia. È un’abitudine, e le abitudini relative ai processi di backup manuali sono spesso dimenticate durante le emergenze. L’automazione elimina l’elemento umano da questa equazione, ma può essere utile solo se sopravvive alle situazioni che rendono necessari i backup: un server molto carico, una rete inaffidabile o un problema di infrastruttura.

Quali modelli di pianificazione minimizzano il carico e soddisfano il suo RTO/RPO?

La pianificazione dei backup è sempre un compromesso tra frequenza e impatto. L’esecuzione di un mongodump su un primario ad alta densità di scrittura ogni ora aiuta a soddisfare RPO aggressivi, ma fa sì che i backup competano con il traffico di produzione per le stesse prestazioni di I/O. La soluzione in questo caso non è l’esecuzione di un mongodump su un server primario ad alta densità di scrittura. La soluzione non è quella di eseguire meno backup, ma di affrontare i backup in modo più intelligente.

La regola numero uno è eseguire il backup nelle ore non di punta. Per la maggior parte dei casi, ciò significa tarda notte o prima mattina nel fuso orario degli utenti principali. Tuttavia, ci sono alcune eccezioni che potrebbero non avere affatto un “periodo di calma”, come le piattaforme analitiche, le applicazioni finanziarie o le applicazioni distribuite a livello globale. In queste situazioni, l’offloading del backup su un secondario replicato è un passo essenziale, anziché opzionale.

La regola numero due è quella di allineare i tipi di backup e la loro frequenza. L’esecuzione di backup completi è costosa – eseguirli quotidianamente o settimanalmente è più che sufficiente nella maggior parte dei casi. I backup incrementali di MongoDB o i processi di archiviazione oplog colmano i vuoti tra i backup completi – di solito vengono eseguiti ogni ora o addirittura in modo continuo, senza alcun impatto notevole sulle prestazioni.

Tenendo conto di questo, possiamo creare una breve tabella con i suggerimenti per le diverse opzioni di frequenza di backup:

Come si possono rendere resilienti e idempotenti gli strumenti di orchestrazione, gli script o i cron job?

La condizione di fallimento più frequentemente osservata per un processo di automazione del backup e del ripristino di MongoDB è uno script che fallisce silenziosamente. Un cron job che esiste con un codice non nullo, non scrive dati sul target e non emette avvisi può passare inosservato per giorni o addirittura settimane. La prima indicazione di un lavoro di questo tipo è solitamente il fallimento di un’operazione di ripristino che non riesce a trovare i dati che deve ripristinare.

La resilienza inizia con la gestione esplicita dei guasti. Ogni script di backup deve verificare che l’output prodotto non sia vuoto e rientri in un intervallo di dimensioni previsto, prima di uscire con successo. Un mongodump che completa ma scrive un archivio quasi vuoto – cosa che accade quando i problemi di connessione interrompono l’esportazione a metà strada – deve essere trattato come un fallimento, non come un successo. I codici di uscita da soli non sono sufficienti.

L‘idempotenza è importante quando i backup fanno parte di una pipeline di orchestrazione più ampia. Un lavoro di backup che è sicuro di essere eseguito due volte senza preoccuparsi di produrre un duplicato o artefatti in conflitto è molto più facile da recuperare se uno schedulatore lo avvia due volte a causa di una sovrapposizione di tempi o di una logica di ritentazione. Questo crea la necessità di avere un output di scrittura verso destinazioni denominate in modo univoco – nomi di file con timestamp o chiavi di archiviazione degli oggetti – mentre si utilizzano operazioni di spostamento atomiche invece di scrivere direttamente sul percorso finale. Un backup scritto parzialmente che si trova nel percorso di destinazione (indistinguibile da uno completo) è una delle modalità di fallimento più insidiose dell’intera pipeline di backup e ripristino di MongoDB.

Quando si tratta di team con strumenti infrastrutturali esistenti, strumenti come Ansible, Kubernetes CronJobs e Airflow possono offrire ambienti di esecuzione molto più osservabili e controllabili rispetto a cron grezzo. Offrono una logica di ripetizione integrata, una cronologia di esecuzione e dei ganci di avviso che il cron di base semplicemente non ha.

Come monitorare i lavori di backup e avvisare in caso di fallimento?

Il monitoraggio di una pipeline di backup di MongoDB non si limita a verificare se il lavoro è stato eseguito o meno. Un lavoro che viene eseguito ma che genera un backup corrotto o incompleto è molto peggio di un lavoro che fallisce clamorosamente, perché solo la prima situazione crea un senso di falsa sicurezza. Le metriche che vale la pena monitorare in queste situazioni sono:

• I lavori di backup segnalano il successo, ma la dimensione del file di output è diminuita in modo significativo rispetto all’esecuzione precedente – un segno di acquisizione parziale o di interruzione della connessione a metà del dump.
• La durata del backup è aumentata in modo sostanziale senza un corrispondente aumento del volume dei dati – spesso un indicatore precoce di una contesa I/O o di un ritardo di replica sul secondario di origine.
• La posizione di archiviazione di destinazione non ha ricevuto un nuovo backup entro la finestra prevista – coglie i casi in cui il pianificatore stesso è fallito o il lavoro è stato silenziosamente saltato.
• I risultati dei test di ripristino, che dovrebbero essere eseguiti regolarmente su un backup campione, mostrano errori o producono un database che non supera i controlli di convalida a livello di applicazione.

Gli avvisi per queste condizioni devono essere inviati alla stessa pipeline di chiamata degli avvisi dell’infrastruttura, non a una casella di posta separata che viene controllata solo sporadicamente.

In che modo la sicurezza e la conformità influiscono sulle pratiche di backup di MongoDB?

Un backup è un duplicato dei dati critici che viene archiviato in un luogo al di fuori del confine di sicurezza del database di produzione. Tutti i controlli di accesso, i livelli di crittografia e l’auditing devono essere sicuri almeno quanto il database di produzione, se non di più.

Come devono essere crittografati i backup a riposo e in transito?

La crittografia a riposo assicura che i file di backup archiviati su disco, nastro o oggetto siano illeggibili senza la chiave di decrittografia corrispondente.

Per i file di backup di MongoDB scritti su object storage, ciò significa attivare la crittografia lato server sul bucket di destinazione – AES-256 tramite AWS S3, Google Cloud Storage o Azure Blob Storage – o crittografare l’archivio di backup prima che lasci il sistema di origine (con uno strumento come GPG). La chiave di crittografia deve essere archiviata separatamente dal backup stesso; una chiave archiviata accanto ai dati che protegge non offre una protezione significativa.

La crittografia in transito assicura che i dati di backup che si muovono tra l’istanza MongoDB, l’agente di backup e la destinazione di archiviazione non possano essere intercettati.

Il TLS deve essere applicato a tutte le connessioni di mongodump utilizzando il flag –tls e la corrispondente configurazione del certificato. Per le soluzioni di backup gestite dalla piattaforma, come Atlas Backup o Bacula Enterprise, la crittografia del trasporto è gestita dalla piattaforma – ma vale comunque la pena verificare che la configurazione imponga il TLS, anziché limitarsi a supportarlo come opzione.

Come controllare l’accesso ai backup e applicare il privilegio minimo?

I file di backup di MongoDB devono avere gli stessi controlli di accesso del database di produzione. È importante cercare di limitare il più possibile il numero di utenti e applicazioni che possono leggere/scrivere o eliminare i file di backup, utilizzando le seguenti misure:

• I bucket o i volumi di archiviazione di backup devono negare l’accesso pubblico per impostazione predefinita, con l’accesso concesso solo agli account di servizio specifici e ai ruoli IAM richiesti dalla pipeline di backup.
• L’accesso umano ai file di backup deve richiedere un’approvazione esplicita ed essere registrato – i test di ripristino di routine devono utilizzare un account di ripristino dedicato con privilegi inferiori, piuttosto che le credenziali amministrative.
• Le autorizzazioni di scrittura e di eliminazione sulle destinazioni di backup devono essere separate – il sistema che crea i backup non deve avere la capacità di eliminarli, il che limita il raggio d’azione di un agente di backup compromesso.
• I registri di accesso ai backup devono essere conservati indipendentemente dai file di backup stessi, in modo che la cronologia degli accessi sopravviva anche se i backup vengono eliminati.
• Se possibile, si dovrebbe utilizzare l’archiviazione cross-account o cross-project, assicurando che un ambiente di produzione compromesso non conceda automaticamente l’accesso ai dati di backup.

In che modo le politiche di conservazione e i requisiti di eliminazione dei dati influiscono sulla strategia di backup?

La politica di conservazione nel backup si muove in due direzioni opposte. L’aspetto operativo suggerisce una preferenza verso un periodo di conservazione dei backup molto lungo – più indietro si può ripristinare, più scelte di backup ci sono. L’aspetto della conformità (GDPR, CCPA, HIPAA) suggerisce una preferenza per l’eliminazione: se un utente richiede l’eliminazione dei dati dal sistema attivo, allora devono essere eliminati anche dai backup.

Questo crea una vera e propria tensione per la strategia di backup di MongoDB. Un backup immutabile che non può essere modificato o cancellato soddisfa i requisiti di protezione dal ransomware, ma è in conflitto con il diritto alla cancellazione.

La soluzione pratica è un modello di conservazione a livelli: backup a breve termine, che sono modificabili e soggetti a richieste di cancellazione, e backup di archiviazione a lungo termine, che contengono dati anonimizzati o pseudonimizzati, dove i singoli record sono stati scrubbati prima dell’archiviazione. L’implementazione di questo richiede che la pipeline di backup sia consapevole della classificazione dei dati – quali collezioni contengono dati personali e quali no – piuttosto che trattare tutti gli output di backup di MongoDB come equivalenti.

Come si applicano i backup immutabili e la protezione da ransomware a MongoDB?

Gli eventi ransomware che prendono di mira l’infrastruttura di backup si concentrano sulla distruzione delle opzioni di ripristino prima della distribuzione del payload ransomware. Se l’aggressore ha la possibilità di eliminare o criptare i file di backup, la principale difesa contro il pagamento di un riscatto viene distrutta. I backup immutabili (file che non possono essere modificati o eliminati per una durata specifica) sono una delle diverse opzioni per eliminare questa possibilità.

I meccanismi che impongono l’immutabilità a livello di storage includono:

• S3 Object Lock in modalità compliance impedisce la cancellazione o la sovrascrittura degli oggetti di backup per il periodo di conservazione configurato, anche da parte del proprietario dell’account o degli utenti amministrativi.
• L’archiviazione WORM (Write Once Read Many) sui sistemi on-premises fornisce una protezione equivalente per le infrastrutture di backup su nastro e su disco.
• Account cloud o unità organizzative separate per l’archiviazione di backup assicurano che le credenziali compromesse nell’ambiente di produzione non consentano l’accesso all’account di backup.

In che modo i backup air-gapped o offline possono ridurre l’impatto delle violazioni?

Un backup air-gapped è fisicamente o logicamente disconnesso da qualsiasi rete che un aggressore potrebbe raggiungere dall’ambiente di produzione.

Per il backup di MongoDB, questo significa tipicamente l’esportazione periodica su nastro, disco offline o un ambiente cloud senza accesso programmatico dai sistemi di produzione. Il punto di ripristino di un backup air-gapped è limitato dalla frequenza con cui il gap viene attraversato per scrivere nuovi dati – i trasferimenti giornalieri o settimanali sono comuni – rendendo le copie air-gapped le più adatte a fungere da livello di ripristino di ultima istanza, piuttosto che il driver principale del flusso di lavoro di ripristino del database.

Anche in questo caso il compromesso è intenzionale: un backup più lento e meno frequente che sopravvive a una compromissione totale dell’infrastruttura è più prezioso in uno scenario peggiore di un backup continuo che viene crittografato insieme a tutto il resto.

Quali sono le migliori pratiche per i backup di produzione di MongoDB?

Le sezioni precedenti trattano singole strategie, strumenti e procedure in modo isolato. Le best practice sono ciò che le tiene insieme in un ambiente di produzione: gli standard minimi, i requisiti di documentazione e le metriche di salute che assicurano che un’architettura di backup MongoDB rimanga affidabile nel tempo, anziché degradarsi silenziosamente man mano che l’infrastruttura e i team cambiano ed evolvono.

Quali sono le politiche minime che ogni implementazione di produzione dovrebbe avere?

La politica minima di backup MongoDB accettabile dipende dalla criticità dell’implementazione. Un ambiente di sviluppo e un database di produzione regolamentato non richiedono gli stessi controlli, ma entrambi richiedono qualcosa di deliberato e testato. La tabella seguente definisce i requisiti di base per livello di distribuzione:

Due requisiti si applicano universalmente, indipendentemente dal livello. In primo luogo, ogni backup deve essere archiviato in una posizione separata dall’istanza che protegge: un backup che vive sullo stesso disco del database di cui esegue il backup non è un backup, ma una copia. In secondo luogo, ogni strategia di backup deve includere almeno un ripristino testato prima di essere considerata operativa. Una configurazione che non è mai stata ripristinata con successo è una supposizione, non una politica.

Come documenta le procedure di backup e di ripristino per i team di reperibilità?

La documentazione di backup che esiste solo nella testa dell’ingegnere che ha costruito la pipeline fallisce nel momento in cui quell’ingegnere diventa irraggiungibile, che di solito è il momento esatto in cui è più necessario. I runbook devono essere scritti per l’ingegnere che non ha mai toccato questo sistema prima d’ora, poiché è assolutamente possibile che sia lui ad eseguire un ripristino alle 2 del mattino dopo un incidente.

Una documentazione efficace per il backup e il ripristino del database MongoDB include:

• La posizione di ogni destinazione di backup – i nomi dei bucket di archiviazione, i percorsi e i metodi di accesso, con le istruzioni per l’autenticazione da un ambiente pulito.
• I comandi esatti necessari per avviare un ripristino, compresi i flag, le stringhe di connessione e qualsiasi variabile d’ambiente che deve essere impostata prima dell’inizio del ripristino.
• I risultati attesi di un ripristino riuscito: come appare un avvio sano di Mongod, quali raccolte controllare e come convalidare che gli account utente e gli indici siano intatti.
• Modalità di fallimento conosciute e relative risoluzioni – errori di mancata corrispondenza della versione, sintomi di ripristino parziale e cosa fare se il backup più recente è danneggiato
• Contatti di escalation – chi chiamare se la procedura documentata non risolve l’incidente, compresi i contatti dell’assistenza del fornitore per Atlas, Bacula o qualsiasi piattaforma sia in uso.

La documentazione deve risiedere in un luogo accessibile durante un’interruzione dell’infrastruttura, non esclusivamente in un wiki che funziona sulla stessa piattaforma che si è appena guastata.

Quali metriche e SLA devono essere monitorati per la salute del backup?

La salute del backup viene misurata utilizzando più metriche operative. Una pipeline di backup tecnicamente funzionante ma che produce un output degradato – archivi più piccoli del previsto, durata crescente, finestre mancate – sta fallendo lentamente, e il fallimento diventerà visibile solo nel momento peggiore. Le seguenti metriche forniscono un avviso precoce:

Queste metriche dovrebbero essere tracciate nella stessa piattaforma di osservabilità utilizzata per il monitoraggio dell’infrastruttura – non in un foglio di calcolo e non riviste manualmente. L’avviso automatico sulle violazioni delle soglie assicura che una pipeline di backup MongoDB in degrado venga trattata con la stessa urgenza di un servizio di produzione in degrado, anziché essere scoperta dopo il fatto.

Aspetti fondamentali

• La topologia di distribuzione in MongoDB (standalone, set di replica o cluster sharded) determina quali metodi di backup sono disponibili per lei.
• Definisca i suoi RTO e RPO prima di selezionare qualsiasi strumento: sono i requisiti che ogni altra decisione deve soddisfare.
• MongoDB Atlas Backup è l’opzione gestita più semplice; Percona Backup for MongoDB (PBM) è la migliore alternativa self-hosted.
• L’archiviazione di backup deve essere crittografata, controllata negli accessi e immutabile: deve essere trattata con lo stesso rigore di sicurezza della produzione.
• Monitorare i lavori di backup per verificare le dimensioni e la durata dell’output, non solo se sono stati completati.
• Un backup che non è mai stato ripristinato è una supposizione: testi e documenti regolarmente le sue procedure di ripristino.

Conclusione

Il backup e il ripristino di MongoDB non sono processi che possono essere attivati una volta e subito dimenticati: si tratta di una disciplina operativa continua che comprende la selezione degli strumenti, la pianificazione, la sicurezza, la documentazione e i test regolari. La strategia giusta per un’istanza di sviluppo standalone non assomiglia affatto alla strategia giusta per un cluster di produzione shardato che serve dati regolamentati, e il divario tra questi due contesti è l’origine della maggior parte dei fallimenti di backup.

Le organizzazioni che recuperano in modo pulito da eventi di perdita di dati non sono quelle con gli strumenti di backup più sofisticati: sono quelle che hanno testato le loro procedure di ripristino prima di averne bisogno, hanno documentato tali procedure per le persone che non erano nella stanza quando il sistema è stato costruito e hanno trattato la salute del backup come una metrica operativa di prima classe, piuttosto che come un ripensamento.

Domande frequenti

I backup di MongoDB possono essere coerenti tra le architetture di microservizi?

Per ottenere un backup coerente tra i microservizi che mantengono ciascuno il proprio database MongoDB, è necessario coordinare i timestamp delle istantanee tra tutti i servizi simultaneamente – un problema di orchestrazione non banale. In pratica, la maggior parte dei team accetta l’eventuale coerenza tra i backup a livello di servizio e si affida alla logica di riconciliazione a livello di applicazione per gestire le lacune, piuttosto che tentare un unico backup atomico cross-service.

Come si esegue il backup di distribuzioni MongoDB multi-tenant in modo sicuro?

Le distribuzioni multi-tenant che isolano i tenant per database possono essere sottoposte a backup selettivo utilizzando il flag –db di mongodump, consentendo il ripristino per tenant senza toccare i dati degli altri tenant. Le distribuzioni che co-localizzano i dati dei tenant all’interno di collezioni condivise richiedono una logica di esportazione a livello di applicazione per ottenere lo stesso isolamento, poiché mongodump opera a livello di collezione e non può filtrare per campo del tenant in modo nativo.

In che modo le distribuzioni MongoDB containerizzate e basate su Kubernetes cambiano la strategia di backup?

Le distribuzioni MongoDB basate su Kubernetes – tipicamente gestite tramite l’Operatore MongoDB Kubernetes o uno StatefulSet – introducono un’infrastruttura effimera che rende inaffidabili le ipotesi di snapshot del filesystem. L’approccio consigliato è quello di utilizzare backup logici tramite mongodump attivati come Kubernetes CronJobs, oppure di distribuire Percona Backup for MongoDB accanto al cluster, che è progettato per operare in modo nativo in ambienti containerizzati con supporto di volumi persistenti.