Le snapshots vengono effettuate tramite l’utility nodetool, il quale permette di eseguire un backup completo dello stato attuale di un nodo, o di effettuare un backup con maggiore granularità (keyspace, table). La snapshot forza il nodo sul quale viene effettuata a svuotare le scritture presenti nella memtable e persisterle sul file system nelle relative SSTable (.db non modificabili). Successivamente viene creato un hard link di ogni *SSTable inclusa nel backup nella cartella snapshots di ciascuna tabella.

In quanto hard link e non copie dei file, una snapshot occupa pochissimo spazio aggiuntivo sul disco. Tuttavia lasciare le snapshot sul file system causa un notevole incremento nell’utilizzo dello spazio disco perchè impedisce l’eliminazione dei vecchi file eseguita a seguito del processo di compattazione (merge delle varie SSTable della stessa tabella in un unico file). Per questo motivo un approccio possibile potrebbe essere quello di copiare le snapshot su uno storage esterno, ed eliminare le snapshot dal filesystem del nodo.

Per quanto detto nelle considerazioni generali, per avere un backup consistente dell’intero cluster, l’utilizzo delle snapshots dovrebbe essere concertato tra i vari nodi del cluster, e avviato in contemporanea tramite l’utilizzo di strumenti che permettano il parallelismo dei comandi (pssh, ansible etc…​).

Lo stesso vale per i restore: Per poter effettuare il rollback dello stato del cluster ad un dato momento è necessario effettuare il restore su ogni nodo, altrimenti i nodi che non vengono ripristinati aggiornerebbero i nodi ripristinati con i dati più nuovi.

Punti critici delle snapshots:

A differenza delle snapshot effettuate tramite nodetool i backup incrementali sono una funzionalità da poter abilitare a livello di nodo. Una volta abilitata, il Cassandra crea degli hard link per ogni nuova SSTable creata a seguito di un flush della memtable dall’ultima snapshot effettuata. Non vengono creati hard link delle SSTable create a seguito della compattazione, in quando tutti i dati sono già presenti nelle varie SSTable create. Utilizzando lo stesso meccanismo degli hard link delle snapshot, anche mantenere a lungo i backup incrementali sul filesystem del nodo impedisce l’eliminazione delle vecchie SSTable causando una crescita notevole dello spazio occupato.

A differenza delle snapshot però, limitandosi alla creazione di hard link, questo meccanismo non inficia sulle prestazioni del cluster. L’utilizzo dei backup incrementali per il ripristino inoltre garantisce un’ottima granularità sul momento del ripristino desiderato (utilizzando tutti i file delle SSTable fino ad un determinato istante). Per limitare il problema dell’occupazione del disco, similmente a quanto ipotizzato per le snapshot, è possibile copiare i file dei backup incrementali su uno storage separato dal nodo, e svuotare la cartella contenente gli hard links.

Punti critici dei backup incrementali:

Essendo 2 meccanismi tra loro indipendenti e con granularità diverse è possibile sfruttare i vantaggi di entrambi con l’obiettivo di limitare lo spazio occupato dai backup, mantenendo una buona granularità per il point-in-time restore (legata alla configurazione del flush della memtable). L’idea di fondo è quella di sfruttare le snapshot come backup di base, effettuandole con cadenza predefinita (1 volta al giorno quando il cluster è scarico sarebbe un buon approccio), e sfruttare invece i backup incrementali per avere il point-in-time tra le snapshot.

In questo modo si eviterebbe di sovraccaricare l’I/O dei nodi con le snapshot e di dover mantenere tutta la storia dei backup incrementali, conservando esclusivamente quelli tra le snapshot che verranno mantenute.

Ovviamente bisognerà ugualmente far attenzione alla gestione dello spazio disco dei filesystem dei nodi:

Il processo di copia dei file dei backup incrementali su storage esterni potrà essere effettuato con la periodicità desiderata, tenendo presente però che un eventuale fallimento del nodo comporterà la perdita dei dati dall’ultima sincronizzazione effettuata.

Il restore dei dati ad un determinato momento comporterà l’utilizzo dell’ultima snapshot catturata prima dell’istante desiderato più le SSTable dei backup incrementali fino ad esso (solo quelle più recenti della snapshot utilizzata).

I commit log sono dei file che contengono tutte le transazioni effettuate sul nodo del cluster. Qualsiasi operazione, prima di essere effettuata nella memtable del nodo viene persistita su filesystem, in modo da avere lo storico delle transazioni da utilizzare come fault tolerance. Quando un nodo smette di funzionare, al suo riavvio la memtable viene riempita con tutte le transazioni presenti nei commit log.

Analogamente ai backup incrementali, è possibile sfruttare i commit log archiviandoli, per ottenere un point-in-time recovery molto preciso, affiancandone l’utilizzo alle snapshots.

Dunque in caso di necessità di recovery si utilizzerebbe la snapshot più recente antecedente al momento desiderato e tutti i commit log contenenti le transazioni successive alla snapshot. A differenza dei meccanismi precedentemente descritti i commit log non interferiscono con la normale compattazione delle SSTable del Cassandra.

Pro:

Contro:

Ovviamente c’è la possibilità di combinare tutte e 3 i tipi di backup in modo da avere un point-in-time recovery molto preciso e tamponare parzialmente i contro di ciascuno. Questo implica una gestione accurata dello spazio disco del nodo, e un processo di recovery più complesso, che si dovrà avvalere di tutti e 3 i layers.