Backup e restore

Anche se tramite l’uso dei Replica Set MongoDB è più robusto ai guasti hardware, nell’amministrazione di un database il backup è necessario per assicurare la possibilità di ripristinare il funzionamento del sistema in caso di gravi errori software che hanno alterato i dati, o di attacchi informatici che ne hanno compromesso l’affidabilità.

Backup e restore di una singola istanza

Se non si usano i Replica Set, per effettuare il backup di tutti i database è sufficiente salvare una copia della cartella del database, specificata nell’avvio dell’istanza con:

mongod --dbpath <cartella>

Se non l'abbiamo specificata espressamente come sopra, tale directory è indicata nel file di configurazione con la chiave storage.dbpath. Quindi è sufficiente utilizzare una qualsiasi altra tecnica di backup di file system, ed applicarla a tale cartella. Se si utilizza Linux, si può usare una tecnica molto veloce ed efficiente basata sugli snapshot LVM. In rete sono disponibili molte guide su come attuarla, e tra queste segnaliamo quella descritta sulla guida a Red Hat.

Il processo di restore, ovvero il ripristino dei dati precedentemente archiviati tramite backup, è altrettanto semplice: basta fermare l'esecuzione di mongod e riavviarlo facendolo puntare al percorso della cartella contenente il backup.

Mongodump e Mongorestore

Per effettuare un backup di un database senza fermare il servizio e soprattutto senza dover essere loggati sul server MongoDB fornisce mongodump, una semplice utility che può essere lanciata dalla console specificando l’istanza di MongoDB:

$ mongodump -h localhost:27017

Verrà generata una cartella dump contenente i file di backup. Quando vorremo fare una il restore di questa cartella, sarà sufficiente usare il comando seguente:

$ mongorestore -h localhost:27017 --drop dump

L’opzione --drop comporta la cancellazione dell’archivio prima del restore. Se non specificato, infatti, i dati di backup verranno aggiunti alle collezioni esistenti.

Backup di un Replica Set

In ogni caso, come abbiamo detto nelle precedenti lezioni, è sempre raccomandato l’utilizzo dei Replica Set, non solo per l’alta disponibilità che offrono ma anche perché consente di ottenere un backup estremamente aggiornato dei dati.

Ciò nonostante, effettuare regolarmente il backup dei dati è importante per poter considerare errori umani, bug nei software o attacchi informatici, che causerebbero la propagazione degli errori in tutto il Replica Set.

La procedura di backup e restore può essere eseguita con le utility mongodump e mongorestore nello stesso modo che abbiamo visto nel paragrafo precedente, tranne che bisogna specificare il nome del Replica Set e l’elenco dei componenti separati da una virgola, in entrambe le righe di comando:

$ mongodump -h esempio/localhost:27018,repl1:27017,repl2:27017

La procedura più a basso livello, basata sui file, prevede invece lo spegnimento del Replica Set, quindi fondamentalmente la creazione di un nuovo Replica Set basato sulle cartelle di backup, seguendo la procedura che abbiamo visto nella lezione 14. L’unica differenza è che possiamo velocizzare la sincronizzazione delle repliche copiando i file di backup nelle cartelle che specificheremo nel parametro dbpath in ogni replica. Altrimenti, se facciamo partire le repliche da cartelle vuote, avremo un setup iniziale di durata proporzionale alla quantità di dati presenti nel backup.

Backup di un cluster

Il backup di un cluster in sharding è un’operazione intrinsecamente più delicata, per vari motivi. Prima di tutto si tratta di un database potenzialmente di grandissime dimensioni, quindi bisogna avere a disposizione lo storage necessario per fare tutto il backup. Inoltre, si tratta di un database distribuito, quindi effettuare il backup implica necessariamente problemi di sincronizzazione: possono infatti verificarsi modifiche negli shard durante il backup di un nodo, che renderebbero il backup complessivo incompleto.

In generale ci sono due modi di operare. Se si dispone di tutto lo spazio su disco necessario a contenere il backup del cluster, è sufficiente invocare mongodump specificando nell'host (opzione -h oppure --host) l’indirizzo dell’istanza mongos. Ovviamente, l’operazione richiederà un certo tempo a seconda della quantità dei dati da leggere.

Se invece, come è più probabile, non si dispone di tanto spazio quanto è necessario per archiviare tutto il cluster, bisogna effettuare una procedura un po’ più complessa che consiste nell’effettuare il backup di ogni shard singolarmente:

1. innanzitutto bisogna fermare il balancer. Questi è un servizio interno di MongoDB che si occupa di bilanciare i vari shard per fare in modo che i dati siano distribuiti abbastanza equamente tra i nodi. Se non effettuiamo questa operazione potrebbe accadere che alcuni dati vengano spostati da uno shard all’altro mentre stiamo effettuando il backup di uno di essi, con la conseguenza che, al termine della procedura, il backup potrebbe essere affetto da dati mancanti (perché spostati da uno shard che dobbiamo ancora archiviare ad uno di cui abbiamo già fatto il backup) oppure duplicati (perché è avvenuto il viceversa). Per fermare il balancer è sufficiente invocare, dalla console mongo:
   

   sh.setBalancerState(false)

2. a questo punto, se si vuole un backup completo e consistente di tutti gli shard in un certo momento, bisogna spegnere un secondario di ogni Replica Set che compone il cluster, in modo da “congelare” la situazione in quell’istante per ogni shard. Questa operazione non è strettamente necessaria, ma ci assicura che il backup sia abbastanza sincronizzato nello shard. In alternativa si può lanciare mongodump su ogni Replica Set in parallelo, come abbiamo visto nella sezione precedente. Il backup risultante potrebbe però non essere facilmente databile, poiché ogni shard inizierebbe e terminerebbe in tempi diversi; il problema comunque sussiste, anche se in misura minore, anche nel caso in cui si spengono tutti gli shard;
3. a questo punto, utilizzando mongodump, effettuiamo il backup di:
   1. un config server. Ce ne basta uno solo per memorizzare la situazione del cluster. Per farlo, dobbiamo utilizzare l’opzione --oplog:
      

      mongodump --oplog -h myconfigserver:27017

   2. di tutti secondari che abbiamo spento al punto 2. Dobbiamo essere fisicamente autenticati dentro la macchina in cui gira il server e specificare le opzioni --dbpath e --journal, perché questi servizi sono spenti:
      

      mongodump --journal --dbpath mongodata

4. adesso possiamo riavviare i secondari che abbiamo spento al punto 2;
5. infine riattiviamo il balancer che abbiamo disattivato al punto 1:
   

   sh.setBalancerState(true)

Ora abbiamo un backup, anch’esso distribuito, di tutto il cluster. Se volessimo fare un restore globale utilizzando questi file, dobbiamo:

1. fermare l'intero cluster;
2. caricare, per ogni server e ogni config server (mongos), i file nelle cartelle dei database. In alternativa si può usare mongorestore;
3. riavviare tutti i server.