Guida completa al backup e al ripristino del database Cassandra

Introduzione: Perché i backup sono importanti per Cassandra?

Cassandra è costruito per non andare mai in tilt. Il backup di Cassandra è importante, perché senza un backup adeguato, i dati importanti possono rischiare di andare persi. Sebbene la replica sia un componente importante che protegge dai guasti hardware, non protegge dalla perdita di dati. Pertanto, disporre di un backup recuperabile e conservare le copie in un luogo completamente separato è una necessità per salvaguardare tutti i suoi dati.

Quali tipi di guasti o incidenti richiedono un piano di backup e ripristino?

I piani di backup e ripristino sono necessari per i guasti logici che la replica non può risolvere. Tali problemi includono la cancellazione accidentale, la corruzione dei dati, il ransomware e gli aggiornamenti falliti. Cassandra copia ogni operazione su ogni replica simultaneamente, il che significa che se si verifica uno di questi problemi, l’intero cluster ne risente.

Di seguito, analizziamo i guasti e gli incidenti tipici che richiedono un piano di backup e ripristino.

• Cancellazione accidentale di dati: Esecuzione di DROP TABLE o TRUNCATE sul cluster sbagliato, con conseguente cancellazione dei dati da tutte le repliche.
• Corruzione dei dati: Un problema di software, hardware o file system che richiede un rollback ad uno stato stabile.
• Aggiornamenti falliti: Configurazione impropria del database o aggiornamenti che causano dati corrotti o lasciano i file SSTable in un formato incompatibile.
• Ransomware: Software dannoso che cripta le directory di dati Cassandra, rendendo i dati illeggibili.
• Insider malintenzionato: Qualcuno all’interno del team che cancella o distrugge deliberatamente i dati (uno scenario meno raro di quanto si pensi).

Quali sono le considerazioni aziendali e tecniche su RPO (Recovery Point Objective) e RTO (Recovery Time Objective)?

L’RPO e l’RTO sono due metriche importanti che determinano direttamente la frequenza con cui i backup devono essere eseguiti, o la velocità con cui il ripristino deve essere completato. Ogni decisione di backup che un’azienda prende deriva direttamente da queste due metriche:

Il Recovery Point Objective(RPO) definisce la quantità di perdita di dati che la sua azienda può tollerare, espressa in ore. Per esempio, un RPO di 4 ore significa che non può perdere più di 4 ore di dati; quindi, avrà bisogno di un backup ogni 4 ore.

L’obiettivo di tempo di ripristino (RTO), invece, definisce quanto tempo è consentito alla sua azienda di non essere disponibile mentre si concentra sul processo di ripristino. Supponiamo che il suo RTO sia di 2 ore. In questo caso, avete 2 ore per recuperare; l’azienda potrebbe avere seri problemi di salute finanziaria.

Entrambe le metriche sono importanti perché informano le decisioni aziendali che possono influenzare direttamente la sua strategia di backup Cassandra.

Quali sono i rischi di non avere una strategia di backup dei dati Apache Cassandra affidabile?

La sola replica non è sufficiente per il backup, quindi rappresenta un rischio enorme per qualsiasi azienda. Le conseguenze vanno oltre la perdita di dati, incidendo sulla continuità operativa, sulla conformità e sulla fiducia degli utenti. Ecco i principali problemi che le aziende devono affrontare senza una strategia di backup Cassandra affidabile.

• Perdita permanente dei dati: Non avere una strategia di backup o averne una inaffidabile significa non avere un percorso di recupero e, in caso di catastrofe, ciò che è perso non può essere riportato indietro.
• Tempi di inattività prolungati: Senza una strategia di backup e senza RTO e RPO chiaramente definiti, la sua azienda può finire per perdere più del previsto.
• Conformità ed esposizione normativa: settori come l’assistenza sanitaria e la finanza operano in base a normative rigorose. Senza un’adeguata strategia di backup Cassandra, la non conformità può comportare sanzioni finanziarie significative.
• Danni alla reputazione: Quando i dati degli utenti sono a rischio, le aziende possono subire un danno reputazionale duraturo, che porta a una graduale perdita di utenti e di fiducia nel tempo.

In che modo le architetture di distribuzione di Apache Cassandra influenzano le esigenze di backup?

L’architettura di distribuzione di Cassandra può influenzare pesantemente le esigenze di backup. Determina quanto rischiosa o complessa debba essere la strategia di backup. Ogni tipo di distribuzione introduce sfide specifiche che un approccio unico non può affrontare.

1. Distribuzioni multi-datacenter

Nelle implementazioni multi-datacenter, le operazioni di backup sono in genere eseguite da un datacenter secondario dedicato, anziché dai nodi di produzione, per evitare che l’attività di backup possa degradare le prestazioni live. Questo datacenter dedicato riceve gli stessi dati replicati della produzione, ma gestisce tutti i carichi di lavoro di backup separatamente, mantenendo i nodi primari liberi per il traffico degli utenti.

2. Cloud/AWS – EBS vs Instance Store

Le implementazioni in cloud su AWS richiedono approcci di backup diversi a seconda del tipo di storage. I nodi in esecuzione su volumi EBS possono sfruttare le funzionalità di snapshot native, poiché lo storage EBS persiste indipendentemente dall’istanza. I nodi che utilizzano lo store di istanze, invece, richiedono backup orari e giornalieri su uno storage esterno come S3, perché i dati dello store di istanze vengono persi in modo permanente e irreversibile nel momento in cui una macchina si ferma o si riavvia.

3. Distribuzioni Kubernetes/ibride

Le implementazioni di Cassandra basate su Kubernetes richiedono il backup di più dei dati SSTable. Dipendono anche da Kubernetes Secrets, ConfigMaps e definizioni StatefulSet che definiscono la configurazione e l’identità del cluster. Senza di esse, i dati ripristinati non hanno un ambiente valido in cui essere eseguiti.

4. Cluster di produzione multi-nodo

Nei cluster di produzione multi-nodo, le istantanee devono essere attivate simultaneamente su ogni nodo per produrre un punto di ripristino coerente. Un backup scaglionato rischia di creare lacune nei dati che rendono impossibile un ripristino pulito.

5. Archiviazione dei registri degli impegni

L’archiviazione del registro degli impegni conserva il registro di scrittura sequenziale di Cassandra insieme alle istantanee regolari, consentendo un ripristino point-in-time. Per le implementazioni in cui anche piccole finestre di perdita di dati sono inaccettabili, l’archiviazione dei registri di commit è un componente essenziale della strategia di backup.

Quale obiettivo di tempo di ripristino (RTO) e quale obiettivo di punto di ripristino (RPO) deve considerare per il backup e il ripristino del database Cassandra?

L’RPO e l’RTO giusti per un’implementazione di Cassandra dipendono dal valore aziendale dei dati e dalla complessità del cluster. Questi due numeri devono essere definiti prima di progettare qualsiasi strategia di backup.

Per quanto riguarda l’RPO, più i dati sono critici, più il punto di ripristino deve essere stretto. L’RPO definisce la perdita di dati accettabile e determina la frequenza di backup. Si consideri una piattaforma di elaborazione dei pagamenti che registra transazioni in tempo reale, che potrebbe richiedere un RPO di minuti.

Per quanto riguarda l’RTO, Cassandra richiede aspettative oneste. A differenza di un database a server singolo, dove il ripristino può richiedere pochi minuti, il ripristino di un cluster Cassandra distribuito comporta la copia dei dati su più nodi, il riavvio dei servizi e l’esecuzione di operazioni di riparazione per sincronizzare le repliche.

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

Per le piccole aziende che operano in settori specifici, l’utilizzo della sola strategia di backup di Cassandra è sufficiente. Tuttavia, nel caso di grandi aziende e imprese, il backup di Cassandra non funziona in modo isolato, ma si integra con un quadro più ampio di protezione dei dati.

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

A differenza delle startup e delle aziende di medie dimensioni, le imprese gestiscono un grande volume di dati. In questi scenari, è difficile per tutti i team gestire il proprio backup in modo indipendente, poiché

• Le organizzazioni perdono traccia di ciò che stanno effettivamente proteggendo.
• Problemi gravi o catastrofi, come un attacco ransomware, che colpiscono più sistemi contemporaneamente.

La resilienza aziendale va oltre il backup a livello di database. Anche se ogni team fa del suo meglio in isolamento, c’è bisogno di un sistema universale che gestisca tutto e che tenga tutto sotto controllo nel caso in cui si verifichi qualcosa. Pertanto, per le grandi imprese, Cassandra non opera separatamente, ma piuttosto si affianca ad altri sistemi importanti che necessitano di protezione secondo politiche coerenti.

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

I backup di Cassandra si integrano con le piattaforme di backup aziendali attraverso i suoi plugin designati, che in seguito diventano parte del patrimonio unificato dell’azienda. Di seguito, illustriamo le caratteristiche e ciò che può fare una volta integrato con la piattaforma di backup aziendale.

• Gestione automatica delle istantanee: La piattaforma pianifica ed esegue il comando snapshot di nodetool automaticamente su tutti i nodi contemporaneamente.
• Coordinamento tra i nodi: Il plugin di backup Cassandra coordina tutti i nodi dell’intero cluster.
• Posizione di archiviazione centralizzata: I file vengono trasferiti dai singoli nodi a una posizione di archiviazione centralizzata.
• Nessuna pulizia manuale: La piattaforma elimina automaticamente i vecchi file che non servono più.
• Monitoraggio e allerta: In caso di problemi, le piattaforme identificano e avvisano il team, il che porta a risoluzioni tempestive.
• Gestire il processo di ripristino: Quando è necessario il ripristino, la piattaforma gestisce tutto dalla A alla Z.

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

L’utilizzo di un sistema di backup centralizzato può influire positivamente sull’efficienza operativa dell’azienda. Con la tabella sottostante, esploriamo i rischi tipici che i singoli backup comportano per le aziende e come un sistema di backup centralizzato possa ridurre significativamente i rischi operativi.

Quali sono le strategie di backup di Cassandra disponibili?

Il backup di Cassandra da solo non è sufficiente a soddisfare le esigenze aziendali. Si rivolge solo a un sistema alla volta, mentre le aziende hanno bisogno di più sistemi con una protezione coordinata e coerente. Un singolo backup isolato non può proteggere un ambiente aziendale. Ha bisogno di una strategia di protezione dei dati centralizzata che unisca tutto in un unico quadro e che implementi politiche, monitoraggio, avvisi e procedure di ripristino coerenti.

Che cos’è il backup istantaneo di Cassandra e quando si dovrebbe usare?

Il backup istantaneo di Cassandra crea una copia point-in-time di tutte le SSTable, eseguita dal comando nodetool snapshot. Non richiede alcuno spazio di archiviazione aggiuntivo, ma piuttosto crea dei collegamenti rigidi per quel particolare momento che vengono congelati, e che in seguito possono essere utilizzati per recuperare le informazioni che si avevano nel caso in cui qualcosa vada storto, o i dati vadano persi.

Prima di qualsiasi operazione ad alto rischio, si dovrebbe utilizzare il backup istantaneo di Cassandra. Tali scenari includono

• Aggiornamenti su larga scala
• Modifiche dello schema
• Eliminazione massiccia di dati

Importante: Si consiglia vivamente di eseguire le istantanee su base giornaliera o occasionale. Una volta creata, la trasferisca su uno spazio di archiviazione esterno. Il backup S3 di Cassandra è l’approccio più utilizzato. Può trasferirlo su Amazon S3, che proteggerà le sue istantanee e garantirà la sicurezza di tutti i suoi dati.

Qual è la differenza tra backup completo, incrementale e differenziale?

Cassandra offre tre categorie principali di backup:

• Backup completo
• Backup incrementale
• Backup differenziale

1. Un backup completo acquisisce una copia completa dell’intero set di dati (indipendentemente dal fatto che siano state apportate o meno delle modifiche). Pur essendo l’opzione più semplice, richiede molto tempo; pertanto, non è la più utilizzata.
2. Il backup incrementale cattura solo ciò che è cambiato dall’ultimo backup.
3. Il backup differenziale cattura solo i dati aggiunti e modificati dall’ultimo backup completo.

NOTA: Cassandra non supporta nativamente il backup differenziale.

Come funziona il backup incrementale di Cassandra e quando è necessario attivarlo?

Il backup incrementale di Cassandra cattura solo i nuovi file SSTable mentre vengono scritti sul disco, rendendolo più efficiente dal punto di vista dello storage rispetto ai backup completi. I backup incrementali riducono l’overhead di archiviazione acquisendo solo i nuovi dati dall’ultimo backup. L’attivazione di questa funzione richiede una modifica di una riga in Cassandra.yaml.

Una volta attivata, non c’è altro lavoro manuale: il resto viene gestito automaticamente.

Fase 1: Ricezione di nuovi dati

I nuovi dati vengono ricevuti nella memtable, che è un buffer di scrittura temporaneo in memoria.

Fase 2: i dati vengono scaricati dalla memtable al disco

Una volta che la memtable è piena e fuori dalla memoria, Cassandra scarica i dati come file SSTable permanente.

Fase 3: Vengono creati gli hard link

Non appena vengono creati gli SStable, Cassandra crea automaticamente degli hard link per quei dati nei backup designati.

Fase 4: Gli agenti di backup eseguono lo sweep e il trasferimento

Gli strumenti di backup come Medusa, integrati con Cassandra, controllano e trasferiscono regolarmente i nuovi file sull’archivio esterno.

Fase 5: Il ciclo si ripete

Questo processo si ripete continuamente ogni volta che nuovi dati entrano nel cluster.

I backup incrementali di Cassandra dovrebbero essere attivati quando:

• I dati cambiano frequentemente
• C’è un grande volume di dati
• Il suo RPO richiede punti di ripristino con una frequenza superiore alle 24 ore.
• Le istantanee complete giornaliere occupano troppo spazio o richiedono troppo tempo.

In che modo i registri di commit e le considerazioni sul ripristino point-in-time influenzano il backup e il ripristino di Cassandra?

L’archiviazione dei registri di commit è una caratteristica importante nell’architettura di distribuzione di Cassandra quando si tratta di ripristinare i database.

Quando si esegue il backup di Cassandra, i passaggi sono i seguenti:

• Arriva la scrittura
• Registro degli impegni (disco) + Memtable (RAM)
• La memoria si riempie → FLUSH
• SSTable (disco)
• Segmento del registro di commit cancellato

Sebbene questa sia una sequenza ideale in circostanze operative normali, l’archiviazione del registro di commit cambia questo schema. Invece di eliminare i segmenti del registro di commit alla fine, ne salva delle copie nell’archivio esterno, consentendo l’accesso ai dati persi. Le istantanee regolari combinate con gli archivi del registro di commit rendono possibile il ripristino point-in-time (PITR). Senza l’archiviazione dei registri di commit, il recupero è limitato solo all’ultima istantanea.

Per avere un’immagine migliore, consideriamo il seguente esempio. Un’istantanea è stata scattata alle 11 del mattino, e poi è avvenuta una cancellazione accidentale alle 15.34. Senza l’archiviazione dei registri di commit, sarebbe in grado di accedere ai dati solo fino alle 11:00, il che le costerebbe 4 ore e 34 minuti di perdita di dati. Con l’archiviazione dei registri di commit, tutti i dati possono essere sostituiti, riducendo l’entità della perdita di dati.

In questi scenari, in cui l’RPO è prossimo allo zero, l’archiviazione dei registri di commit non diventa un optional, ma un must.

Quali sono i pro e i contro dei backup a livello di cluster o a livello di nodo?

I backup di Cassandra vengono eseguiti sia a livello di nodo che a livello di cluster, ognuno dei quali presenta dei compromessi distinti.

Backup a livello di nodo: È più semplice rispetto al backup a livello di cluster, in quanto non richiede un’orchestrazione speciale e viene eseguito il backup su ogni nodo in modo indipendente. Tuttavia, il backup dei nodi in modo indipendente rischia l’incoerenza dei dati in tutto il cluster, soprattutto nel caso di cluster > 50 nodi, in quanto il ripristino può essere impegnativo, causando problemi associati all’integrità dei dati.

Backup a livello di cluster: A differenza del backup a livello di nodo, è molto più complesso e richiede un’orchestrazione speciale. Esegue il backup su tutti i nodi dello stesso cluster contemporaneamente. Questo assicura che l’integrità dei dati non venga compromessa.

Quali strumenti e servizi supportano il backup e il ripristino di Cassandra?

Cassandra offre un’ampia suite di strumenti e servizi per il backup e il ripristino. Scegliere quello giusto è essenziale quanto le strategie stesse, e la scelta dipende molto da diversi fattori, tra cui le dimensioni del cluster e i requisiti di ripristino. In questa sezione, tratteremo in modo approfondito i principali tipi di strumenti e servizi che supportano il backup e il ripristino di Cassandra, e discuteremo i vantaggi e gli svantaggi di ciascuno.

Quali sono i pro e i contro dei metodi di backup nativi di Cassandra?

Quali sono i pro e i contro dei metodi di backup nativi di Cassandra?

I metodi di backup nativi di Cassandra sono gli strumenti integrati direttamente in Cassandra e non richiedono l’integrazione di software di terze parti, come Medusa e Bacula. I due tipi principali di metodi di backup nativi di Cassandra sono i seguenti:

1. Istantanea di Nodetool
2. Backup incrementale integrato

Entrambe le opzioni sono ampiamente utilizzate da Cassandra, e il metodo specifico da scegliere dipende molto da diversi fattori. I metodi di backup nativi di Cassandra possono essere un’opzione ideale per le piccole implementazioni, grazie alla loro praticità. Non ci sono costi aggiuntivi di installazione o di licenza.

Tuttavia, hanno anche i loro limiti. Sono fortemente concentrati sul lavoro manuale, che include il trasferimento dei file su un sistema esterno uno per uno e la pulizia manuale delle vecchie istantanee. Per le grandi distribuzioni, questa potrebbe non essere un’opzione ideale, in quanto non esiste un monitoraggio centralizzato, né un avviso automatico in caso di guasto, oltre a molte altre caratteristiche.

Pro:

• facile da capire
• ideale per le piccole distribuzioni
• non richiede installazione
• gratuito e integrato

Contro:

• non adatto a grandi produzioni
• nessun monitoraggio o avviso
• nessuna gestione della conservazione
• nessuna pianificazione

Come funziona Cassandra backup S3 e quando dovrebbe usarlo?

Cassandra backup S3 è una delle soluzioni di backup più utilizzate, in quanto offre un’ampia gamma di vantaggi:

• Capacità di archiviazione illimitata
• Ridondanza geografica
• Controllo degli accessi
• Politiche di ciclo di vita automatico

Per aiutarla a prendere una decisione più informata e identificare se è adatto alle sue esigenze, esploriamo passo dopo passo il suo funzionamento.

Fase 1: Viene attivata un’istantanea su ogni singolo nodo, producendo file SStable.

Fase 2: successivamente, questi file vengono compressi, crittografati e caricati sul bucket S3 assegnato, utilizzando uno strumento di backup di terze parti come Medusa.

Fase 3: una volta in S3, i file snapshot locali possono essere eliminati.

Il backup S3 di Cassandra deve essere utilizzato quando

• Il cluster funziona in un ambiente cloud con accesso S3.
• Necessita di uno storage di backup geograficamente separato ed economicamente vantaggioso.
• Desidera una gestione automatica della conservazione attraverso le politiche del ciclo di vita di S3.
• Utilizza strumenti di terze parti, come Bacula Enterprise, Medusa e OpsCenter, che si integrano in modo nativo con S3.

Come si confrontano i metodi manuali basati sulle istantanee con gli strumenti di backup automatizzati di Cassandra?

In termini di praticità, gli strumenti di backup automatizzati di Cassandra sono un’opzione migliore, soprattutto per le aziende. Di seguito, discutiamo e confrontiamo i due metodi separatamente.

Metodo manuale basato sulle istantanee

Questo metodo si basa molto sul lavoro manuale, tra cui l’esecuzione degli snapshot di nodetool, la scrittura di script per trasferire manualmente i file su S3 SStable, l’impostazione di cron job e l’eliminazione manuale dei vecchi snapshot non più necessari. I metodi basati sul manuale non sono molto efficienti per le imprese e le grandi aziende, in quanto dipendono dall’uomo, mancano di monitoraggio e coordinamento e aumentano il rischio di errori.

Gli strumenti di backup Cassandra automatizzati sono integrati automaticamente attraverso strumenti di terze parti, tra cui Medusa e Bacula Enterprise. Le caratteristiche tipiche includono la pianificazione automatizzata, il coordinamento, il trasferimento, la compressione e la crittografia, la gestione della conservazione, il monitoraggio e gli avvisi.

Come si possono utilizzare in modo sicuro le istantanee a livello di filesystem per il backup del DB Cassandra?

In uno scenario tipico, il backup del DB Cassandra crea e archivia semplicemente i dati nel database Cassandra. Un’istantanea a livello di filesystem offre un approccio alternativo a questo, consentendo l’acquisizione dell’intero disco a livello di storage. Si integra con strumenti di backup Cassandra di terze parti, come gli snapshot di AWS EBS, per catturare i file SSTable, i registri di commit e i file di configurazione.

Sebbene questi strumenti siano abbastanza veloci e completi e possano operare in modo indipendente a livello di archiviazione, possono causare seri problemi se non vengono utilizzati correttamente. Se Cassandra è in fase di midwrite e viene attivata un’istantanea del filesystem mentre i dati sono nella memtable, potrebbe diventare difficile ripristinare i dati in modo chiaro.

NOTA IMPORTANTE: per ridurre il rischio di un tale scenario, esegua il flush di nodetool prima di attivare lo snapshot del filesystem. Ecco cosa può fare per ridurre il rischio di un simile scenario.

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

Esiste un’ampia suite di strumenti di backup e ripristino di Cassandra, che sono opzioni ideali per soddisfare le esigenze di implementazioni di produzione su larga scala. I vantaggi tipici offerti da questi strumenti includono, ma non si limitano a

• Efficienza operativa
• Supporto dell’archiviazione in cloud
• Flessibilità del backup
• Ripristino d’emergenza più rapido

Strumenti leader di terze parti per il backup e il ripristino di Cassandra

• Bacula Enterprise

Bacula Enterprise si distingue da tutte le altre soluzioni di backup, perché è specificamente progettato per ambienti grandi e complessi. È lo strumento di backup e ripristino di livello aziendale più completo disponibile per le implementazioni Cassandra.

• OpsCenter

OpsCenter è uno strumento di backup Cassandra di terze parti che fa parte della piattaforma di gestione cluster ufficiale di DataStax. Il backup e il ripristino sono solo un componente di una piattaforma più ampia che copre. Questo strumento archivia i dati di backup per garantire che non ci siano file duplicati e supporta sia l’archiviazione locale che Amazon S3 come destinazioni di backup.

OpsCenter si integra direttamente con l’ecosistema DataStax Enterprise e gestisce la complessità aggiuntiva del ripristino di questi carichi di lavoro accanto ai dati Cassandra standard. La sua funzione di clonazione del cluster consente di ripristinare i dati di backup in un cluster diverso, supportando i flussi di lavoro di migrazione e disaster recovery.

• Medusa

Medusa è uno degli strumenti di backup e ripristino open source più diffusi, costruito appositamente per Apache Cassandra. Le caratteristiche tipiche offerte da Medusa includono il supporto del backup completo e incrementale, la gestione automatica delle ritenzioni e l’integrazione con vari servizi di archiviazione cloud, come Amazon S3, Google Cloud Storage e Azure Blob Storage.

Medusa è costruito per l’architettura distribuita di Cassandra; comprende come coordinare i backup tra i vari nodi, gestire i file SSTable e gestire catene di backup incrementali senza script personalizzati.

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

Gli strumenti di backup di Cassandra possono gestire il database in modo isolato, il che è un’opzione ideale per le piccole distribuzioni. Per i cluster > 50 nodi, Cassandra Backup da solo non è sufficiente, in quanto manca il coordinamento e la visibilità di un’infrastruttura completa. Bacula Enterprise integra il backup di Cassandra in una strategia più ampia di protezione dei dati a livello aziendale.

A differenza del backup istantaneo di Cassandra, che esegue il backup di ogni nodo uno per uno, Bacula consente di coordinare tutti i nodi del cluster in una sola volta, nello stesso momento. Gestisce un backup completo in modo automatico, senza alcun intervento manuale. Ciò include l’attivazione delle istantanee, il trasferimento degli SStable nello storage centralizzato pertinente, la gestione delle catene di backup e la successiva archiviazione dei registri di commit per un ripristino point-in-time (PITR).

Questo rende Bacula Enterprise un’opzione pratica per le organizzazioni che hanno bisogno di un controllo centralizzato su Cassandra insieme ad altri sistemi della loro infrastruttura.

Come si esegue un backup sicuro per diverse topologie di Cassandra?

Il backup sicuro di Cassandra richiede molto di più: richiede un’esecuzione accuratamente pianificata, che spesso viene trascurata. Prestare attenzione ai dettagli operativi è importante quanto gli strumenti e le strategie stesse, poiché è questo che garantisce la coerenza dei dati in tutto il processo.

Come si esegue il backup di un cluster Cassandra multi-nodo senza impattare sulla disponibilità?

Per eseguire il backup di un cluster Cassandra multi-nodo senza impattare sulla disponibilità, è necessario scaglionare le operazioni di backup tra i vari nodi, pianificare nelle ore non di punta e limitare l’uso delle risorse. Le pratiche seguenti affrontano direttamente ciascuno di questi requisiti.

• Eseguire il backup di un nodo alla volta

Cassandra replica i dati su più nodi e questo può influire sulla sua disponibilità. Per ridurre al minimo tale rischio, è buona norma eseguire il backup di un solo cluster alla volta, mentre gli altri possono svolgere le loro funzioni quotidiane, come servire le richieste.

• Eseguire i backup solo nelle ore non di punta

Durante le ore di punta, soprattutto nei giorni feriali e nelle ore lavorative, la competizione per le risorse è relativamente più alta. Il backup delle operazioni durante i fine settimana risolve questo problema, poiché la concorrenza per le risorse è minima o nulla.

• Limitare le operazioni di backup

Le operazioni di backup e il traffico live competono per le stesse risorse. Strumenti come Bacula Enterprise o Medusa aiutano a limitare le operazioni di backup. In questo modo si garantisce che le operazioni di backup non consumino risorse sufficienti, con un impatto sulle prestazioni live.

Come si coordina il backup delle istantanee di Cassandra tra i nodi distribuiti?

Il coordinamento del backup delle istantanee di Cassandra tra i nodi distribuiti è semplice, a condizione che tutti i nodi del cluster distribuito vengano acquisiti simultaneamente.

Gli scenari opposti possono causare seri problemi. In un cluster distribuito, ogni nodo detiene una porzione diversa del set di dati totale. Anche una differenza minima può determinare punti diversi nel tempo, che alla fine possono portare a un punto di ripristino incoerente, difficile o appena possibile da ripristinare in modo chiaro.

È necessario disporre di strumenti efficaci di orchestrazione per gestire questo aspetto in modo nativo. L’integrazione di Cassandra con strumenti di terze parti come Bacula Enterprise consente di collegare tutti i nodi contemporaneamente, quindi di attendere il completamento di tutte le istantanee e successivamente di trasferire i file su uno storage esterno. Questo processo assicura il coordinamento regolare del backup delle istantanee di Cassandra tra i nodi distribuiti, senza alcun compromesso.

Come si assicura che i backup rimangano coerenti tra le repliche e i data center?

I backup possono diventare incoerenti tra le repliche e i data center quando i nodi conservano versioni leggermente diverse degli stessi dati al momento dell’istantanea. Due passaggi preliminari al backup e due pratiche a livello di backup che affrontano direttamente questo problema.

• Eseguire nodetool repair

Quando si esegue una riparazione con nodetool, la sincronizzazione della replica avverrà nell’intero cluster e ogni nodo avrà la versione più recente degli stessi dati. Una volta eseguito questo processo, non ci sarà alcuna incoerenza all’inizio dell’istantanea.

• Disabilitare la compattazione

Esegua nodetool disableautocompaction per evitare che i nodi siano a metà della compattazione quando viene eseguita l’istantanea, evitando file SSTable parzialmente uniti nel backup.

Una volta eseguiti questi passaggi, può passare al processo di backup. Ecco cosa può fare per rimanere coerente tra i vari datacenter.

• Utilizzi la coerenza LOCAL_QUORUM

Questo le consentirà di avere solo dati pienamente confermati e aggiornati dal centro dati locale, acquisiti durante le operazioni di backup.

• Esegua il backup da un solo data center

Il backup da più data center può causare incoerenze a causa della differenza di orario. Il backup da un solo data center elimina le incoerenze, in quanto un backup DC completo cattura già il set di dati completo attraverso la replica.

Quali sono i passaggi per ripristinare Cassandra dai backup?

Il backup di Cassandra è solo metà del processo: è altrettanto importante dotarsi di informazioni su come ripristinare Cassandra dal backup. Il processo di ripristino può variare a seconda di diversi fattori, tra cui l’ambito e i metodi utilizzati durante il processo.

La sezione seguente copre tutti gli scenari di ripristino che può incontrare.

Come si esegue il backup e il ripristino di Cassandra in modo sicuro per tabelle, keyspace o cluster completi?

Il backup e il ripristino di Cassandra possono avvenire a tre livelli diversi, e ognuno di essi può portare a una diversa portata della perdita di dati. Discutiamone uno per uno.

• Ripristino a livello di tabella

Questo è il livello più semplice per il ripristino. Nel ripristino a livello di tabella, non è necessario recuperare tutto, ma solo una tabella che è stata accidentalmente abbandonata o eliminata. Il processo è semplice: copiare il file snapshot dato nella directory corretta ed eseguire nodetool refresh per caricare i dati.

• Ripristino a livello di spazio chiave

Il ripristino a livello di spazio chiave si riferisce al processo di ripristino di tutte le tabelle che si trovano nello stesso spazio chiave. Segue lo stesso processo del ripristino a livello di tabella, ma si applica a tutte le tabelle, e viene eseguito quando l’intero keyspace viene cancellato o danneggiato simultaneamente.

• Ripristino di un cluster completo

Questo tipo copre tutto ciò che si trova nello stesso cluster; pertanto, è il più complesso e richiede molto tempo. Di solito, il ripristino di un cluster completo avviene dopo eventi catastrofici importanti, come il ransomware. Il processo di ripristino di un cluster completo comprende l’arresto di Cassandra su ogni nodo, la pulizia di tutte le directory di dati, il ripristino dei file snapshot e il successivo riavvio del cluster.

Come si ripristina da un’istantanea di backup di Cassandra e si ripristinano i nodi?

Il ripristino di un nodo Cassandra è un processo meticoloso e richiede il rispetto di passaggi chiaramente definiti. Di seguito, analizziamo il percorso esatto dei passaggi che dovrà seguire per ripristinare il suo nodo Cassandra.

Passo 1: Arrestare Cassandra

Dovrà arrestare Cassandra, poiché i file di dati non possono essere sostituiti mentre Cassandra è in funzione.

Passo 2: Cancellare la directory dei dati

Eliminare tutti i file danneggiati dalla directory dei dati, in quanto sono i file che vengono sostituiti dal backup.

Passo 3: Copiare i file snapshot

Una volta che la directory dei dati è stata ripulita dai file cancellati o danneggiati, può copiare i file snapshot e riportarli nel percorso corretto della directory dei dati.

Passo 4: Correggere le autorizzazioni

Non appena i dati corretti sono nel posto giusto, corregga le autorizzazioni dei file e si assicuri che Cassandra ne sia proprietario; altrimenti, non sarà in grado di leggere la versione corretta.

Passo 5 – Riavviare Cassandra

Il nodo torna online, leggendo i file SSTable ripristinati.

Passo 6 – Eseguire nodetool repair. Questo sincronizza il nodo ripristinato con i suoi vicini, in modo che riceva qualsiasi scrittura avvenuta su altri nodi mentre era offline.

NOTA IMPORTANTE: se sta eseguendo un ripristino completo del cluster, dovrà ripetere questa sequenza su tutti i nodi.

Come si utilizzano i dati del backup incrementale di Cassandra durante il ripristino?

Il ripristino da un backup incrementale di Cassandra è molto più complesso rispetto al ripristino del backup snapshot. Ci sono due cose importanti da tenere a mente quando si avvia un ripristino con un backup incrementale di Cassandra.

• Il backup incrementale deve essere applicato in ordine cronologico
• Nessun file della catena può essere saltato.

Il ripristino del backup incrementale comprende due fasi principali, che sono le seguenti:

1. Ripristino della linea di base dell’istantanea completa: È IMPOSSIBILE ripristinare il backup incrementale senza ripristinare il backup dell’istantanea completa, poiché serve come base.
2. Applicare gli incrementi in ordine cronologico: Ogni incremento viene costruito sopra la linea di base, dal più vecchio al più recente. Se l’ordine non viene seguito cronologicamente, il ripristino del backup non sarà corretto.

Discutiamo un esempio e vediamo come funziona

Supponiamo di avere un’istantanea completa il martedì e degli incrementi ogni giorno fino al sabato. Per ripristinare il backup incrementale di sabato, dovrà applicare le istantanee di martedì, quindi gli incrementali di mercoledì, giovedì, venerdì e sabato nello stesso ordine cronologico.

Come si gestiscono i disallineamenti di versione tra il backup e le versioni di Cassandra di destinazione?

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

I backup di Cassandra possono cambiare di tanto in tanto. Quando quello utilizzato per creare e quello utilizzato per ripristinare il backup non coincidono, non avviene un ripristino pulito corretto. A seconda delle circostanze, ci sono due soluzioni da prendere in considerazione.

1. Eseguire la stessa versione di Cassandra utilizzata per la creazione, quindi aggiornarla alla versione di destinazione. Questa è la più diffusa tra le due opzioni. Questo riduce al minimo la complessità dell’intero processo ed elimina i rischi di compatibilità di formato.
2. Convertire i vecchi file e poi ripristinarli in una nuova versione. Se la prima soluzione non funziona, può convertire i file della vecchia versione utilizzando lo strumento sstableupgrade , e poi ripristinare successivamente alla nuova versione.

Entrambe le opzioni sono gestibili. Non è importante quale scegliere, ma piuttosto che le discrepanze di versione siano gestite correttamente e che i dati siano ripristinati correttamente.

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

I processi di backup manuali, che sono ideali per le piccole distribuzioni, hanno ancora i loro svantaggi. Sono soggetti ad errori umani, a pianificazioni dimenticate e a caratteristiche che non vengono rilevate fino a quando non si verifica una grave catastrofe. L’automazione e la pianificazione sono progettate specificamente per risolvere questo problema: garantire che gli errori siano gestiti in tempo prima che diventino gravi, e identificare i guasti in anticipo per prendere le precauzioni necessarie. Questa sezione tratta in modo esauriente tutto ciò che deve sapere per automatizzare e pianificare in modo affidabile i backup di Cassandra.

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

Quando sceglie la giusta pianificazione dei backup, ci sono due requisiti che deve tenere in considerazione

• Soddisfare i requisiti RPO/RTO
• Ridurre al minimo il carico del cluster

Esistono due schemi principali di pianificazione del backup che potrebbe prendere in considerazione

• Istantanee complete giornaliere + backup incrementali orari

Esegua un’istantanea completa una volta al giorno e degli incrementi orari per catturare le modifiche che si verificano nel corso della giornata. Questa combinazione la aiuterà a soddisfare il suo RPO di un’ora senza dover eseguire ripetutamente snapshot completi.

NOTA IMPORTANTE: pianifichi le sue istantanee complete durante le ore non di punta per ridurre al minimo la concorrenza del traffico live.

• Snapshot completi settimanali + incrementi giornalieri

Mentre per la maggior parte delle implementazioni, gli snapshot completi giornalieri soddisfano l’RPO di 24 ore, non è così per i cluster > 50 nodi, poiché richiedono molto tempo. In questi scenari, la pianificazione di full-snapshot settimanali combinati con incrementi giornalieri può essere un’opzione migliore, che le permetterà di ridurre i costi generali e di mantenere un RPO di 24 ore.

Di seguito, discutiamo i requisiti RPO più diffusi e quali sono i modelli consigliati per essi.

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

Gli script di backup non funzionano adeguatamente in molti modi, e affrontarli in tempo è fondamentale. Costruire la resilienza e l’idempotenza è la soluzione definitiva, che garantisce che ogni processo di backup sia gestito con attenzione.

Ecco i passi concreti da seguire per rendere la sua automazione di backup resiliente e idempotente.

Fase 1: Effettuare un pre-controllo prima dell’esecuzione

Prima ancora di provare a creare una nuova istantanea, verifichi e si assicuri che non esistano altre istantanee per la stessa finestra.

Passo 2: Utilizzare i file di blocco

Una volta avviata l’automazione del backup, crei un file di blocco e successivamente lo elimini. Questo passo assicurerà che non vi siano due file di backup in esecuzione simultaneamente.

Fase 3: Controllare ogni fase

Verifichi ogni singolo dettaglio e controlli il codice di uscita di ogni comando, comprese le istantanee, la compressione e i caricamenti. Questo aiuterà a identificare il fallimento dell’intero processo e a tenere tutto sotto controllo.

Passo 4: Registrare tutto

Scriva tutte le attività, compresi i successi, i fallimenti e gli avvertimenti, in un file di registro, che la aiuterà ad assicurarsi che gli script siano resistenti.

Fase 5: Pulire in caso di fallimento

Eseguire automaticamente lo sweep delle istantanee parziali o dei caricamenti incompleti, nel caso in cui il suo script di backup fallisca a metà del processo.

Fase 6: Aggiungere la logica di ritrattamento

Riprova automaticamente i guasti transitori fino a un limite definito.

Passo 7: Utilizzi gli strumenti di orchestrazione

Invece di utilizzare i cron job, utilizzi strumenti di orchestrazione come Bacula Enterprise, che le permetteranno di gestire l’intero ciclo di vita del backup.

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

Durante il processo di backup di Cassandra, i guasti possono verificarsi in qualsiasi momento. Il monitoraggio dei lavori di backup e gli avvisi in caso di guasti sono due elementi importanti da considerare durante i guasti.

Quando inizia il monitoraggio del backup, tenga a mente queste domande per renderlo efficace.

• Il backup è stato eseguito?
• È stato completato con successo?
• Quanto tempo ha richiesto l’esecuzione?
• Quanto era grande l’output
• È possibile ripristinare il backup?

Per monitorare i lavori di backup, consideri quanto segue:

1. Controllare i registri di Cassandra

Esamini il file system.log dopo ogni lavoro di backup per trovare errori o avvisi che indichino che qualcosa non è stato completato in modo pulito.

2. Utilizzi nodetool per verificare le sue istantanee

Esegua nodetool listsnapshots per assicurarsi che la sua istantanea esista effettivamente.

3. Traccia le uscite del lavoro

Si assicuri di registrare il codice di uscita, la dimensione del file e la durata del suo script di backup per poterlo confrontare in seguito con le versioni precedenti.

Durante l’esecuzione del backup di Cassandra, gli avvisi sono importanti quanto il monitoraggio, che la aiuta a prendere le precauzioni necessarie in tempo. A seconda della gravità del problema, gli avvisi di guasto devono essere indirizzati al canale designato.

• PagerDuty per una risposta immediata su chiamata
• Slack per la visibilità del team
• e-mail per le notifiche non urgenti

Può anche utilizzare strumenti di terze parti come Bacula Enterprise, che offre backup e monitoraggio unificati e avvisi, assicurando che tutto sia sotto controllo.

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

Utilizzare la giusta strategia di backup di Cassandra è importante, ma è solo la metà dell’equazione. La sicurezza e la conformità sono la seconda parte. La sicurezza assicura che i file siano protetti da qualsiasi accesso o restrizione autorizzata. La conformità, invece, assicura che le pratiche di backup soddisfino tutti i requisiti normativi.

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

I backup di Cassandra devono essere crittografati sia a riposo che in transito. Si tratta di due requisiti di protezione distinti che affrontano diversi punti di vulnerabilità.

La crittografia a riposo è il processo di archiviazione dei file di backup in forma crittografata sul disco o sullo storage di backup. Assicura che i file siano protetti e non vengano letti, anche in caso di furto dell’archivio fisico.

La crittografia in transito, invece, si riferisce al processo di trasferimento del backup dal nodo Cassandra allo storage di backup. Questo processo impedisce l’intercettazione durante il trasferimento, garantendo la protezione dei dati importanti.

Ecco cosa devono fare le aziende e le imprese per proteggere adeguatamente i backup di Cassandra.

• Utilizzare standard di crittografia forti come AES-256 per la crittografia a riposo.
• Protocolli sicuri come HTTPS per la crittografia in transito.
• Archiviare e gestire le chiavi di crittografia utilizzando il servizio di gestione delle chiavi (KMS).
• Limitare l’accesso ai file di backup

Come si controlla l’accesso ai backup e si applica il privilegio minimo?

Controllare l’accesso a tutto per tutti è una delle pratiche meno utilizzate nel backup di Cassandra. Questa pratica richiede l’applicazione del minimo privilegio, il che significa dare a ogni sistema e persona il minimo indispensabile di permessi per il loro ruolo. Gli account o ruoli di servizio tipici includono:

1. Agenti di backup che hanno accesso in sola scrittura all’archivio di backup, ma non possono leggere o eliminare i backup esistenti.
2. Agenti di ripristino che hanno accesso in sola lettura e non possono cancellare o modificare nulla.
3. Amministratore di backup che ha accesso completo a tutto.

Molte aziende implementano politiche IAM (Identity and Access Management) e bucket S3 per controllare l’accesso ai backup e applicare il minimo privilegio. Tali politiche includono, ma non si limitano a, negare le operazioni agli account non amministratori, limitare l’accesso a un intervallo IP sconosciuto, richiedere la crittografia su tutti i caricamenti e verificare i record di registrazione.

La separazione di questi compiti tra i sistemi e le persone, e l’identificazione di chi può fare cosa e quando, assicura che tutto sia sotto controllo e che nulla sia compromesso.

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

Le politiche di conservazione e i requisiti di cancellazione dei dati sono due sfide distinte che hanno un impatto sulla strategia di backup di Cassandra. Le politiche di conservazione sono le politiche che determinano la durata di conservazione dei backup di Cassandra prima della loro eliminazione se non sono più in uso.

• Backup giornalieri – Conservati per 30 giorni
• Backup settimanali – Conservati per 3 mesi
• Backup mensili – Conservati per un anno
• Backup annuali – Conservati per 7 anni

Per risolvere questo problema, le organizzazioni implementano un approccio di conservazione a livelli, il che significa applicare contemporaneamente periodi di conservazione diversi a diversi tipi di backup. In questo modo, le aziende e le imprese possono bilanciare i costi di archiviazione e la conformità alle normative senza conservare tutto per sempre.

I requisiti di cancellazione dei dati rappresentano un’altra sfida, in quanto non è possibile eliminare i dati di utenti specifici dai file di backup binari. Per risolvere questo problema, le aziende mantengono un periodo di conservazione abbastanza breve, in modo che i dati eliminati scadano naturalmente entro un lasso di tempo documentato e difendibile.

Come si applicano i backup immutabili e la protezione da ransomware al backup e al ripristino di Cassandra?

Il ransomware è il guasto più grande e catastrofico che si verifica durante il processo di backup di Cassandra. In caso di attacco, il ransomware segue uno schema prevedibile, che è il seguente:

• Crittografia dei dati in tempo reale
• Puntare al file di backup per eliminare il recupero

I backup immutabili affrontano direttamente questo problema. Garantisce che i file di backup non possano essere modificati dopo essere stati scritti, e anche un account amministrativo completamente compromesso non può eliminare o criptare un backup immutabile.

S3 Object Lock implementa l’immutabilità a livello di storage AWS:

• I file scritti in un bucket bloccato non possono essere modificati o eliminati per il periodo di conservazione definito.
• La modalità Conformità rimuove tutte le capacità di sovrascrittura.
• La modalità Governance consente agli amministratori autorizzati di annullare il blocco in condizioni specifiche.

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

Nella maggior parte degli scenari, gli attacchi ransomware non si limitano a criptare i dati in tempo reale: cercano costantemente opzioni per distruggere i backup online e ridurre al minimo le possibilità di recupero. Il miglior meccanismo di difesa che gli attacchi ransomware non possono superare è rappresentato dai backup air-gapped e offline.

I backup air-gapped sono completamente disconnessi fisicamente da tutte le reti. Ciò significa che i backup dei dati air-gapped non possono essere raggiunti, cancellati o crittografati, poiché non esiste una connessione internet o un accesso remoto.

I backup offline sono più ampi e non sono attivamente connessi ai sistemi attivi al momento di una violazione. Tuttavia, possono essere ancora raggiungibili attraverso altri mezzi.

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

Una strategia di backup Cassandra di produzione sembra un percorso senza fine, che richiede politiche coerenti, misurazioni continue e una documentazione chiara, per rimanere affidabile nel tempo. La seguente sezione tratta le best practice per il backup Cassandra di produzione, definendo la linea di base e discutendo tutto ciò che è necessario sapere.

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

Il minimo indispensabile che ogni implementazione di Cassandra in produzione dovrebbe avere, indipendentemente dalle dimensioni dell’azienda, dal budget o dalla complessità del cluster, è il seguente:

1. Istantanee giornaliere automatizzate. L’automazione elimina la dipendenza umana dall’operazione più critica di protezione dei dati.
2. Archiviazione fuori sede. Ogni istantanea deve essere immediatamente trasferita su uno storage esterno, completamente separato dal cluster.
3. Politica di conservazione definita. Deve documentare la durata di conservazione di ogni tipo di backup e farla rispettare automaticamente.
4. Monitoraggio e avvisi. Il monitoraggio e gli avvisi automatici sono un must, che le consentiranno di prendere le precauzioni necessarie in tempo e di prevenire i guasti più gravi.
5. Processo di ripristino testato. I backup devono essere testati regolarmente per garantire la sicurezza dei suoi dati.
6. Crittografia. Tutti i suoi file di backup devono essere crittografati a riposo e in transito, senza eccezioni.
7. Controllo degli accessi. Il privilegio minimo deve essere applicato a tutti i suoi archivi di backup.
8. Documentazione della versione. Ogni backup deve essere etichettato con la versione di Cassandra su cui è stato creato.
9. Runbook documentato. Deve avere un runbook documentato, che includa procedure di ripristino dettagliate da utilizzare in caso di catastrofe grave.
10. Backup incrementali. Dovrebbe utilizzare backup incrementali combinati con backup snapshot completi che abbiano un RPO inferiore alle 24 ore.

Come si documentano le procedure di backup e ripristino di Cassandra per i team di reperibilità?

Per documentare le procedure di backup e ripristino di Cassandra per il team di reperibilità, le aziende dispongono di un runbook, che è un documento che funge da guida passo-passo. Un runbook ideale dovrebbe essere scritto in modo tale che anche uno specialista junior che non ha mai eseguito un backup di Cassandra possa leggerlo ed eseguire tutto con successo. Ecco cosa dovrebbe trattare un runbook di questo tipo:

• Ripristino di una singola tabella
• Ripristino dello spazio dei tasti
• Ripristino dell’intero cluster
• Tempistiche previste per ogni fase necessaria
• Dettagli di contatto degli esperti di Cassandra e del supporto dello strumento di backup.

NOTA IMPORTANTE: è necessario che ci sia una guida che permetta alle persone non abituate di capire quale di queste procedure si applica alla situazione in questione.

Questi runbook svolgono una funzione estremamente importante per le aziende e le imprese. Devono essere aggiornati dopo ogni aggiornamento, ripristino o quando cambiano gli strumenti di backup.

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

Il monitoraggio della salute del backup richiede il monitoraggio di metriche specifiche e la misurazione del loro rendimento e dell’eventuale degrado delle prestazioni.

Le metriche chiave che sono importanti da considerare per la salute del backup:

1. Tasso di successo. Questa metrica rappresenta la percentuale di lavori che sono andati a buon fine entro il periodo definito.
2. Durata. Questa metrica definisce la durata di ogni lavoro. Ad esempio, decidendo che un’istantanea completa avrà luogo entro una settimana.
3. Dimensione. Indaga su cali o picchi inaspettati che segnalano anomalie.
4. Tempo di ripristino. Misurata attraverso test di ripristino regolari, questa metrica conferma che l’RTO effettivo è raggiungibile nella pratica.
5. Età del backup. Identificare l’età del backup più recente che ha avuto successo in questo momento.
6. Tempo di risposta agli avvisi: la rapidità con cui vengono riconosciuti i guasti e si interviene. SLA: tutti gli avvisi di backup vengono riconosciuti entro 15 minuti.

Per monitorare queste metriche e identificare lo stato di salute del backup, può utilizzare strumenti di terze parti come Bacula Enterprise, Medusa o OpsCenter, che offrono una piattaforma unificata per eseguire tutte queste operazioni contemporaneamente.

Punti di forza

• Definisca i suoi RPO e RTO prima di progettare la sua strategia, poiché senza di essi la sua strategia di backup non ha un obiettivo misurabile.
• Conservare sempre le istantanee fuori sede una volta create.
• Esegua i backup incrementali e si impegni nell’archiviazione dei registri, in quanto ridurrà i costi di archiviazione.
• L’automazione, il monitoraggio e gli avvisi sono un must, in quanto riducono la probabilità di errori e guasti.
• Deve sempre disporre di crittografia, controllo degli accessi, archiviazione immutabile e backup air-gapped. La crittografia e il controllo degli accessi impediscono l’accesso non autorizzato. I backup immutabili e con air-gapped assicurano che il ransomware non possa distruggere il suo percorso di ripristino.
• Verifichi i suoi backup e le esercitazioni di ripristino regolari confermino il suo piano di lavoro per il ripristino.

Domande frequenti

I backup di Cassandra possono essere coerenti con le architetture applicative distribuite?

Sì, i backup di Cassandra possono rimanere coerenti tra i canali applicativi distribuiti. Tuttavia, ciò viene realizzato attraverso snapshot coordinati e archiviazione dei registri di commit che producono backup affidabili e ripristinabili.

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

Il backup sicuro delle distribuzioni Cassandra multi-tenant richiede snapshot a livello di spazio chiave per mantenere isolati i dati dei tenant. Si assicuri di applicare controlli di accesso rigorosi e la crittografia durante l’archiviazione dei backup per evitare l’esposizione dei dati tra tenant.

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

Le distribuzioni di Cassandra containerizzate richiedono snapshot di volume persistenti, invece di affidarsi esclusivamente allo snapshot di nodetool. In Kubernetes, è possibile utilizzare strumenti come Medusa per gestire l’orchestrazione del backup tra i pod.