Chat with us, powered by LiveChat
Richiedi il Prezzo
WW +41 21 641 6080 | US +1 800 256 0192 | CA +1 800 935 0725 | FR +33 261 880008 | UK +44 808 1890445
Contatti
Principale > Backup dei dati corporativo > Strumenti di backup dei dati aziendali > Soluzione di backup MongoDB di livello aziendale per implementazioni su larga scala

Soluzione di backup MongoDB di livello aziendale per implementazioni su larga scala

Eseguire backup e ripristini granulari di MongoDB su server, set di repliche e cluster shardati

I database NoSQL come MongoDB sono in grado di gestire enormi quantità di traffico e dati grazie a un’architettura scalabile che li rende una soluzione preziosa per le aziende che gestiscono milioni di utenti simultanei.

Detto questo, il backup di un cluster NoSQL presenta di per sé una serie di sfide relative alla coerenza dei dati che le soluzioni di backup tradizionali non riescono a superare, dato che la copia dei file grezzi del database mentre il server è in esecuzione può produrre un artefatto incoerente o non ripristinabile, poiché i file possono subire modifiche tra una lettura e l’altra

Il plugin di backup e ripristino per MongoDB di Bacula Enterprise si interfaccia direttamente con il motore di MongoDB e automatizza i backup logici su un database attivo per server autonomi e set di repliche senza interrompere le operazioni di scrittura. Per quanto riguarda invece i cluster shardati, è necessario soddisfare prima alcuni prerequisiti per automatizzare il backup logico.

Inoltre, l’architettura isolata a cinque moduli di Bacula limita l’estensione del danno in caso di violazione del database MongoDB e garantisce un ripristino rapido quando l’architettura è combinata con la segmentazione di rete, credenziali univoche e TLS reciproco.

Scarica la versione di prova

Principali vantaggi della soluzione di backup e ripristino di MongoDB

  • Backup coerenti dei database MongoDB attivi – Il plugin MongoDB di Bacula evita gli artefatti incoerenti generati dalla semplice copia dei file, utilizzando direttamente lo strumento mongodump di MongoDB. Per i server standalone, ciò produce uno snapshot logico del contenuto del database. Per i replica set, invece, il plugin genera una catena di ripristino completamente coerente aggiungendo i metadati dell’oplog al dump.
  • Backup logico coordinato per cluster MongoDB frammentati – Il plugin MongoDB di Bacula offre alle implementazioni di cluster frammentati un percorso di backup logico coordinato senza richiedere script di orchestrazione personalizzati. Acquisisce i dati delle applicazioni tramite mongos insieme ai metadati di instradamento per il ripristino logico dei dati applicativi. Detto questo, la coerenza tra i frammenti dipende dall’arresto del bilanciatore e dal blocco delle operazioni di scrittura per tutta la durata del backup.
  • Ripristino granulare di MongoDB a livello di database e collezione – Con il plugin MongoDB, è possibile filtrare e ripristinare database specifici o singole collezioni senza dover ricorrere al ripristino dell’intero cluster di database. Di conseguenza, i tempi di ripristino si riducono notevolmente e il rischio di sovrascrivere dati integri insieme a quelli danneggiati viene significativamente ridotto. *Il ripristino granulare a livello di collezione si applica agli artefatti logici completi e non può essere combinato con la riproduzione dell’oplog, il che significa che non è possibile ripristinare una collezione specifica a un punto preciso nel tempo con un’unica operazione.
  • Ripristino a un punto nel tempo (PITR) per i set di repliche MongoDB – Poiché una migrazione dello schema mal riuscita o l’eliminazione accidentale di una collezione possono cancellare ore di scritture, il plugin MongoDB di Bacula registra segmenti del log delle operazioni in ogni processo incrementale e differenziale per fornire un ripristino preciso a un punto nel tempo (PITR). Il parametro replay_to consente di interrompere la riproduzione in qualsiasi punto all’interno della finestra oplog disponibile. Questa funzionalità permette di ripristinare il set di repliche allo stato protetto più vicino a quello precedente al verificarsi dell’incidente.

Caratteristiche principali del plugin MongoDB di Bacula

Integrità dei dati e sicurezza degli accessi

  • Verifica della continuità della catena prima del ripristino – Ogni volta che viene avviato un ripristino, il plugin MongoDB verifica automaticamente l’integrità del checksum, l’identità della catena, il collegamento al genitore, l’impronta digitale della sorgente e i confini dell’oplog. Se manca qualcosa o vi è una discrepanza, il plugin blocca il ripristino prima che possa raggiungere il database.
  • Supporto dell’autenticazione TLS e MONGODB-X509 – Il plugin MongoDB si connette ad ambienti MongoDB protetti senza compromettere in alcun modo gli standard di autenticazione. Supporta il protocollo TLS sia a livello di connessione del driver Java che a livello dello strato MongoDB Database Tools; SCRAM per l’autenticazione basata su password; e MONGODB-X509 per l’autenticazione basata su certificati, in cui il nome utente MongoDB deve corrispondere esattamente al soggetto del certificato del client. Inoltre, le credenziali di connessione vengono gestite tramite un file password_file per isolarle dai log dei processi e dall’output di configurazione.
  • Metadati di manifesto e catena per la verificabilità – Ogni processo di backup di MongoDB produce una registrazione completa e verificabile di ciò che è stato sottoposto a backup, inclusa la versione di origine, la topologia, i database selezionati e i checksum. Questi file di metadati viaggiano insieme agli artefatti di backup nel catalogo di Bacula sotto /@mongodb e sono disponibili per l’audit e la pianificazione del ripristino senza intervenire sull’ambiente attivo.

Infrastruttura di backup adattiva

  • Supporto per il backup multi-topologia – Il plugin supporta tutti e tre i tipi di distribuzione di MongoDB (ovvero server standalone, replica set e cluster shardati) e il comportamento del backup si adatta automaticamente alla topologia, senza alcun tipo di intervento manuale. I server standalone vengono sottoposti a un backup logico completo tramite mongodump. I set di replica vengono sottoposti a un backup completo che avvia una catena di ripristino, seguito da processi incrementali e differenziali che registrano i segmenti dell’oplog. I cluster shardati vengono sottoposti a backup tramite mongos, con i metadati di instradamento acquisiti insieme ai dati dell’applicazione.
  • Report di simulazione per backup e ripristino – Il comando dry_run=yes genera un report completo di ciò che il backup o il ripristino eseguirebbero, senza scrivere o modificare nulla, in modo che eventuali errori di configurazione o problemi di compatibilità vengano individuati ben prima che il processo venga eseguito in un ambiente di produzione. Per il backup, ciò verifica la connessione, la topologia, le autorizzazioni, la compatibilità degli strumenti e lo spazio di lavoro disponibile.

Set completo di funzionalità del plugin MongoDB

Il ripristino a un punto nel tempo, insieme alle altre funzionalità elencate in precedenza, rappresenta solo una parte del quadro più ampio di ciò che il plugin può offrire per il backup e il ripristino del database MongoDB. Di seguito è possibile vedere l’ampia gamma di funzionalità che il plugin offre alle grandi imprese con milioni di utenti simultanei.

Funzionalità di backup

  • Backup completi, incrementali e differenziali – Il plugin supporta tutti e tre i livelli di job. I set di repliche ottengono vere e proprie catene basate su oplog; mentre le distribuzioni standalone e shardate ottengono artefatti logici di tipo completo a ogni livello.
  • Backup logico tramite mongodump – Ogni backup è un artefatto logico prodotto dallo strumento mongodump di MongoDB, che mostra il contenuto effettivo del database al momento dell’esecuzione del job.
  • Filtraggio di database e collezioni – I filtri di inclusione ed esclusione consentono di limitare qualsiasi processo di backup a database specifici o singole collezioni.
  • Acquisizione dei metadati di routing dei cluster frammentati – Per le distribuzioni frammentate, il plugin registra l’appartenenza ai frammenti e i metadati di routing insieme ai dati dell’applicazione per supportare la pianificazione del ripristino a livello di applicazione tramite mongos. Ciò riguarda esclusivamente il recupero logico dei dati dell’applicazione.

Funzionalità di ripristino

  • Ripristino a un punto nel tempo per i set di repliche – Il parametro replay_to interrompe la riproduzione dell’oplog in qualsiasi punto all’interno della finestra dell’oplog disponibile. La precisione del ripristino dipende dalla conservazione dell’oplog, dalla frequenza dei processi e dall’ultimo confine di catena acquisito con successo.
  • Ripristino in streaming su mongorestore – I payload degli archivi completi vengono trasmessi in streaming direttamente dallo storage di Bacula a mongorestore senza scrivere prima gli archivi di dump completi sul disco locale.
  • Ripristino tra host – Il plugin trasmette in streaming gli artefatti in mongorestore su qualsiasi destinazione valida, il che supporta i test in sandbox e le migrazioni di cluster. Detto questo, la portabilità del formato logico non garantisce che ogni combinazione di versione del server, versione di Database Tools, FCV, definizione dell’indice o funzionalità di raccolta possa essere ripristinata.
  • Controllo della strategia di conflitto – Il parametro conflict_strategy controlla il modo in cui il plugin gestisce i dati esistenti sulla destinazione di ripristino. È possibile impostare conflict_strategy=fail tramite la sessione di ripristino di Bacula per i ripristini di convalida, e conflict_strategy=drop solo quando i dati esistenti sulla destinazione possono essere sostituiti in tutta sicurezza.

Sicurezza

  • Supporto delle connessioni TLS – Il protocollo TLS è supportato sia a livello di connessione del driver Java che a livello del layer MongoDB Database Tools.
  • Autenticazione SCRAM e MONGODB-X509 – Il plugin supporta inoltre l’autenticazione SCRAM basata su password e l’autenticazione MONGODB-X509 basata su certificati, per la quale il nome utente MongoDB deve corrispondere alla lettera al soggetto del certificato client.
  • Isolamento delle credenziali tramite password_file – Le credenziali di connessione sono gestite tramite un password_file. Non sono incorporate negli URI, il che le mantiene separate dai log delle operazioni e dall’output di configurazione.
  • Utente di backup con privilegi minimi – Il plugin è progettato per essere eseguito con un utente di backup MongoDB dedicato, al quale sono concessi solo i privilegi necessari per la modalità di backup selezionata.

Plugin di backup e ripristino di MongoDB: confronto tra le topologie

Il plugin MongoDB adatta il proprio comportamento di backup in base alla topologia di distribuzione a cui è collegato. La tabella sottostante illustra le funzionalità supportate da ciascuna topologia, in modo da facilitare la pianificazione della strategia di backup e delle aspettative di ripristino prima dell’esecuzione del primo processo.

Funzionalità Autonomo Set di repliche Cluster frammentato
Backup completo Sì Sì Sì
Incrementale / Differenziale Artefatti logici di tipo completo (senza catena oplog) Catena vera e propria basata su oplog Ripristino dei dati dell’applicazione
Ripristino a un punto nel tempo (PITR) No Sì — tramite replay_to No
Acquisizione dell’oplog No Sì — Processi incrementali e differenziali No
Convalida della continuità della catena No Sì — prima di ogni ripristino No
Acquisizione dei metadati di routing No No Sì — appartenenza ai shard e configurazione di instradamento
Richiesta protezione del bilanciatore No No Sì
(1) il bilanciatore deve essere arrestato; (2) migrazioni dei chunk disabilitate; (3) scritture impedite per la durata del dump
Destinazione della connessione Mongod primario Primario scrivibile (URI del set di repliche preferito) Solo mongos
Metodo di ripristino Ripristino logico completo tramite mongorestore Riproduzione della catena convalidata tramite mongorestore Ripristino dell’applicazione tramite mongos con preparazione dell’instradamento

In che modo Bacula protegge i dati di backup di MongoDB dalle minacce informatiche?

Per contrastare i criminali informatici e proteggere le organizzazioni dal ransomware, Bacula Enterprise, scelto da grandi organizzazioni come la NASA, la Marina degli Stati Uniti e l’Aeronautica Militare degli Stati Uniti, protegge i dati di backup di MongoDB integrandosi direttamente con destinazioni di archiviazione immutabili e conformi allo standard WORM, in modo da impedire a un malintenzionato in possesso delle credenziali di modificare, rietichettare o, peggio ancora, cancellare i dati fino alla scadenza del periodo di conservazione configurato.

Architettura e controllo degli accessi

  • Architettura isolata a cinque moduli – Nell’architettura a cinque moduli di Bacula, il File Daemon (client), il Director, lo Storage Daemon, la Console e il database del Catalogo operano come componenti separati. Questo tipo di separazione limita l’impatto di un componente compromesso, in particolare se combinata con la segmentazione della rete, credenziali univoche per ogni componente, TLS reciproco e controlli di accesso basati sul principio del privilegio minimo.
  • Privilegi limitati del File Daemon (client) – Gli amministratori possono limitare con precisione le directory da cui un client può eseguire il backup, in cui può eseguire il ripristino e in cui può eseguire script, tramite le direttive AllowedBackupDirectories, AllowedRestoreDirectories e AllowedScriptDirectories. Il File Daemon può inoltre funzionare in modalità di sola lettura, al fine di impedire qualsiasi modifica non autorizzata da quel sistema.
  • Controllo degli accessi basato sui ruoli – Bacula supporta un controllo granulare degli accessi basato sui ruoli (RBAC) tramite elenchi di controllo degli accessi (ACL) specializzati che limitano con precisione ciò che un utente della console può visualizzare e modificare. Questa sicurezza viene applicata attraverso i livelli di controllo JobACL, CommandACL, PoolACL e ScheduleACL.
  • Autenticazione a più fattori – L’accesso alla console supporta l’autenticazione a più fattori (MFA) basata su TOTP ed è conforme alla RFC 6238, oltre all’autenticazione standard tramite password e TLS. L’accesso all’interfaccia grafica web supporta separatamente l’autenticazione tramite password monouso, che include anche opzioni di verifica biometrica tramite smartphone.

Immutabilità e integrità dei dati

  • Protezione dei volumi gestita da Bacula – Bacula imposta un attributo “Append-Only” sui volumi basati su file durante il loro primo processo di backup per impedire la perdita di dati dovuta alla sovrascrittura. Una volta che un volume viene contrassegnato come “Pieno”, un flag di immutabilità può impedire che venga rietichettato o riutilizzato fino alla scadenza del suo periodo di protezione. Questi controlli vengono applicati a livello di applicazione e la loro resistenza a un attacco dipende dai privilegi del sistema operativo, dal supporto del filesystem, dai privilegi del daemon di archiviazione e dalla configurazione della conservazione.
  • Immutabilità imposta dall’hardware e dal cloud – Per un’immutabilità che resista anche agli accessi privilegiati a livello di sistema operativo, Bacula si integra con l’immutabilità controllata dall’appliance su NetApp SnapLock, DataDomain RetentionLock e HPE StoreOnce, nonché con la modalità WORM conforme alle normative e il blocco degli oggetti su AWS S3, Azure e Google Cloud Storage. A differenza dei controlli a livello di applicazione, questi vengono applicati a livello di hardware o di provider cloud e non possono essere sovrascritti dalle credenziali del sistema operativo.
  • Verifica dei processi e controllo di integrità basato su hash – Bacula è in grado di rilevare corruzioni silenziose calcolando le firme SHA256 o SHA512 dei dati dei file e confrontando lo stato attuale di un volume con la relativa voce nel Catalogo. Per la convalida dell’integrità avversaria, si noti che questo confronto si basa sul presupposto che il Catalogo rimanga integro insieme ai volumi di backup.
  • Archiviazione air-gapped – Bacula Enterprise opera interamente offline in ambienti completamente isolati, senza alcuna dipendenza da Internet. Il Director, gli Storage Daemon e i File Daemon possono essere distribuiti su reti separate, in modo che i dati di backup di MongoDB rimangano inaccessibili alle minacce esterne anche in caso di violazione a livello di rete.

Crittografia

  • Comunicazioni crittografate – I daemon di Bacula effettuano l’autenticazione tramite SCRAM-SHA-256. La crittografia TLS dovrebbe essere abilitata per tutte le comunicazioni di rete in un’implementazione sicura ed è supportata da tutti i componenti di Bacula.
  • Conformità allo standard FIPS 140-3 – Bacula Enterprise garantisce la conformità allo standard FIPS 140-3 tramite il proprio modulo crittografico, che utilizza OpenSSL-FIPS ed è certificato su diverse piattaforme. Il modulo può essere utilizzato in tutti i componenti di Bacula.
  • Crittografia dei dati inattivi – Il demone di archiviazione è in grado di crittografare un’intera destinazione di archiviazione in un’unica operazione, indipendentemente dalla fonte dei dati. Gli amministratori possono inoltre configurare la crittografia separatamente per i singoli client.

Rilevamento delle minacce

  • BGuardian Ransomware Detection – Il modulo di analisi automatizzata della sicurezza di Bacula, BGuardian, verifica la solidità della configurazione, l’utilizzo della crittografia, i modelli di manomissione dei backup e decine di altri indicatori di rafforzamento della sicurezza in tutto l’ambiente, generando report e avvisi persistenti man mano che vengono rilevati dei problemi.
  • Scansione antivirus e ricerca di malware – Bacula garantisce una difesa automatizzata dalle minacce integrando un plugin antivirus basato su ClamAV per eseguire la scansione dei file sottoposti a backup alla ricerca di virus durante i processi di verifica post-backup.

Cosa si ottiene implementando Bacula Enterprise?

Ogni implementazione di Bacula Enterprise offre le seguenti funzionalità relative al ripristino, al backup, ai prezzi e all’amministrazione della piattaforma.

Funzionalità di backup efficienti

  • Compressione adattiva – Gli algoritmi di compressione sono configurabili per ogni processo, in modo che gli amministratori possano ottimizzare la compressione in base al tipo di dati e alle risorse disponibili.
  • Backup completi, differenziali e incrementali – Bacula supporta i livelli di backup completo, differenziale e incrementale. Una strategia tipica prevede l’esecuzione iniziale di un backup completo, seguito da backup incrementali, il che evita di eseguire ripetutamente backup completi di grandi dimensioni secondo una pianificazione fissa.
  • Backup completi virtuali progressivi – Bacula può combinare un backup completo esistente con i successivi incrementali per creare un nuovo backup completo sintetico senza ricontattare il client. Il processo legge invece i dati dall’archivio di backup esistente. La direttiva Backups To Keep può ripetere questo consolidamento su base continuativa.
  • Spooling su disco prima della scrittura su nastro – Bacula può scrivere i dati di backup su uno spool su disco prima di inviarli al nastro come flusso continuo. Ciò aiuta a prevenire i movimenti di avvio e arresto del nastro che possono verificarsi quando i dati arrivano troppo lentamente per consentire all’unità di scrivere in modo continuo. Il problema è particolarmente comune con i backup incrementali e differenziali, che tendono a produrre flussi di dati più piccoli e meno costanti rispetto ai backup completi.
  • Trasferimenti attenti alla larghezza di banda – Dopo il backup iniziale, vengono trasferiti in rete solo i dati modificati. Ciò mantiene basso il traffico di rete senza richiedere limitazioni manuali della larghezza di banda o soluzioni alternative di pianificazione.
  • Pianificazione frequente dei backup – I processi di backup possono essere eseguiti ogni pochi minuti anziché una volta al giorno, riducendo la finestra di potenziale perdita di dati da ore a minuti.
  • Protezione continua dei dati – L’applicazione cdp-client monitora le modifiche ai file e li copia in una directory di spool non appena si verificano. FileDaemon invia quindi tali dati a un normale processo di backup Bacula a intervalli prestabiliti, in modo che le modifiche possano essere acquisite in pochi secondi o minuti anziché attendere il successivo backup pianificato.

Funzionalità di ripristino ultraveloci

  • Ripristino bare-metal a livello di sistema – Bacula Enterprise è in grado di ripristinare un intero server, inclusi il sistema operativo, le applicazioni, la configurazione e i dati, senza richiedere una previa installazione manuale del sistema operativo.
  • Ripristino dei dati multipiattaforma – I dati di backup possono essere ripristinati su un sistema operativo diverso da quello originale. Ciò offre ai team maggiore flessibilità durante le sostituzioni hardware, le migrazioni o altri scenari di ripristino.
  • Convalida automatica del ripristino – I test automatici consentono di verificare che i dati di backup siano recuperabili senza che un amministratore debba eseguire un processo di convalida separato.
  • Replica geografica dei backup – Per impostazione predefinita, Bacula conserva una singola copia di backup. Per creare copie aggiuntive in altre posizioni, gli amministratori possono configurare processi di copia o migrazione. Una configurazione tipica potrebbe prevedere di conservare la copia primaria su un supporto di archiviazione locale, creare una seconda copia su un altro tipo di supporto, come l’archiviazione cloud, e quindi inviare una terza copia in una sede remota o isolata (air-gapped). Questa configurazione contribuisce a garantire che un’interruzione a livello di sito non metta fuori uso tutte le copie di ripristino disponibili.

Controllo dei costi e licenze di backup prevedibili

  • Deduplicazione a livello di blocco – I blocchi di dati ripetuti vengono archiviati una sola volta nel catalogo dei backup, riducendo così il consumo di spazio di archiviazione senza richiedere modifiche alle politiche o alle pianificazioni di backup.
  • Flussi di lavoro di archiviazione a più livelli – I dati di backup possono spostarsi automaticamente tra i diversi livelli di archiviazione man mano che invecchiano. I punti di ripristino recenti possono rimanere su supporti di archiviazione più veloci, mentre i backup più vecchi vengono spostati su destinazioni a costo inferiore.
  • Licenze indipendenti dal volume – I costi di licenza non aumentano con la crescita dei dati protetti. I team possono espandere il proprio ambiente di backup senza dover sostenere costi di licenza più elevati.
  • Costi prevedibili – I prezzi fissi rendono più semplice la pianificazione dei budget per l’infrastruttura, senza costi di licenza variabili legati alla crescita dello spazio di archiviazione o alle variazioni del carico di lavoro.
  • Prezzi indipendenti dal carico di lavoro – Le dimensioni dei database, il numero di server e la quantità di spazio di archiviazione protetto non incidono sui costi di licenza.
  • Costi inferiori su larga scala – Gli ambienti di grandi dimensioni o in rapida crescita possono aggiungere dati protetti senza aumentare i costi di licenza. Rispetto ai modelli di licenza basati sulla capacità, i risparmi possono diventare più significativi man mano che i volumi di dati crescono.

Gestione e amministrazione dei backup

  • Doppia interfaccia – BWeb offre una console grafica per la gestione e il monitoraggio quotidiani dei processi. Bconsole (user agent) garantisce agli operatori il pieno controllo tramite riga di comando per la creazione di script, l’automazione e la configurazione avanzata.
  • Scalabilità senza limiti – La stessa architettura di piattaforma gestisce ambienti che vanno da pochi server a implementazioni che contano migliaia di server, il tutto sotto un unico piano di gestione.
  • Rilevamento automatico delle risorse – La piattaforma esegue una scansione dell’infrastruttura per identificare e catalogare automaticamente le destinazioni di backup. La copertura della protezione rimane aggiornata man mano che l’ambiente cresce.
  • Reportistica dettagliata – I report programmati coprono i risultati dei processi, le tendenze relative alla capacità, lo stato di conformità e le prestazioni operative con una cadenza definita.
  • Integrazione con sistemi esterni – Bacula si collega a strumenti di monitoraggio, sistemi di ticketing IT e servizi di directory, senza richiedere alcuno sviluppo personalizzato obbligatorio.

Domande frequenti

Come si esegue il backup di un database MongoDB attivo senza tempi di inattività?

Per i server autonomi e i replica set, il plugin Bacula Enterprise per MongoDB esegue mongodump su un database attivo senza interrompere le operazioni di lettura o scrittura, e il database rimane pienamente operativo per tutta la durata dei processi di backup. Detto questo, la garanzia di assenza di tempi di inattività non si applica ai backup dei cluster con partizionamento (sharded), poiché questi backup richiedono (1) l’arresto del bilanciatore di chunk tramite sh.stopBalancer(), (2) la successiva disabilitazione delle migrazioni di chunk pianificate e (3) il blocco delle operazioni di scrittura e delle trasformazioni dello schema per tutta la durata del dump. È prevedibile che le operazioni di scrittura vengano interrotte durante la finestra di backup. Eseguire prima il backup del replica set del server di configurazione, quindi acquisire ciascun replica set di shard a intervalli di tempo il più ravvicinati possibile.

Qual è la differenza tra un backup logico e uno fisico in MongoDB?

Un backup logico utilizza mongodump per esportare i documenti, gli indici e gli schemi del database in file di archivio BSON portabili. Questi archivi sono indipendenti dal motore di archiviazione sottostante e possono generalmente essere ripristinati su un server diverso, sebbene i ripristini tra versioni diverse dipendano dalla compatibilità tra le versioni di MongoDB, dalla versione di Database Tools e dalla Feature Compatibility Version (FCV). Pertanto, non è garantito che ogni combinazione funzioni. Un backup fisico, d’altra parte, copia i file di dati grezzi dal disco, il che è molto più veloce per set di dati molto grandi ma vincola l’archivio al motore di archiviazione e alla versione originali.

Come funziona il ripristino a un punto nel tempo (PITR) per i replica set di MongoDB?

Il ripristino a un punto nel tempo (PITR) è disponibile esclusivamente per i replica set. Quando è necessario un ripristino, il parametro `replay_to` interrompe la riproduzione dell’oplog in qualsiasi punto all’interno della finestra oplog disponibile e ripristina il replica set allo stato protetto più vicino all’interno di quella finestra prima che si verifichi un incidente. I server standalone e i cluster shardati non supportano il PITR tramite questo plugin perché non forniscono una catena di ripristino dell’oplog allo stesso modo dei set di replica. Se è necessario ripristinare una collezione specifica a un punto nel tempo, la procedura consigliata consiste nel ripristinare prima l’intera catena del set di replica su una destinazione non di produzione, quindi estrarre e riconciliare i dati richiesti a livello di applicazione.

È possibile ripristinare una singola collezione MongoDB senza ripristinare l’intero database?

Sì. Il plugin MongoDB di Bacula supporta filtri di inclusione ed esclusione a livello di database e di collezione, in modo che un’operazione di ripristino possa riguardare una collezione specifica senza intaccare il resto del database. Ciò consente di mantenere brevi le finestre di ripristino e limita il rischio di sovrascrivere dati integri insieme a quelli danneggiati che è necessario sostituire. Il ripristino completo del database è disponibile quando necessario, ma non è mai l’unica opzione.

Inoltre, si noti che il ripristino granulare a livello di collezione si applica agli artefatti logici completi e non può essere combinato con la riproduzione dell’oplog, il che significa che il ripristino a un punto nel tempo opera sempre sull’intero ambito del set di repliche. Se sono necessarie entrambe le operazioni, assicurarsi di ripristinare prima l’intera catena del set di repliche su una destinazione non di produzione, quindi estrarre i dati richiesti a livello di applicazione.

Perché utilizzare il plugin MongoDB di Bacula invece di eseguire mongodump manualmente?

mongodump di per sé è uno strumento valido per una singola esportazione logica. Detto questo, il suo limite è che non offre tutto ciò che viene dopo il dump (pianificazione centralizzata, conservazione automatizzata, convalida del checksum, metadati della catena di ripristino e l’elenco potrebbe continuare). Il plugin MongoDB di Bacula Enterprise integra mongodump e mongorestore all’interno del motore di policy di Bacula, in modo che ogni processo di backup di MongoDB sia opportunamente pianificato, catalogato, convalidato e recuperabile dalla stessa console che gestisce il resto dell’infrastruttura.

Ulteriori informazioni sul backup di MongoDB:

Potresti anche essere interessato a:
backup remoto
soluzioni di backup aziendale
sistema di backup aziendale