La scalabilità del backup è la capacità di mantenere le prestazioni di backup e ripristino man mano che i dati, i carichi di lavoro e i requisiti di conservazione aumentano.
Una piattaforma di backup che funziona bene con 100 terabyte (TB) potrebbe comportarsi in modo molto diverso con 1 petabyte (PB).
Man mano che gli ambienti di backup crescono, possono sorgere problemi di scalabilità. Tali problemi includono finestre di backup con orari di attività più lunghi, ricerche di ripristino più lunghe e un maggiore carico di lavoro amministrativo.
La scalabilità deve essere valutata nell’ambito dell’intera architettura di backup e ripristino, non limitandosi a considerare la sola capacità di archiviazione. Man mano che l’ambiente dati cresce, il sistema dovrà supportare volumi di dati più grandi, un numero maggiore di carichi di lavoro, periodi di conservazione più lunghi e richieste di ripristino più impegnative senza generare costi eccessivi, complessità o rischi operativi. Deve inoltre continuare a soddisfare gli obiettivi di punto di ripristino (RPO) e gli obiettivi di tempo di ripristino (RTO) dell’organizzazione.
Cosa significa scalabilità in un ambiente di backup?
La scalabilità del backup è la capacità di un ambiente di backup di proteggere e ripristinare quantità crescenti di dati e carichi di lavoro, continuando a soddisfare i requisiti definiti in termini di prestazioni, costi, sicurezza, RPO e RTO.
Gli ambienti di backup non crescono in un unico modo. Il volume dei dati può aumentare, ma lo stesso vale per il numero di file, carichi di lavoro, sedi e requisiti di conservazione. Ciascuno di questi fattori esercita pressione su una parte diversa dell’infrastruttura di backup.
- Maggior quantità di dati: un numero maggiore di server, database, applicazioni e utenti aumenta la capacità protetta.
- Maggior numero di file e oggetti: miliardi di file possono esercitare una pressione considerevole sui cataloghi di backup e sui sistemi di metadati.
- Tassi di modifica più elevati: un maggior numero di dati che cambiano ogni giorno significa che è necessario eseguire il backup di più informazioni all’interno della stessa finestra temporale.
- Maggior numero di carichi di lavoro: macchine virtuali, database, container, applicazioni SaaS (Software as a Service) e account cloud introducono tutti requisiti di protezione diversi.
- Periodi di conservazione più lunghi: I requisiti normativi e le politiche aziendali possono richiedere che i dati di backup vengano conservati per mesi o anni.
Perché la capacità di backup e la scalabilità del backup non sono la stessa cosa
La capacità di backup è la quantità di dati che un sistema può archiviare e conservare. “La crescita dell’infrastruttura di backup si riferisce alla capacità dell’intero ambiente di protezione dei dati di gestire carichi di lavoro crescenti, mantenendo al contempo gli obiettivi di prestazioni, affidabilità, sicurezza e ripristino.
Man mano che l’ambiente di backup cresce, la capacità di archiviazione è solo uno degli aspetti da considerare. Dal punto di vista delle prestazioni operative, volumi di dati più elevati possono aumentare i requisiti di throughput del backup, l’elaborazione dei metadati e dei cataloghi, il traffico di replica e i costi di conservazione. Se questi componenti non scalano di pari passo con lo storage, le operazioni di backup di routine possono diventare più lente e costose.
Implicazioni della crescita per il ripristino. Maggiori sono i dati disponibili, più tempo può essere necessario per il ripristino, specialmente se occorre ripristinare più sistemi contemporaneamente. Anche con processi di backup riusciti, un’organizzazione potrebbe avere difficoltà a rispettare il proprio RTO se non dispone di un throughput di ripristino e di una capacità di ripristino sufficienti.
Un’architettura di backup scalabile deve quindi adattarsi alla crescita in diverse aree interconnesse:
- I componenti che trasferiscono e archiviano i dati di backup
- I componenti di catalogazione e indicizzazione utilizzati per individuare i punti di ripristino
- I componenti che gestiscono le politiche, la pianificazione, il monitoraggio e le risorse
- Piano di ripristino
Le prestazioni del backup su larga scala dovrebbero essere valutate in base alle esigenze di protezione continua e a quelle di ripristino. Un’architettura scalabile deve essere in grado di mantenere RPO e RTO definiti man mano che aumentano il volume dei dati, il numero di carichi di lavoro, la conservazione, la distribuzione geografica e la domanda di ripristino simultaneo.
Quali colli di bottiglia compaiono per primi man mano che gli ambienti di backup crescono?
I primi colli di bottiglia relativi alla scalabilità del backup compaiono in genere nelle finestre di backup, nella larghezza di banda di rete, nei servizi di metadati, nella replica, nelle prestazioni del repository o nell’infrastruttura di ripristino. Quale di questi si manifesti per primo dipende dalle caratteristiche del carico di lavoro e dall’architettura.
Le finestre di backup entrano in conflitto con l’attività di produzione
Man mano che aumenta la quantità di dati che cambiano ogni giorno, i processi di backup potrebbero occupare una percentuale maggiore della finestra di backup disponibile. I backup pianificati possono finire per coincidere con l’orario di lavoro o protrarsi nel ciclo di protezione successivo.
La crescita del catalogo e dei metadati rallenta il ripristino
Con l’aumentare dei sistemi, dei punti di ripristino, dei file e degli oggetti, il catalogo di backup diventa una componente architettonica sempre più importante.
Il catalogo deve supportare aggiornamenti continui, operazioni di ricerca, navigazione, reportistica e ripristino. In presenza di lunghi periodi di conservazione e di un numero elevato di oggetti, un’infrastruttura di metadati mal progettata può rendere difficile individuare rapidamente il punto di ripristino corretto.
I carichi di lavoro con file di piccole dimensioni generano un overhead sproporzionato
Il numero e la dimensione dei file possono avere un effetto significativo sulle prestazioni del backup. Un singolo file di database di grandi dimensioni e milioni di file di piccole dimensioni possono occupare la stessa quantità di spazio di archiviazione, ma i carichi di lavoro con file di piccole dimensioni in genere generano un overhead di elaborazione molto maggiore. L’enumerazione dei file, la raccolta dei metadati, i controlli delle autorizzazioni, l’indicizzazione e la ricreazione dei file possono tutti aumentare i tempi di backup e ripristino.
I test delle prestazioni dovrebbero quindi riflettere le caratteristiche reali del carico di lavoro piuttosto che il solo volume dei dati.
Le scelte architetturali potrebbero inoltre dover tenere conto della densità dei file di piccole dimensioni. A seconda dell’ambiente, le organizzazioni possono prendere in considerazione strategie quali snapshot del file system, backup a livello di immagine, storage a oggetti oppure il raggruppamento e l’archiviazione di grandi raccolte di file di piccole dimensioni prima della protezione.
I carichi di lavoro con file di piccole dimensioni sovraccaricano le operazioni sui metadati
Le moderne architetture di backup mantengono comunemente più copie dei dati protetti a garanzia di resilienza e ripristino. Ogni copia aggiuntiva influisce sulla pianificazione della capacità, e i dati di backup che non possono essere modificati o eliminati durante un periodo di conservazione specificato possono rendere tale impatto più significativo, poiché i dati protetti non possono essere rimossi prima della scadenza del loro periodo di conservazione.
La pianificazione della crescita dovrebbe tenere conto delle copie primarie e secondarie, della replica, della conservazione immutabile, dei blocchi legali che possono impedire ai dati di backup di scadere secondo il loro normale ciclo di vita, dei metadati, dello spazio temporaneo di ripristino e di altri costi generali associati al funzionamento dell’ambiente.
La velocità di ripristino riceve meno investimenti rispetto all’acquisizione
L’acquisizione dei backup riceve un’attenzione costante poiché i processi di backup vengono eseguiti regolarmente. Il ripristino su larga scala viene testato meno frequentemente, il che significa che le limitazioni di ripristino possono passare inosservate fino a quando non diventano critiche.
Le prestazioni di ripristino possono essere influenzate dalla velocità di lettura del repository, dalla frammentazione dei backup, dalla deduplicazione e dalla ricostruzione dei dati deduplicati durante i processi di ripristino, dalla capacità di rete, dal recupero e dall’egress dal cloud, dalla scansione antimalware e dalle prestazioni della destinazione di ripristino.
Quali metriche rivelano tempestivamente i problemi di scalabilità?
L’utilizzo della capacità fornisce solo un quadro parziale della situazione. Il monitoraggio dovrebbe quindi coprire l’intero servizio di protezione e ripristino. Tra le metriche utili figurano, tra le altre, l’utilizzo della finestra di backup, il ritardo in coda, la velocità di backup e ripristino, il tempo di risposta del catalogo, il ritardo di replica e la copertura RPO.
Architettura di backup “scale-up” vs. “scale-out”
Lo “scale-up” espande un sistema di backup esistente con più risorse. Lo “scale-out” espande la capacità aggiungendo sistemi o nodi e distribuendo i carichi di lavoro tra di essi.
Lo “scale-up” aggiunge CPU, memoria, storage o altre risorse a un sistema esistente. È generalmente facile da gestire, ma l’architettura rimane comunque soggetta alla capacità massima di quel sistema.
Lo scale-out aggiunge nodi, worker, unità di storage o altri servizi. Questo metodo può offrire una crescita più incrementale e potenzialmente consentire la distribuzione dei carichi di lavoro su più sistemi, ma comporta anche maggiori esigenze di coordinamento e operative.
Un processo passo dopo passo per la progettazione di un backup scalabile
Un’architettura di backup scalabile parte dalla crescita prevista dell’ambiente piuttosto che dalla sola infrastruttura attuale.
1. Modellare la crescita in base al carico di lavoro anziché utilizzare un’unica percentuale annuale
Monitorare la capacità protetta, il tasso di variazione giornaliero, il numero di oggetti, il volume dei processi, la conservazione, il numero di copie di backup e le finestre di backup disponibili per ciascuna delle principali categorie di carico di lavoro.
Database, macchine virtuali, file server, container e carichi di lavoro cloud presentano spesso requisiti di protezione molto diversi. Le previsioni dovrebbero inoltre tenere conto delle implementazioni pianificate delle applicazioni, delle migrazioni al cloud, delle acquisizioni, dei cambiamenti normativi e del ritiro dall’uso delle infrastrutture.
2. Convertire gli obiettivi di ripristino in requisiti di throughput
Gli obiettivi di ripristino dovrebbero determinare le esigenze misurabili dell’infrastruttura. Assegnare i requisiti di ripristino in base alla priorità delle applicazioni: non tutti i carichi di lavoro sono uguali. Alcune applicazioni critiche potrebbero necessitare di risorse di ripristino ad alte prestazioni, mentre i dati meno sensibili al fattore tempo possono avvalersi di percorsi di archiviazione e ripristino a costo inferiore.
3. Mappare i percorsi completi dei dati di backup e ripristino
Documentare l’intero percorso dei dati durante il ripristino, dallo storage di backup all’ambiente di produzione e dall’ambiente di produzione allo storage di backup. Ciò dovrebbe includere lo storage di origine, gli agenti di backup/strumenti di trasferimento dati, i collegamenti di rete, i firewall, le fasi di crittografia e deduplicazione, i repository, le destinazioni di replica, i servizi di catalogazione e le destinazioni di ripristino. La mappatura di ciascun componente aiuta a identificare dove la larghezza di banda potrebbe essere limitata, poiché l’elemento più lento in modo costante può limitare le prestazioni dell’intero processo di backup o ripristino.
Gli scenari di disastro introducono un’ulteriore considerazione: la contesa delle risorse condivise. Durante il ripristino, i servizi di rete, di calcolo, di identità e di archiviazione potrebbero essere già sottoposti a un carico elevato o parzialmente non disponibili. La pianificazione del ripristino dovrebbe quindi valutare se queste risorse condivise siano in grado di supportare il ripristino del backup contemporaneamente alla rimessa in linea di altri sistemi critici.
4. Definire gruppi di risorse di backup separati
Le organizzazioni dovrebbero prendere in considerazione domini di backup separati quando la geografia, i confini di sicurezza, la contesa dei carichi di lavoro o i requisiti di ripristino rendono difficile la gestione di un unico dominio condiviso. È possibile ridurre la contesa e limitare l’impatto di un guasto o di un carico di lavoro insolitamente impegnativo utilizzando worker di backup, pool di archiviazione, proxy o altre risorse indipendenti.
NOTA: La separazione comporta anche un sovraccarico gestionale. Ogni nuovo dominio richiede monitoraggio, applicazione di patch, gestione delle credenziali, pianificazione della capacità e test.
5. Automatizzare le decisioni relative al ciclo di vita e al posizionamento
Con l’aumento dei carichi di lavoro protetti, la configurazione manuale diventa sempre più difficile. Le pianificazioni di backup, i periodi di conservazione, i livelli di archiviazione, i requisiti di replica e le politiche di scadenza possono essere assegnati tramite automazione basata su policy. Il rilevamento automatizzato può inoltre aiutare a individuare nuovi sistemi che sono stati implementati senza un’adeguata protezione.
6. Aggiungere sicurezza senza creare un collo di bottiglia non misurabile
Sebbene la sicurezza sia una parte importante della moderna architettura di backup, i controlli di sicurezza aggiungono anche ulteriori requisiti. La pianificazione della capacità e delle prestazioni dovrebbe tenere conto della crittografia, dell’immutabilità, dell’autenticazione a più fattori, della scansione antimalware e degli ambienti di ripristino isolati.
Le organizzazioni dovrebbero inoltre mantenere backup offline e regolarmente testati. La CISA suggerisce di archiviare i backup offline e crittografati, e di testare regolarmente la disponibilità e l’integrità dei backup per garantire che rimangano utilizzabili in caso di un incidente di ransomware o di altri scenari di ripristino.
7. Testare la crescita e il ripristino prima che la produzione raggiunga il limite
I test dovrebbero basarsi sui requisiti previsti, non solo sui livelli attuali di carico di lavoro. I test di carico e di ripristino dovrebbero misurare il volume dei dati, la concorrenza dei processi, le prestazioni del catalogo, l’utilizzo del repository, la replica, gli scenari di guasto e la velocità di ripristino.
Lista di controllo per la scalabilità del backup
Quando si progetta l’architettura di backup, utilizzare questa lista di controllo per verificare se è in grado di soddisfare i requisiti attuali e la crescita futura:
- Capacità protetta attuale: la quantità totale di dati attualmente sottoposti a backup.
- Tasso di crescita: il tasso annuo con cui si prevede che i dati protetti crescano.
- Tasso di variazione giornaliero: percentuale o volume di dati che cambia tra un ciclo di backup e l’altro.
- Numero di file o oggetti: il numero di singoli file, oggetti o record che il sistema di backup deve gestire.
- Finestra di backup: il periodo di tempo disponibile per l’esecuzione dei backup pianificati.
- RPO richiesto: la perdita massima tollerabile di dati misurata in termini di tempo.
- RTO richiesto: il tempo massimo accettabile per il ripristino di sistemi o dati.
- Throughput di ripristino: la velocità con cui l’ambiente di backup è in grado di restituire i dati durante un ripristino.
- Numero di copie nel backup: quante copie devono essere conservate e dove?
- Periodo di conservazione immutabile: il periodo minimo di tempo durante il quale le copie di backup devono essere protette da modifiche o cancellazioni.
- Larghezza di banda di replica: la velocità di trasferimento richiesta alla rete per trasferire i dati di backup tra ambienti o sedi.
Come dimostrare che un’architettura di backup è scalabile
Eseguire test di carico e di ripristino per dimostrare la scalabilità del backup e del ripristino in base ai volumi di dati previsti, alla concorrenza, alla conservazione, ai guasti e ai requisiti di ripristino.
Le specifiche dei fornitori e i valori di throughput pubblicati sono utili ai fini del confronto, ma non garantiscono le prestazioni in un ambiente specifico. I risultati effettivi dipendono da fattori quali il tipo di dati e la dimensione dei file, la frequenza delle modifiche, la compressione e la deduplicazione, la crittografia, la latenza di rete, le prestazioni della sorgente, la progettazione del repository e l’infrastruttura di ripristino.
Una prova di concetto significativa dovrebbe quindi riprodurre le condizioni che l’organizzazione si aspetta di incontrare man mano che cresce.
I test dovrebbero includere anche il ripristino da ransomware ed eventi distruttivi che compromettono i dati. Il NIST SP 1800-11 fornisce linee guida sul recupero dei dati dopo eventi distruttivi, con particolare enfasi sulla convalida dell’integrità dei dati e sulla garanzia che le informazioni recuperate siano affidabili e possano essere utilizzate in sicurezza.
Perché i costi del backup spesso crescono più rapidamente dei dati
I costi del backup possono crescere più rapidamente dei dati protetti. Ciò è dovuto al fatto che la crescita può comportare contemporaneamente un aumento delle copie di archiviazione, della conservazione, della replica, delle licenze, del traffico di rete, del recupero dal cloud, dell’infrastruttura di gestione e dell’impegno amministrativo.
È necessario elaborare un modello di costo realistico che consideri un periodo di pianificazione di almeno tre anni e includa:
- Crescita dei dati e tassi di variazione giornalieri
- Conservazione, replica, immutabilità e blocchi legali
- Licenze software e assistenza
- Requisiti di aggiornamento dello storage e dell’hardware
- Costi di archiviazione cloud, operazioni, recupero e trasferimento dei dati in uscita dal cloud (egress)
- Costi di rete e di trasferimento interregionale
- Infrastruttura di catalogazione e gestione
- Test di ripristino e risorse temporanee per il ripristino
- Amministrazione, monitoraggio, applicazione delle patch e risposta agli incidenti
- Costi di migrazione o di uscita dalla piattaforma
In che modo Bacula Enterprise supporta il backup scalabile
Bacula Enterprise si distingue come una soluzione di backup e ripristino particolarmente scalabile, in grado di offrire risposte realistiche alle problematiche legate alla scalabilità qui discusse. Utilizza un’architettura modulare, per cui i componenti di gestione del backup, dei servizi client, dello storage e del catalogo possono essere implementati separatamente in base alle esigenze dell’ambiente.
La piattaforma supporta un ampio spettro di categorie di carichi di lavoro, inclusi sistemi fisici e virtuali, database, container e ambienti cloud. Ciò la rende ideale per le organizzazioni che devono proteggere più tipi di infrastruttura nell’ambito di un’unica strategia di backup.
In termini di scalabilità, il design modulare consente di distribuire l’elaborazione dei backup, l’archiviazione e i servizi associati man mano che il volume dei dati e i requisiti di carico di lavoro aumentano. Pertanto, per le organizzazioni in rapida crescita, questa architettura può essere presa in considerazione nell’ambito di una valutazione più ampia di come l’infrastruttura di backup possa scalare nel tempo.
L’architettura di Bacula favorisce lo scale-up e lo scale-out in molti modi diversi. Ecco alcuni esempi:
Volumi di dati enormi: Scala dagli ambienti aziendali convenzionali alle infrastrutture HPC e di intelligenza artificiale da diversi petabyte.
B Miliardi di file: HPCAccelerator distribuisce i carichi di lavoro del file system tra worker concorrenti, consentendo una protezione efficiente di miliardi di file.
Elaborazione parallela: È possibile eseguire contemporaneamente più flussi di backup e ripristino, aumentando notevolmente la velocità di elaborazione.
Elevata concorrenza dei processi: Supporta migliaia di processi di backup simultanei in ambienti estesi e complessi.
Architettura distribuita: I componenti di backup possono essere distribuiti su più server, reti e sedi per evitare di dipendere da un unico collo di bottiglia nell’elaborazione.
Integrazione parallela del file system: Funzionalità dedicate per Lustre e IBM Storage Scale/GPFS aiutano a proteggere in modo efficiente file system estremamente grandi e ad alte prestazioni.
Backup incrementali efficienti: Tecnologie come Lustre Changelog e BSnapDiff identificano i dati modificati senza dover scansionare ripetutamente l’intero file system di grandi dimensioni.
Scalabilità dello storage: I clienti possono espandersi su risorse di disco, nastro, object storage e cloud senza essere vincolati a un unico fornitore o tecnologia di storage.
Scalabilità del carico di lavoro: Un’unica piattaforma è in grado di proteggere server fisici, macchine virtuali, container, database, carichi di lavoro cloud e ambienti HPC man mano che l’infrastruttura si espande.
Scalabilità economica: Bacula non applica costi in base al volume dei dati protetti, pertanto i set di dati in rapida crescita non comportano automaticamente un aumento altrettanto rapido dei costi di licenza.
Queste funzionalità rendono Bacula scalabile sia dal punto di vista tecnico che economico, in particolare per HPC, IA, infrastrutture IT complesse, ricerca e ambienti di grandi imprese.
Domande frequenti
L’archiviazione cloud può rendere un sistema di backup automaticamente scalabile?
L’archiviazione cloud può fornire una capacità virtualmente elastica, ma non elimina altre limitazioni. Il software di backup, la larghezza di banda di rete, i limiti delle API (interfacce di programmazione delle applicazioni), i servizi di metadati, le prestazioni di recupero, i costi di uscita e l’infrastruttura di ripristino possono tutti influire sulla scalabilità. L’archiviazione cloud dovrebbe quindi essere valutata come parte dell’architettura completa di backup e ripristino.
Quanta capacità di riserva dovrebbe mantenere un repository di backup scalabile?
Non esiste una percentuale universale applicabile a ogni ambiente. La pianificazione della capacità dovrebbe tenere conto della crescita prevista dei dati, dei tassi di variazione giornalieri, dei periodi di conservazione, delle copie immutabili, della replica, degli aumenti temporanei del carico di lavoro, dei guasti hardware o dei nodi e del tempo necessario per procurarsi e implementare capacità aggiuntiva.
La deduplicazione migliora sempre la scalabilità del backup?
No. La deduplicazione può ridurre il consumo di spazio di archiviazione e il traffico di rete, ma la sua efficacia dipende dal tipo di dati protetti. Richiede inoltre risorse di elaborazione e metadati e può influenzare le prestazioni di ripristino a seconda dell’implementazione. Sia l’efficienza del backup che le prestazioni di ripristino dovrebbero essere misurate con carichi di lavoro rappresentativi.
Quando un’organizzazione dovrebbe suddividere un unico ambiente di backup in più domini?
Potrebbe essere opportuno disporre di domini di backup separati quando un unico ambiente comporta contese sulle risorse, problemi di sicurezza, requisiti di residenza dei dati o dipendenze operative tra carichi di lavoro separati dal punto di vista geografico o organizzativo. L’obiettivo dovrebbe essere quello di creare confini utili, senza però generare silos gestionali superflui. Il monitoraggio centralizzato, la gestione delle policy e la reportistica possono garantire visibilità su più ambienti.
Un sistema di backup può scalare se il ripristino rimane manuale?
Solo in misura limitata. Man mano che il numero di carichi di lavoro protetti aumenta, le attività di ripristino manuali, quali la sequenzializzazione delle applicazioni, la gestione delle credenziali, la configurazione delle reti e la convalida dei dati ripristinati, possono diventare colli di bottiglia significativi.
