Backup e ripristino dei mainframe: strategie moderne per sistemi aziendali resilienti

Qual è il panorama attuale del backup e del disaster recovery dei mainframe?

In un ambiente IT, in particolare nell’IT aziendale, il backup mainframe rimane una delle discipline più critiche e spesso sottovalutate.

Le transazioni finanziarie, i file assicurativi e i programmi governativi dipendono sempre più dai mainframe, il che significa che anche i rischi di downtime del sistema sono ai massimi livelli. Una soluzione di backup per mainframe deve essere in grado di soddisfare un tipo di esigenza che il tipico sistema di backup distribuito non è mai stato progettato per offrire.

Perché i mainframe richiedono ancora approcci specializzati per il backup e il ripristino?

Un mainframe non è semplicemente un server di grandi dimensioni. La sua architettura è stata costruita attorno al concetto di disponibilità continua, throughput I/O massiccio e separazione del carico di lavoro – fattori che determinano la progettazione e l’esecuzione dei backup a un livello fondamentale.

Un ambiente z/OS che gestisce migliaia di transazioni al secondo non può consentire le stesse finestre di backup, gli stessi modelli di coerenza e le stesse procedure di ripristino utilizzati dai file server Linux.

I sistemi di backup dei mainframe devono gestire una serie di elementi che sono unici per la piattaforma e non esistono altrove – dataset VSAM, cataloghi z/OS, strutture di accoppiamento e ambienti sysplex – che richiedono tutti meccanismi propri. Eseguire un backup di un cluster VSAM è molto diverso dall’eseguire un backup di un albero di directory, mentre il ripristino di un sysplex in uno stato coerente richiede un coordinamento che va ben oltre le capacità degli strumenti di backup generici.

Anche la scalabilità è un problema a sé stante. I mainframe gestiscono regolarmente volumi di dati dell’ordine dei petabyte, con requisiti SLA rigorosi che impongono che il processo di backup operi in concomitanza con il lavoro di produzione senza alcun impatto percepibile. Questo vincolo da solo esclude un gran numero di soluzioni standard.

Quali sono le minacce e le modalità di guasto più comuni per gli ambienti mainframe?

Sebbene estremamente affidabili per loro natura, i mainframe non sono invincibili. I tipi di guasti che possono mettere a rischio un ambiente mainframe sono numerosi e una strategia di backup mainframe adeguata deve tenerne conto:

• Guasto hardware – Degrado del sottosistema di archiviazione, guasti ai canali o ai processori, che possono danneggiare i dati o renderli inaccessibili anche senza un’interruzione completa del sistema
• Errore umano – Cancellazione accidentale di set di dati, lavori JCL configurati in modo errato o aggiornamenti errati del catalogo, che rappresentano una quota significativa degli eventi di ripristino nel mondo reale
• Errori di software e applicazioni – Bug nella logica di elaborazione batch o nel middleware che scrivono dati errati, che potrebbero non emergere fino a quando i record non si sono già propagati a valle
• Ransomware e attacchi dannosi – Un vettore di minaccia sempre più rilevante, discusso in modo approfondito nella sezione seguente
• Disastri a livello di sito – Interruzioni di corrente, allagamenti o guasti all’infrastruttura fisica che interessano un intero data center

Nessuna singola minaccia ha la precedenza sulle altre. Il failover hardware non è sufficiente senza la gestione dei dati logicamente danneggiati, e viceversa, quando si decide la strategia di backup del mainframe.

In che modo i moderni requisiti aziendali modificano le aspettative relative al backup e al DR?

Anche la definizione di “recuperabile” è cambiata notevolmente nel corso degli anni.

Un obiettivo RTO di 4 ore poteva essere ragionevole un decennio fa per un discreto numero di carichi di lavoro. I team di continuità operativa odierni puntano a un RTO pari a zero (o molto vicino allo zero) per le applicazioni critiche, spinti dal commercio digitale, dalle reti di pagamento in tempo reale e dalle normative che trattano le interruzioni significative come una violazione della conformità normativa anziché come un inconveniente operativo.

Molte di queste aspettative sono state ora documentate all’interno delle strutture normative. In base a quadri normativi come DORA e PCI DSS, le organizzazioni sono ora tenute a definire formalmente e a testare regolarmente gli obiettivi di ripristino. Il mancato rispetto di questi impegni è considerato una violazione della conformità e viene trattato di conseguenza.

Per le organizzazioni che utilizzano i mainframe come elemento centrale della propria attività, questa dimensione normativa rende la pianificazione del disaster recovery (DR) una responsabilità di governance, non solo tecnica.

Perché le strategie di backup dei mainframe si stanno evolvendo nell’era delle minacce informatiche?

Le moderne minacce informatiche hanno cambiato ciò che un backup mainframe deve essere in grado di fare. Gli ambienti mainframe si sono a lungo affidati a funzionalità di resilienza appositamente progettate – mirroring, copia point-in-time e ridondanza a più livelli – che erano altamente efficaci contro i modelli di minaccia per cui erano state progettate: guasti hardware, errori umani e disastri a livello di sito.

Purtroppo, l’aumento di attacchi complessi di ransomware e alla catena di approvvigionamento ha introdotto una nuova serie di problemi in cui anche i backup sono presi di mira. L’emergere di gruppi di ransomware come Conti – i cui playbook di attacco documentati elencavano l’identificazione e la distruzione dei backup come obiettivo primario prima di attivare la crittografia – ha introdotto un modello di minaccia che le strategie di backup aziendali non erano state progettate per affrontare.

In che modo il ransomware prende di mira gli ambienti legacy e mainframe?

L’ipotesi che i mainframe siano intrinsecamente protetti dal ransomware in virtù della loro architettura è stata storicamente molto diffusa. Tuttavia, tale ipotesi viene sempre più messa in discussione man mano che gli ambienti mainframe diventano più profondamente integrati con i sistemi aperti e le infrastrutture distribuite.

I moderni autori di ransomware sono calcolatori e metodici; scansionano e mappano l’infrastruttura prima di attivare un payload, cercando specificamente i repository e i cataloghi di backup per disabilitare qualsiasi meccanismo di ripristino prima di avviare il processo di crittografia.

Gli ambienti mainframe presentano un rischio di esposizione particolare attraverso i loro punti di integrazione. I sistemi z/OS comunicano costantemente con reti distribuite, livelli di archiviazione cloud e middleware di sistemi aperti (ognuno dei quali può fungere da punto di ingresso). Man mano che gli ambienti mainframe si integrano sempre più profondamente con l’infrastruttura distribuita, la superficie di attacco si espande: la compromissione di un sistema connesso potrebbe, in architetture di rete sufficientemente piatte, fornire un percorso verso i livelli di archiviazione condivisa su cui risiedono i set di dati di backup del mainframe.

In molte configurazioni, i cataloghi di backup mainframe e i set di dati di controllo risiedono sullo stesso fabric di archiviazione dei dati che proteggono – il che significa che un aggressore in posizione favorevole, o un evento di corruzione che si propaga attraverso l’archiviazione condivisa, potrebbe colpire entrambi contemporaneamente. Non ci vuole molto a giungere alla conclusione che un catalogo di backup che esiste sullo stesso fabric di archiviazione dei dati stessi potrebbe essere corrotto e distrutto nello stesso incidente.

Questa situazione deve ora essere affrontata dalle moderne architetture di backup mainframe.

Qual è il ruolo dei backup immutabili e con isolamento fisico nei mainframe?

Questi sono i due approcci architetturali principali per combattere il ransomware: l’immutabilità e l’air-gap. Sebbene siano due dei concetti principali discussi in relazione alla risoluzione del problema del ransomware, in realtà funzionano in modi diversi.

I due approcci non si escludono a vicenda. Una strategia di backup mainframe ben sviluppata può comprendere entrambi: una copia immutabile per garantire il ripristino in tempi brevissimi in scenari di attacchi logici e una copia air-gapped per il ripristino definitivo in circostanze in cui anche l’immutabilità a livello di archiviazione è stata violata (tramite l’uso di account amministratore privilegiati o attacchi mirati direttamente al livello di archiviazione).

Laddove l’immutabilità a livello di storage non è già fornita in modo nativo – come avviene, ad esempio, tramite IBM DS8000 Safeguarded Copy e il framework Z Cyber Vault – l’implementazione su z/OS richiede un’attenta integrazione con gli strumenti di backup esistenti per garantire che le politiche di immutabilità siano applicate a livello di storage piuttosto che solo a livello di applicazione (dove potrebbero essere potenzialmente aggirate).

In che modo i principi zero-trust si applicano alle architetture di backup dei mainframe?

z/OS ha incorporato molti dei principi ora associati all’architettura zero-trust – controlli di accesso obbligatori, rigorosa separazione dei compiti e audit trail completi – da molto prima che il termine entrasse nel discorso mainstream sulla sicurezza. Per quanto riguarda specificamente il backup mainframe, la questione non riguarda tanto l’introduzione dei concetti zero-trust, quanto piuttosto la garanzia che le politiche RACF o ACF2 siano configurate in modo da applicare tali principi in modo coerente all’ambiente di backup, che a volte viene considerato a rischio inferiore rispetto alla produzione e al quale viene consentito di accumulare privilegi eccessivi nel tempo.

Quando si parla di backup mainframe, lo zero-trust implica che nessun dispositivo, utente o processo (nemmeno gli amministratori di backup) sia mai considerato in possesso di accesso implicito o capacità di gestire i dati di backup. In termini pratici, ciò implicherebbe una rigorosa separazione dei compiti, l’autenticazione a due fattori per la console di gestione del backup e permessi rigorosamente basati sui ruoli che limitino chi è autorizzato a cancellare/modificare/disabilitare i lavori di backup.

Su z/OS, ciò si traduce in una progettazione delle politiche RACF o ACF2 che limita esplicitamente l’accesso al catalogo di backup, combinata con avvisi fuori banda per qualsiasi azione amministrativa che modifichi le impostazioni di conservazione o le pianificazioni di backup. L’ambiente di backup mainframe dovrebbe essere trattato come un sistema critico per la sicurezza, in modo che sia i cicli di revisione degli accessi che le tracce di audit soddisfino gli stessi standard applicati ai dati di produzione.

Quali obiettivi di ripristino dovrebbero guidare la strategia di backup del mainframe?

Gli obiettivi di ripristino non dovrebbero essere fissati e poi ignorati, poiché costituiscono la base dell’intera architettura di backup del mainframe su base contrattuale. Tutte le decisioni oltre questo punto (riguardanti la frequenza dei backup, la topologia di replica, le scelte relative ai livelli di storage) devono derivare da RTO e RPO stabiliti. Le aziende che saltano questo passaggio di solito scoprono le loro lacune durante un evento di disastro reale – il momento peggiore in cui ciò possa accadere.

Qual è la differenza tra RTO e RPO per i carichi di lavoro mainframe?

RTO e RPO sono concetti ben noti nel campo del DR, ma il loro effetto nel contesto del mainframe è piuttosto significativo e può assumere significati molto diversi rispetto alle stesse metriche nei sistemi distribuiti.

L’RPO (Recovery Point Objective), ovvero il lasso di tempo massimo accettabile per la perdita di dati, è particolarmente difficile da definire per i mainframe a causa delle relazioni tra le transazioni. Un mainframe che elabora transazioni di pagamento ad alto volume potrebbe facilmente avere milioni di record all’ora distribuiti su una serie di set di dati accoppiati.

L’RPO non è solo un’istantanea scattata ripetutamente dopo un determinato periodo di tempo, ma implica l’acquisizione di tutti i set di dati accoppiati, i cataloghi e le strutture di accoppiamento in un particolare momento.

L’RTO (Recovery Time Objective), ovvero il tempo massimo assegnato alle operazioni di ripristino, presenta delle complessità specifiche nei mainframe. Il ripristino di un ambiente z/OS non equivale all’avvio di una macchina virtuale da un’istantanea.

Il più delle volte le aziende non si rendono conto del loro vero valore RTO fino a quando non eseguono un test di ripristino – a quel punto nessuno può chiudere gli occhi sul divario tra il tempo di ripristino ipotizzato e quello effettivo.

Entrambi gli obiettivi devono essere definiti per carico di lavoro, non per sistema. Un singolo mainframe può ospitare applicazioni con tolleranze molto diverse per la perdita di dati e il tempo di inattività, ed è proprio questo che la classificazione per livello di criticità è progettata per affrontare.

In che modo i livelli di criticità dovrebbero influenzare la frequenza e la conservazione dei backup?

Non tutti i carichi di lavoro in esecuzione su un mainframe dovrebbero – né possono permettersi – di essere protetti allo stesso modo. La classificazione in base alla criticità è il processo attraverso il quale la criticità aziendale si traduce in una politica di backup concreta. Essa assegna risorse adeguate ai carichi di lavoro per i quali è prevista la finestra di ripristino più lunga, evitando al contempo un eccesso di protezione per i carichi di lavoro in cui è tollerabile una finestra di ripristino più ampia.

Un modello pratico di classificazione opera tipicamente su tre livelli:

L’assegnazione dei livelli dovrebbe essere guidata dall’analisi dell’impatto sul business piuttosto che dalla convenienza tecnica e dovrebbe essere rivista almeno una volta all’anno: la criticità dei carichi di lavoro cambia con l’evolversi delle priorità aziendali e un set di dati che l’anno scorso era di livello 2 potrebbe essere già considerato di livello 1 oggi.

In che modo la conformità e gli SLA influenzano gli obiettivi di ripristino?

Non solo i framework di ripristino incentivano una solida pianificazione del ripristino, ma molti richiedono ora risultati concreti e verificabili.

• La normativa DORA impone alle entità finanziarie di definire e testare le capacità di ripristino rispetto a metriche predefinite
• Il PCI DSS stabilisce requisiti specifici di disponibilità e integrità per i sistemi che accedono ai dati dei titolari di carte
• La norma HIPAA sulla disponibilità stabilisce gli obblighi per il mantenimento dell’accesso alle informazioni sanitarie protette (PHI) in circostanze specificate

L’effetto pratico è che gli obiettivi di ripristino di un carico di lavoro regolamentato non sono più soggetti al solo giudizio interno. Ogni volta che gli SLA e i requisiti normativi si sovrappongono, viene scelto il requisito più rigoroso. Pertanto, la soluzione di backup per mainframe deve essere progettata, testata e documentata in modo da soddisfare sia i revisori esterni che le esigenze interne.

Quali opzioni di backup in loco esistono per i mainframe?

Il backup in loco dei mainframe attinge da tre distinte categorie tecnologiche:

• Backup su nastro (fisico e virtuale)
• Backup da disco a disco
• Copie point-in-time

Ciascuna di queste opzioni risponde a diverse esigenze di ripristino e vincoli operativi. La consapevolezza di dove si colloca ciascun approccio è alla base di qualsiasi strategia di backup per mainframe ben progettata.

Come funzionano i backup basati su DASD (emulazione nastro, nastri virtuali) sui mainframe?

Il backup su dispositivi di archiviazione ad accesso diretto (DASD) fa parte degli ambienti mainframe da molti anni, ma la tecnologia effettiva è cambiata in modo significativo nel corso del tempo.

Le librerie a nastro virtuali (VTL) sono ampiamente utilizzate negli ambienti mainframe come livello di prestazioni davanti al nastro fisico, presentando un’interfaccia a nastro a z/OS mentre scrivono i dati su uno storage basato su disco prima che vengano migrati su nastro fisico per una conservazione a lungo termine. Una VTL si comporta come un dispositivo a nastro fisico dal punto di vista del software mainframe, ma scriverà i dati su uno storage basato su disco.

Di conseguenza, uno script JCL o di automazione scritto per i backup su nastro fisico può essere riutilizzato per i backup VTL con modifiche minime o nulle, garantendo prestazioni migliori senza la necessità di cambiare l’intera infrastruttura di backup.

Il nastro fisico rimane ancora oggi il supporto di backup principale nella maggior parte degli ambienti mainframe, con i VTL che fungono da intermediari ottimizzati in termini di prestazioni che preservano le pratiche operative basate su nastro, riducendo al contempo la manipolazione meccanica e migliorando la velocità di backup.

Quando è preferibile optare per i backup da disco a disco rispetto alle soluzioni su nastro?

La decisione di implementare il backup da disco a disco o su nastro per i mainframe non è solo di natura tecnica, ma è spesso determinata da una combinazione di esigenze di ripristino, realtà aziendali e considerazioni economiche.

Il backup da disco a disco è la scelta migliore quando:

• La velocità di ripristino è una priorità: i ripristini su disco si completano in una frazione del tempo necessario per individuare, montare e leggere un volume su nastro, il che influisce direttamente sul raggiungimento dell’RTO
• Le finestre di backup sono ristrette: i target su disco ad alta velocità di trasmissione possono assorbire i dati di backup più rapidamente rispetto al nastro, riducendo il rischio che i processi superino la finestra loro assegnata
• Sono previsti test di ripristino frequenti: i ripristini su nastro comportano un sovraccarico operativo che scoraggia i test regolari di DR, mentre le destinazioni su disco rendono i test di ripristino una routine
• È necessario un ripristino granulare: il ripristino di un singolo set di dati o di un numero ridotto di record dal disco è significativamente più pratico rispetto alla ricerca tra i volumi su nastro per individuare dati specifici

Il nastro è ancora adatto per applicazioni in cui l’archiviazione a lungo termine, l’archiviazione normativa o l’archiviazione fuori sede lo rendono conveniente. Tuttavia, per i carichi di lavoro con requisiti RTO rigorosi o esigenze di test di ripristino frequenti, il disco-a-disco può offrire un vantaggio operativo significativo come complemento al backup primario basato su nastro.

Che ruolo svolgono le tecnologie di snapshot e point-in-time sul mainframe?

Gli snapshot occupano una posizione specifica nel panorama del backup dei mainframe; non rappresentano un’alternativa al backup, ma un’estensione delle funzionalità di backup esistenti. Risultano particolarmente utili nei casi in cui le restrizioni delle finestre di backup convenzionali o le esigenze di granularità del ripristino superano le capacità che i processi pianificati possono fornire da soli.

Su z/OS, le tecnologie di copia point-in-time creano una copia dipendente istantanea di un set di dati o di un volume senza interrompere l’I/O di produzione; IBM FlashCopy è l’opzione più importante sul mercato. Le caratteristiche chiave che definiscono come queste tecnologie si inseriscono in una strategia di backup mainframe includono:

• Requisiti di coerenza: uno snapshot di un singolo volume è semplice, ma l’acquisizione di un’immagine coerente in un determinato momento su più volumi correlati in un ambiente OLTP molto trafficato richiede un attento coordinamento per evitare di acquisire dati durante una transazione
• Granularità del ripristino: gli snapshot consentono un rapido ripristino a uno stato recente noto come corretto, ma in genere vengono conservati per periodi più brevi rispetto alle copie di backup tradizionali, rendendoli inadatti come unico meccanismo di ripristino
• Overhead di storage: le copie dipendenti consumano capacità di storage aggiuntiva e la relazione tra i volumi di origine e di destinazione deve essere gestita con attenzione per evitare di influire sulle prestazioni di produzione

Gli snapshot, se utilizzati correttamente, fungono da livello di ripristino rapido in un progetto di backup mainframe a più livelli, dove possono gestire scenari di ripristino frequenti e recenti, mentre il backup tradizionale si occupa dello storage a lungo termine fuori sede.

Quali architetture di disaster recovery off-site e remote sono disponibili?

L’architettura di DR off-site è quella in cui il backup mainframe e la pianificazione della continuità operativa sono maggiormente interconnessi. Le decisioni specifiche nell’architettura di DR off-site – la modalità di replica, la topologia del sito, la strategia di archiviazione – influenzano non solo il potenziale di ripristino a livello di sito, ma anche la sua velocità e completezza in condizioni reali.

In che modo la replica sincrona rispetto a quella asincrona influisce sulla recuperabilità?

La modalità di replica è probabilmente una delle decisioni architetturali più significative per una configurazione di disaster recovery mainframe, poiché la modalità di replica specifica effettivamente la quantità minima teorica di dati che le aziende possono permettersi di perdere durante qualsiasi scenario di failover.

Nella maggior parte dei casi non si tratta di una scelta semplice e binaria. Molti sistemi mainframe utilizzano la replica sincrona verso un sito secondario adiacente per esigenze di continuità operativa, abbinata alla replica asincrona verso un sito terziario più remoto per scenari di disastri catastrofici. In questo modo, riescono ad accettare un RPO più ampio per la separazione geografica del backup, poiché un collegamento sincrono su una grande distanza non sarebbe semplicemente pratico.

Quali sono i pro e i contro dei siti DR attivi-attivi rispetto a quelli attivi-passivi?

La topologia del sito – ovvero il modo in cui il sito secondario si relaziona con la produzione durante le normali operazioni – determina sia il profilo dei costi che il comportamento di ripristino dell’intera architettura DR.

Una configurazione attivo-attivo esegue i carichi di lavoro di produzione in entrambi i siti contemporaneamente. In questo caso, la distribuzione del carico di lavoro avviene attraverso il sysplex. Il vantaggio principale di questa architettura è che il failover non è un evento discreto, poiché la capacità è già presente nel sito di DR e il passaggio da un funzionamento ridotto a uno completo è significativamente più breve rispetto a qualsiasi scenario di avvio a freddo. I backup e la replica per il mainframe vengono sempre utilizzati anziché rimanere inattivi, motivo per cui i guasti all’interno della postura di DR si verificano durante il normale funzionamento, non in caso di un vero e proprio disastro.

In questo caso, i compromessi riguardano sia i costi che la complessità. L’architettura active-active richiede un’infrastruttura completa di livello produttivo in entrambi i siti, con un bilanciamento continuo del carico di lavoro e un’attenta progettazione delle applicazioni per gestire la coerenza distribuita nelle transazioni. Tenendo presente questo, l’architettura active-active può introdurre più rischi di quanti ne possa eliminare per le organizzazioni i cui carichi di lavoro mainframe sono strettamente integrati tra loro o difficili da partizionare.

Gli ambienti active-passive mantengono un sito di backup caldo e inattivo, riducendo notevolmente la spesa hardware. Ciò implica che le soluzioni di backup mainframe che servono questo sito manterranno l’ambiente passivo abbastanza aggiornato da soddisfare i requisiti RTO – una sfida che crescerà man mano che il livello di aggiornamento tra primario e secondario diverge. Ciò che non può essere aggirato riguardo all’active-passive è il fatto che il failover comporta un periodo di transizione effettivo, e tale periodo deve essere testato regolarmente per confermare che rientri nei limiti accettabili.

Quando è opportuno il tape vaulting remoto o il tape basato su cloud?

Il nastro – sia esso fisico o basato su cloud – rimane un elemento centrale dell’architettura di backup mainframe, soddisfacendo requisiti che le alternative basate su disco non sempre riescono a soddisfare, inclusi i requisiti di air-gap e di conservazione dei supporti fisici esplicitamente richiesti da framework come il PCI DSS. Il nastro rimane appropriato in una serie definita di condizioni:

• Conservazione normativa a lungo termine – dove i mandati richiedono anni o decenni di conservazione dei dati e il costo di mantenere tali dati su disco o in uno storage cloud attivo è proibitivo
• Requisiti di air-gap – dove le politiche o le normative richiedono una copia dei dati di backup che sia fisicamente o logicamente scollegata da tutte le infrastrutture accessibili dalla rete
• Carichi di lavoro di archiviazione a cui si accede raramente – dove la probabilità di dover ripristinare i dati è sufficientemente bassa da rendere la latenza di recupero un compromesso accettabile rispetto al costo di archiviazione
• Protezione supplementare per i livelli di backup attivi – dove il nastro funge da copia a valle dei backup su disco piuttosto che da meccanismo di ripristino primario

Ciò che il tape vaulting non dovrebbe essere è la soluzione di backup mainframe primaria per qualsiasi carico di lavoro con requisiti RTO significativi. Il sovraccarico operativo legato alla localizzazione, alla spedizione e al montaggio dei supporti fisici – o al recupero e alla preparazione dei nastri basati su cloud – lo rende strutturalmente inadatto a scenari di ripristino sensibili al fattore tempo.

In che modo la mobilità dei dati e l’integrazione multipiattaforma influiscono sul ripristino dei mainframe?

Il ripristino del mainframe non viene eseguito in modo isolato. L’infrastruttura aziendale è ormai strettamente interconnessa; i motori di transazione del mainframe popolano database distribuiti, le applicazioni dei sistemi aperti estraggono i dati dal mainframe e li utilizzano in tempo reale, mentre i livelli API integrano le piattaforme in modo trasparente e senza soluzione di continuità, creando numerose interdipendenze che spesso vengono trascurate nella pianificazione del Disaster Recovery.

Considerare il backup e il ripristino del mainframe come un’operazione a sé stante – ripristinando set di dati, cataloghi e sottosistemi senza tenere conto della coerenza dei sistemi distribuiti dipendenti – produrrà quasi certamente un mainframe tecnicamente ripristinato con cui il resto dell’ambiente aziendale non potrà interagire in modo utile.

Come è possibile integrare i dati del mainframe con i sistemi distribuiti e aperti per il DR?

In un panorama aziendale moderno è raro che i carichi di lavoro del mainframe vengano eseguiti all’interno dei propri ambienti isolati. I motori di transazione del mainframe inviano i dati a feed che alimentano applicazioni di analisi a valle, mentre i motori di transazione z/OS inviano i dati a database distribuiti che le applicazioni web-enabled utilizzano in tempo reale.

In caso di ripristino del mainframe, non si tratta della capacità di ripristinare il mainframe, ma della possibilità di riportare l’intero sistema dipendente in uno stato di funzionamento coerente insieme ad esso. Le possibili tecniche di integrazione che supportano questo aspetto includono tutto, dalla replica dei dati basata su API alle architetture di condivisione dello storage in cui il mainframe e i sistemi distribuiti possono accedere agli stessi pool di dati.

La scelta giusta dipende in gran parte dalla latenza accettabile, dal volume di dati e da quanto siano critici i requisiti di coerenza tra i due sistemi. L’elemento cruciale del processo di backup del mainframe è che questi punti di integrazione siano esplicitamente mappati e inclusi nella pianificazione del DR, invece di essere trattati come un problema di qualcun altro.

Quali sfide sorgono quando si sincronizzano carichi di lavoro mainframe e non mainframe?

La sincronizzazione multipiattaforma è il punto in cui i piani di DR eterogenei falliscono maggiormente. Le sfide tecniche e operative sono sufficientemente specifiche da giustificare un’attenzione particolare:

• Disallineamento dei confini delle transazioni – i sistemi mainframe gestiscono tipicamente le transazioni con garanzie ACID a livello di set di dati, mentre i sistemi distribuiti possono utilizzare modelli di coerenza diversi, rendendo difficile stabilire un unico punto di ripristino valido contemporaneamente in entrambi gli ambienti
• Dipendenze temporali – i lavori batch che estraggono dati dal mainframe per l’elaborazione a valle creano dipendenze temporali implicite che raramente sono documentate formalmente; ciò significa che un ripristino che riporta il mainframe a un punto precedente all’ultima esecuzione del batch potrebbe lasciare i sistemi distribuiti più aggiornati rispetto al mainframe in termini di attualità dei dati
• Coerenza di cataloghi e metadati – il ripristino di set di dati mainframe senza i corrispondenti aggiornamenti agli archivi di metadati distribuiti – o viceversa – può lasciare le applicazioni in uno stato in cui fanno riferimento a dati che non esistono o sono stati sostituiti
• Impegni RTO e RPO divergenti – i team mainframe e distribuiti operano spesso in base a SLA separati, il che può comportare operazioni di ripristino che ripristinano ciascuna piattaforma in modo indipendente senza coordinare la coerenza puntuale richiesta per le applicazioni che si estendono su entrambe

E non si tratta nemmeno di casi limite. Gli errori di sincronizzazione potrebbero essere una delle cause principali di un ripristino tecnicamente riuscito ma funzionalmente fallito in ambienti in cui i sistemi non mainframe accedono agli stessi dati dei mainframe o dipendono operativamente dai mainframe.

In che modo gli ambienti di backup eterogenei migliorano la resilienza?

Uno degli impulsi principali nell’IT aziendale è la standardizzazione: utilizzare un’unica piattaforma di backup, un unico set di strumenti, un unico modello operativo. Gli ambienti mainframe, d’altra parte, sono proprio il luogo in cui questo approccio potrebbe non essere affatto migliore.

Un ambiente di backup eterogeneo (in cui soluzioni di backup native per mainframe operano insieme a piattaforme di sistemi aperti con punti di integrazione definiti) può migliorare la resilienza in modi che un approccio basato su un unico fornitore non sempre è in grado di eguagliare. Né gli exploit specifici del fornitore né i guasti dei prodotti possono propagarsi a cascata attraverso l’intero patrimonio di backup. Un backup nativo per mainframe utilizza concetti nativi della piattaforma come i file VSAM, i cataloghi z/OS e l’integrità del sysplex che i prodotti per sistemi aperti generalmente non sono in grado di gestire o non gestiscono bene, mentre i prodotti per sistemi aperti gestiscono i componenti distribuiti per cui sono stati progettati.

L’eterogeneità non è sinonimo di frammentazione. Si tratta di una specializzazione intenzionale con un’integrazione nota: non solo la presenza di più strumenti non correlati uno accanto all’altro, ma un’architettura pianificata che utilizza ciò che ogni strumento sa fare meglio.

Come si possono applicare i modelli di backup ibrido e integrato nel cloud ai mainframe?

L’integrazione cloud è passata dall’essere una considerazione marginale a una scelta architettonica mainstream per il backup dei mainframe. Tale cambiamento è guidato principalmente da pressioni economiche, esigenze di flessibilità geografica e dalla maturazione dei livelli di storage cloud, ora progettati per gestire fin dall’inizio la scala dei volumi di dati dei mainframe.

Sarebbe anche corretto affermare che, nella pratica, le opzioni disponibili in questo ambito sono in gran parte incentrate sull’ecosistema di prodotti IBM, data la natura proprietaria delle interfacce di archiviazione z/OS.

Quali sono le opzioni per integrare i backup mainframe con lo storage nel cloud pubblico?

Esistono diversi modi in cui le soluzioni di backup mainframe possono integrarsi con il cloud pubblico. Ciascun approccio presenta caratteristiche particolari e si adatta a diversi tipi di esigenze di ripristino e livelli di volume di dati. Gli approcci più diffusi sono:

• Il cloud come sostituto del nastro – i dati di backup vengono scritti su livelli di archiviazione a oggetti come AWS S3 o Azure Blob, utilizzando interfacce compatibili con il mainframe o appliance gateway che traducono i formati di backup z/OS nelle API di archiviazione cloud
• Il cloud come destinazione di backup secondaria – i processi di backup on-premise vengono replicati nell’archiviazione cloud come copia a valle, fornendo protezione off-site senza sostituire l’infrastruttura di backup primaria in loco
• Librerie nastro virtuali basate sul cloud – soluzioni VTL con backend cloud nativi che presentano un’interfaccia nastro familiare a z/OS mentre scrivono su uno storage a oggetti cloud scalabile
• Architetture di replica ibrida – i dati del mainframe vengono replicati su istanze mainframe ospitate nel cloud o su ambienti compatibili, consentendo un DR basato sul cloud anziché un semplice storage basato sul cloud

Il modello di integrazione scelto determina direttamente quali scenari di ripristino possono essere facilitati nel livello cloud. Le soluzioni di sola archiviazione proteggono dal guasto del sito, ma non accelerano il ripristino, rendendo necessarie risorse di calcolo all’interno del cloud invece che solo dati.

Come può essere utilizzata l’orchestrazione del DR basato su cloud per il ripristino del mainframe?

Il salvataggio delle copie di backup nel cloud risolve il problema della conservazione. Tuttavia, per recuperarle rapidamente è necessaria l’orchestrazione: flussi di lavoro predefiniti che coordinano la serie di azioni che si verificano dal momento in cui viene presa la decisione di eseguire il failover fino a quando il sistema mainframe è effettivamente in esecuzione.

L’orchestrazione del DR basata su cloud per le soluzioni di backup mainframe può comprendere:

• Attivazione automatica del failover – monitoraggio dello stato che rileva il guasto del sito primario e avvia i flussi di lavoro di ripristino senza intervento manuale
• Sequenza di ripristino – runbook predefiniti che eseguono le fasi di IPL, ripristino del catalogo e riavvio delle applicazioni nel corretto ordine di dipendenza
• Provisioning dell’ambiente: avvio automatico delle risorse di elaborazione e archiviazione ospitate nel cloud necessarie per ricevere ed eseguire i carichi di lavoro ripristinati
• Automazione dei test – test di DR programmati e senza interruzioni che convalidano le procedure di ripristino rispetto ai dati di backup attuali senza influire sulla produzione
• Coordinamento del rollback – procedure di failback gestite che riportano i carichi di lavoro al sito primario una volta ripristinato, senza perdita di dati o lacune di coerenza

La maturità delle funzionalità di orchestrazione disponibili varia notevolmente da un fornitore all’altro. Inoltre, non tutte le soluzioni supportano nativamente l’intera gamma di passaggi di ripristino specifici per z/OS.

Quali considerazioni relative alla sicurezza e alle prestazioni sorgono quando si combinano i mainframe con il backup su cloud?

Le implicazioni dell’estensione del backup dei mainframe al cloud presentano una serie di sfumature, trovandosi al crocevia di due paradigmi infrastrutturali estremamente diversi. È meglio esaminare questi compromessi a confronto:

Né la sicurezza né le prestazioni possono essere considerate un aspetto secondario nelle architetture di backup cloud per mainframe, poiché compromettere uno dei due minerebbe immediatamente il valore dell’intera integrazione.

Quali software e strumenti supportano il backup e il ripristino dei mainframe?

Il panorama del software di backup mainframe è relativamente ristretto, ma la sua complessità è pari a quella delle soluzioni di backup distribuite in termini di complessità complessiva.

L’elenco delle soluzioni disponibili spazia da soluzioni native Z/OS profondamente integrate a piattaforme aziendali più ampie con connettori mainframe. I principali attori in questo settore – tra cui IBM DFSMS e DFSMShsm, CA Disk di Broadcom e Backup for z/OS di Rocket Software – sono descritti in dettaglio di seguito, insieme alle considerazioni architetturali che si applicano indipendentemente dalla scelta del prodotto.

La scelta corretta varia notevolmente a seconda dell’ambiente esistente, dei requisiti di ripristino e del modello operativo.

In che modo gli standard aperti e le API (ad es. API IBM, REST) facilitano l’utilizzo degli strumenti di backup?

La natura storicamente chiusa degli strumenti di backup mainframe sta iniziando a evolversi verso modelli di integrazione più aperti. L’esposizione da parte di IBM delle funzioni di gestione z/OS tramite API REST ha creato possibilità per lo sviluppo di varie integrazioni da parte di fornitori di backup o sviluppatori interni (cosa che in precedenza era impossibile senza l’uso di interfacce proprietarie).

L’interoperabilità è il vantaggio pratico in questo caso. Le soluzioni di backup mainframe che supportano (forniscono o utilizzano) API standard troveranno spazio in soluzioni di orchestrazione del backup aziendale più ampie, fornendo informazioni sullo stato agli strumenti di monitoraggio centralizzati, ricevendo modifiche alle politiche da piattaforme di gestione unificate o indirizzando l’archiviazione cloud tramite interfacce standard di archiviazione a oggetti.

La necessità di specialisti del backup mainframe non viene eliminata completamente (quelli con competenze di backup z/OS), ma riduce il grado di separazione tra i backup mainframe e il resto del patrimonio di backup aziendale.

Qual è il ruolo degli strumenti di automazione e orchestrazione nei flussi di lavoro di ripristino?

Le procedure di ripristino manuali sono un ostacolo. Se runbook complessi e articolati in più fasi vengono eseguiti sotto pressione, la probabilità di errore umano aumenta drasticamente, inclusi errori di sequenza, dipendenze mancanti e altri ritardi.

L’automazione riesce a eliminare tutti questi problemi grazie alla sua stessa progettazione. Le aree in cui l’automazione offre il valore più diretto nei flussi di lavoro di backup e ripristino dei mainframe sono:

• Pianificazione dei lavori di backup e gestione delle dipendenze: garantisce che i lavori vengano eseguiti nell’ordine corretto, con le fasi di pre-elaborazione e post-elaborazione appropriate, senza intervento manuale
• Verifica del catalogo: controlli automatizzati che confermano l’integrità del catalogo di backup dopo ogni job, individuando i problemi prima che diventino sorprese durante il ripristino
• Flussi di lavoro di allerta ed escalation: notifica immediata quando i processi di backup falliscono, superano la finestra temporale prevista o producono risultati incoerenti, inoltrata ai team corretti senza monitoraggio manuale
• Esecuzione del runbook di ripristino: esecuzione sequenziale e basata su script delle fasi di ripristino che riduce il carico cognitivo sugli operatori durante eventi ad alto stress e impone il corretto ordine delle dipendenze

Una copertura di automazione più ampia porta a prevedibilità e testabilità durante i processi di ripristino. Un flusso di lavoro di ripristino che è stato eseguito centinaia di volte in modo automatico è significativamente più affidabile di un flusso di lavoro che esiste solo come documento.

Quali prodotti di backup commerciali sono disponibili per z/OS e piattaforme correlate?

Il mercato commerciale delle soluzioni di backup per mainframe è dominato da un ristretto numero di fornitori specializzati i cui prodotti si sono evoluti insieme a z/OS per molti anni. Pertanto, tutte queste soluzioni condividono una caratteristica comune: sono costruite con una comprensione nativa dei costrutti z/OS che le piattaforme di backup generiche non sarebbero in grado di replicare senza compromessi significativi.

Le principali categorie di funzionalità che distinguono i prodotti di backup per mainframe l’uno dall’altro includono:

• Granularità a livello di dataset: la capacità di eseguire il backup, catalogare e ripristinare singoli dataset anziché interi volumi, il che è essenziale per le operazioni pratiche di ripristino quotidiane
• Riconoscimento del sysplex: gestione delle strutture di accoppiamento e dei dataset condivisi in un sysplex parallelo senza lacune di coerenza
• Gestione del catalogo: gestione integrata del catalogo ICF, che è di per sé una dipendenza di ripristino che deve essere gestita con attenzione
• Compressione e deduplicazione: riduzione in linea dei volumi dei dati di backup, che incide direttamente sui costi di archiviazione e sulla durata della finestra di backup

Quando si sceglie una soluzione di backup per mainframe, queste funzionalità devono essere valutate in base al mix di carichi di lavoro e alle esigenze di ripristino dell’ambiente. Alcune delle soluzioni di backup per mainframe commerciali più diffuse includono:

• IBM DFSMS e DFSMShsm – gestione dello storage nativa z/OS di IBM e gestore dello storage gerarchico
• Broadcom ACF2 e CA Disk – strumenti di backup e ripristino a livello di set di dati consolidati da tempo, con profonda integrazione in z/OS e ampia diffusione nelle aziende
• Rocket Backup for z/OS di Rocket Software – backup di set di dati ad alte prestazioni con potenti funzionalità di compressione e gestione del catalogo

Queste soluzioni non sono direttamente intercambiabili: ognuna presenta punti di forza diversi in aree quali il supporto sysplex, l’integrazione cloud e l’automazione operativa, motivo per cui la valutazione delle funzionalità rispetto ai requisiti specifici dell’ambiente è più importante della sola reputazione del fornitore.

Come vengono gestiti la sicurezza, la conformità e la conservazione per i backup mainframe?

Quali opzioni di crittografia e gestione delle chiavi proteggono i dati di backup inattivi e in transito?

La crittografia basata su hardware è presente negli ambienti mainframe da decenni, con la famiglia IBM Crypto Express e la crittografia dei dataset z/OS. Si tratta di un vantaggio consolidato rispetto a molti ambienti distribuiti che dovrebbe essere mantenuto una volta che i dati di backup si trovano al di fuori dell’ecosistema mainframe. La crittografia dei dati di backup mainframe inattivi e in transito deve essere considerata un requisito e non una funzionalità opzionale.

A riposo, la crittografia dei dataset z/OS con AES-256 viene eseguita implicitamente a livello di storage, quindi la crittografia può procedere senza alcuna modifica al software di backup o al codice dell’applicazione. In transito, la trasmissione verso sedi remote o verso il cloud è protetta con la crittografia TLS.

Nella maggior parte dei casi, è nella gestione delle chiavi che la complessità aumenta. La crittografia è forte solo quanto le misure di protezione applicate all’archiviazione delle chiavi. Negli ambienti di backup mainframe, queste chiavi devono essere accessibili durante il ripristino senza diventare una potenziale vulnerabilità.

Il framework ICSF e i moduli di sicurezza hardware di IBM costituiscono la base per la gestione delle chiavi aziendali su z/OS, ma le organizzazioni che intendono estendere i backup al cloud o a destinazioni distribuite dovrebbero assicurarsi di mantenere il controllo sulla custodia delle chiavi (anziché delegare questo compito a un fornitore terzo per impostazione predefinita).

Quali funzionalità di audit e reporting sono necessarie per la verifica della conformità?

La verifica della conformità per il backup mainframe non si esaurisce con l’adozione delle politiche giuste: richiede prove dimostrabili che tali politiche vengano eseguite in modo coerente e che le eccezioni vengano rilevate e risolte. Le funzionalità di audit e reporting che le soluzioni di backup mainframe devono supportare includono:

• Registrazione del completamento dei lavori – registrazioni con data e ora di ogni lavoro di backup, inclusi gli stati di successo, fallimento e completamento parziale, conservate per tutta la durata del periodo di conformità pertinente
• Report sull’integrità del catalogo – verifica periodica che i cataloghi di backup riflettano accuratamente i dati che indicizzano, con risultati documentati disponibili per la revisione di audit
• Audit di accesso e modifica – registrazioni di ogni azione amministrativa che riguarda la configurazione del backup, le impostazioni di conservazione o i dati di backup stessi, inclusa l’identità dell’autore e il timestamp
• Documentazione dei test di ripristino – registrazioni formali dell’esecuzione dei test di DR, dei risultati e di eventuali lacune individuate, che le autorità di regolamentazione si aspettano sempre più spesso di vedere come prova della resilienza operativa
• Cronologia delle eccezioni e degli avvisi – registrazioni documentate di errori di backup, finestre mancate e violazioni delle politiche, insieme alle prove di come ciascuna di esse è stata risolta

Anche la mancanza della funzionalità di audit trail potrebbe costituire un riscontro di non conformità in base a numerosi quadri normativi, pertanto l’infrastruttura di reporting relativa al backup dei mainframe non è una semplice comodità, ma una componente della posizione di conformità.

In che modo le politiche di conservazione dovrebbero soddisfare le esigenze normative e aziendali?

La progettazione delle politiche di conservazione per i backup mainframe si trova al crocevia tra i mandati normativi, i requisiti di ripristino aziendale e la gestione dei costi di archiviazione. Sfortunatamente, questi tre requisiti raramente hanno gli stessi obiettivi: la normativa può richiedere una conservazione di 7 anni, i requisiti di ripristino aziendale sono soddisfatti dopo 90 giorni e i costi di archiviazione richiedono la finestra di conservazione più breve possibile.

Il panorama normativo stabilisce limiti minimi non negoziabili per molti ambienti mainframe:

Le politiche di conservazione dovrebbero essere determinate in base alla classificazione dei dati, non in base al sistema. Un singolo mainframe può ospitare dati soggetti a più politiche di conservazione contemporaneamente, e una politica di conservazione generica che applica il requisito più restrittivo a tutti i set di dati comporta uno spreco di spazio di archiviazione e complica inutilmente la gestione del ciclo di vita.

Come si definisce una roadmap per migliorare la maturità dei processi di backup e di DR del mainframe?

Il miglioramento della maturità del backup mainframe raramente è un progetto singolo: si tratta di un programma di miglioramenti incrementali che mira a raggiungere una posizione di DR realizzabile, verificabile e costantemente controllata. La roadmap che viene organizzata in questo contesto inizia con un’analisi onesta della situazione attuale.

Quali domande di valutazione aiutano a determinare la maturità attuale e le lacune?

Prima di stabilire le priorità dei miglioramenti, le organizzazioni devono avere un quadro chiaro della loro attuale situazione in materia di backup mainframe. Le seguenti domande costituiscono la base di tale valutazione:

• Gli obiettivi di ripristino sono definiti formalmente? Per ogni carico di lavoro mainframe dovrebbero esistere obiettivi RTO e RPO documentati, mappati in base ai livelli di criticità, non ipotizzati o ereditati da documentazione legacy che non è stata rivista di recente.
• Quando è stato condotto l’ultimo test di ripristino completo? Una strategia di backup del mainframe che non è stata testata end-to-end negli ultimi 12 mesi non può essere considerata affidabile: le ipotesi non verificate si accumulano silenziosamente nel tempo. Su z/OS, end-to-end significa includere la sequenza IPL, il ripristino del catalogo ICF e le procedure di riavvio del sottosistema, non solo verificare l’esistenza dei dati di backup.
• I cataloghi di backup sono archiviati indipendentemente dai sistemi che proteggono? La perdita del catalogo durante un evento di ripristino è una delle cause più comuni e prevenibili di fallimento del ripristino. Su z/OS ciò include sia il catalogo master ICF che eventuali cataloghi utente, nonché i set di dati di controllo DFSMShsm – tutti elementi che costituiscono di per sé dipendenze di ripristino.
• I dati di backup sono protetti contro le minacce interne e il ransomware? Le politiche di immutabilità, i controlli di accesso e le procedure di air-gap dovrebbero essere documentati e verificabili, non dati per scontati solo perché sono stati implementati in passato. Su z/OS ciò significa verificare la copertura delle politiche RACF o ACF2 sui set di dati e sui cataloghi di backup in modo specifico, non solo sui dati di produzione.
• Le dipendenze multipiattaforma sono mappate? Ogni sistema distribuito, API o applicazione a valle che dipende dai dati del mainframe dovrebbe essere documentato, con la sua relazione di ripristino rispetto al mainframe definita in modo esplicito.
• L’ambiente di backup soddisfa gli attuali requisiti di conformità? I periodi di conservazione, gli standard di crittografia e le funzionalità di audit trail devono essere verificati rispetto al quadro normativo attuale, non a quello in vigore quando è stata redatta l’ultima versione della politica di backup.

Come si dovrebbero stabilire le priorità dei miglioramenti incrementali (risultati immediati vs. progetti a lungo termine)?

Non tutte le lacune individuate nella valutazione possono essere affrontate contemporaneamente. Un quadro pratico di definizione delle priorità va dalla riduzione immediata del rischio al miglioramento architettonico a lungo termine:

1. Colmare prima le vulnerabilità del catalogo: se i cataloghi di backup non sono protetti in modo indipendente, tale lacuna rappresenta un rischio esistenziale per il ripristino che supera in urgenza tutti gli altri miglioramenti.
2. Stabilire o convalidare gli obiettivi di ripristino: senza obiettivi RTO e RPO documentati, ogni miglioramento successivo manca di uno standard misurabile verso cui tendere.
3. Implementare l’immutabilità e i controlli di accesso: i miglioramenti della resilienza al ransomware hanno un impatto elevato e sono relativamente realizzabili senza grandi cambiamenti architetturali, rendendoli risultati immediati e significativi.
4. Eseguire un test di ripristino completo: prima di investire in nuovi strumenti o architetture, verificare cosa l’ambiente attuale è effettivamente in grado di fornire in condizioni di ripristino reali.
5. Affrontare le lacune di sincronizzazione multipiattaforma: una volta stabilizzata la situazione del backup del mainframe, estendere l’attenzione alle dipendenze distribuite e al coordinamento del ripristino oltre i confini delle piattaforme.
6. Valutare le lacune relative agli strumenti e all’automazione: con un quadro chiaro dei requisiti di ripristino e delle capacità attuali, le decisioni relative agli strumenti possono essere prese sulla base di criteri specifici e convalidati, piuttosto che sulle affermazioni dei fornitori.
7. Puntare alla convalida continua: la verifica automatizzata dei backup, i test di DR programmati e il monitoraggio continuo dei KPI sostituiscono le valutazioni puntuali con una visione costantemente aggiornata della prontezza alla DR.

Quali KPI e metriche dovrebbero guidare la maturità del programma di DR in corso?

Un programma di backup mainframe che non viene misurato non viene gestito. Le seguenti metriche forniscono un quadro pratico per monitorare la maturità del DR nel tempo:

• Tempo di ripristino effettivo rispetto a quello obiettivo – il divario tra il tempo di ripristino testato e l’RTO documentato, misurato durante ogni test di DR e monitorato come andamento nel tempo.
• Punto di ripristino effettivo vs. obiettivo – la finestra di perdita di dati effettiva raggiunta durante i test di ripristino, confrontata con l’RPO documentato per ogni livello di carico di lavoro.
• Tasso di successo dei processi di backup – la percentuale di processi di backup mainframe pianificati completati con successo entro la finestra definita, monitorata settimanalmente e analizzata quando scende al di sotto di una soglia concordata.
• Tempo medio di rilevamento dei guasti di backup – la rapidità con cui vengono identificati i guasti di backup dopo che si sono verificati, che influisce direttamente sul tempo in cui l’ambiente opera con una lacuna non rilevata nella sua protezione.
• Frequenza di verifica dell’integrità del catalogo – con quale frequenza viene verificata l’accuratezza e la completezza dei cataloghi di backup, con i risultati documentati a fini di audit.
• Copertura del coordinamento del ripristino Sysplex – la percentuale di carichi di lavoro di Livello 1 per i quali le dipendenze di ripristino tra sistemi, comprese le strutture di accoppiamento e le relazioni tra set di dati condivisi, sono esplicitamente documentate e testate.
• Frequenza e copertura dei test di DR – il numero di test di DR condotti ogni anno e la percentuale di carichi di lavoro di Livello 1 e Livello 2 inclusi in ciascun ciclo di test.
• Tempo necessario per correggere le lacune identificate – il tempo medio che intercorre tra l’identificazione di una lacuna – tramite test, audit o monitoraggio – e l’attuazione di una correzione convalidata.

Conclusione

Il backup e il ripristino del mainframe non sono un progetto che si risolve una volta per tutte. Il panorama delle minacce si evolve, i requisiti aziendali cambiano, i quadri normativi si inaspriscono e i sistemi che dipendono dai dati del mainframe diventano sempre più interconnessi nel tempo. La strategia di backup del mainframe che era sufficiente tre anni fa probabilmente presenta oggi una serie di lacune, non perché non funzioni più, ma perché l’ambiente circostante è cambiato mentre la strategia è rimasta immutata.

Le organizzazioni che riescono a mantenere una vera resilienza DR affrontano il backup dei mainframe come un programma continuo, non come un progetto una tantum. Obiettivi di ripristino definiti, procedure testate, controlli di sicurezza applicati e politiche di conservazione regolarmente riviste non sono risultati una tantum, ma abitudini operative che determinano se il ripristino è possibile quando conta davvero.

Domande frequenti

I dati di backup del mainframe possono essere utilizzati per supportare iniziative di analisi o data lake?

I dati di backup dei mainframe possono fungere da fonte per iniziative di analisi, ma richiedono un trattamento accurato: i set di dati di backup sono strutturati per il ripristino, non per l’interrogazione, e in genere necessitano di una trasformazione prima di poter essere utilizzati in un contesto di data lake. L’approccio più pratico consiste nel considerare i backup dei mainframe come una fonte di dati secondaria che integra le pipeline di estrazione dati appositamente progettate, anziché sostituirle. Le organizzazioni che tentano di utilizzare direttamente i dati di backup grezzi per l’analisi spesso scoprono che il sovraccarico operativo della conversione del formato e della convalida della coerenza supera il valore dei dati stessi.

Quali sono i rischi di affidarsi esclusivamente alla replica per il disaster recovery?

La replica affronta efficacemente i guasti a livello di sito, ma non fornisce alcuna protezione contro il danneggiamento logico: se dati errati vengono scritti sul sito primario, la replica li propaga al sito secondario quasi in tempo reale. Una strategia di backup del mainframe basata esclusivamente sulla replica non ha alcun punto di ripristino precedente all’evento di corruzione, il che significa che errori logici, crittografia ransomware e bug delle applicazioni che producono dati errati possono rendere entrambi i siti ugualmente inutilizzabili. La replica dovrebbe essere un livello di un’architettura di backup del mainframe più ampia, non l’intera strategia.

In che modo le strategie di backup mainframe dovrebbero adattarsi ai requisiti ESG e di sovranità dei dati?

I requisiti di sovranità dei dati – che impongono che determinati dati rimangano all’interno di specifici confini geografici o giurisdizionali – limitano direttamente le opzioni di backup off-site e su cloud disponibili per gli ambienti mainframe che operano in più regioni. Le soluzioni di backup mainframe devono essere valutate in base ai requisiti di sovranità di ogni giurisdizione in cui opera l’organizzazione, non solo in base alla sede del data center primario. Le considerazioni ESG aggiungono un’ulteriore dimensione, con il consumo energetico dell’infrastruttura di backup – in particolare le grandi librerie a nastro e la replica sempre attiva – che diventa un fattore nella rendicontazione di sostenibilità per le organizzazioni con impegni ESG formali.