Integrazione tra Commvault Complete Backup & Recovery Software e i sistemi Hewlett Packard Enterprise (HPE) StoreOnce

Commvault annuncia la piena integrazione tra Commvault Complete™ Backup & Recovery Software e i sistemi Hewlett Packard Enterprise (HPE) StoreOnce, incluso HPE StoreOnce Catalyst. Questa soluzione permette a Commvault di gestire l’intero ciclo di vita delle attività di data management per i sistemi HPE StoreOnce. L’integrazione tra i sistemi HPE StoreOnce con Catalyst Copy soddisfa le sfide di backup, recovery e compliance, riducendo i requisiti di risorse e rispondendo alla costante crescita dei dati che i clienti devono affrontare.

L’integrazione di Commvault Complete™ Backup & Recovery Software, che l’azienda ritiene sia la soluzione di backup e recovery più complete e ricca di funzionalità del mercato, con i sistemi HPE StoreOnce, ottimizza i costi dello storage, riduce il traffico di rete, offre massima data mobility e semplifica la gestione dei dati. Inoltre, gli utenti possono spostare i dati del backup in maniera nativa, affidabile e conveniente verso cloud pubbliche, private, o ibride. Questa capacità è assicurata da HPE Cloud Bank Storage, funzionalità che sarà supportata da una release software HPE schedulata per novembre.

La nuova soluzione comprende il supporto per la deduplica in modalità low bandwidth (source-side) che riduce i dati ridondanti, minimizza lo spostamento automatico dei dati verso storage più economico a mano a mano che i dati invecchiano in base alle policy definite dall’utente, e comprende il supporto per backup completi e sintetici con Catalyst Clone.

StoreOnce Catalyst può essere facilmente configurato avvalendosi dell’interfaccia utente Commvault in pochi clic. Una volta abilitato, Commvault gestisce i backup e gli spostamenti per i sistemi HPE StoreOnce così come fa per qualunque altro client Commvault. Sulla base del livello di integrazione non sono necessarie altre configurazioni. Aggiornamenti StoreOnce Catalyst future saranno compresi nei periodici service pack Commvault.

L’intelligenza artificiale può semplificare la protezione dei dati

Edwin Passarella, Technical Services Manager, Commvault Italia
Edwin Passarella, Technical Services Manager, Commvault Italia
Intelligenza Artificiale e Machine learning: è raro ormai non vedere citate queste tecnologie in articoli o pubblicità. A volte può essere una trovata promozionale, spesso invece le ragioni sono valide, ad esempio, la promessa di automazione per semplificare le nostre vite attraverso lo svolgimento di attività regolari, ed in grado di adattarsi ai cambiamenti per raggiungere gli obiettivi prefissati.
L’idea del machine learning in sé può evocare immagini di un futuro distopico che ricorda il film Terminator, con una trama che narra di esseri umani che perdono il controllo delle macchine da loro create. Nel mondo reale, il vero potere di tecnologie come questa si realizza quando otteniamo il controllo e possiamo stabilire le attività che desideriamo, in qualità di amministratori di sistema e utenti aziendali. Non soccombere alla loro volontà, perché Intelligenza Artificiale e Machine Learning sono in grado di apprendere e imparare ad adattarsi. In molti conosceranno il proverbio cinese “Dai un pesce a un uomo e lo nutrirai per un giorno. Insegna a un uomo a pescare e lo nutrirai per tutta la vita.”
Allo stesso modo stiamo istruendo le macchine a realizzare operazioni su base regolare, definendo le nostre esigenze di business principali, RPO e RTO da applicare ai differenti dati, migliorando la prontezza di ripristino dell’intero ambiente.
È importante scegliere soluzioni in grado di apprendere e di adattarsi ai cambiamenti tramite la definizione di obiettivi, l’identificazione di anomalie e la semplificazione della governance e dei requisiti di conservazione dei dati.
Abbiamo appena iniziato a capire come queste tecnologie possono facilitare diversi aspetti della nostra vita. Alcune aziende inventeranno nomi bizzarri per definire i loro tentativi di automazione. Riteniamo intelligenza artificiale e machine learning essenziali e molto attesi negli odierni ambienti di dati in rapida crescita e apporteranno un nuovo livello di fiducia nei modelli di protezione dei dati, garantendo una migliore visibilità delle operazioni quotidiane e delle anomalie impreviste in modo tale da rendere le attività più semplici.

Wenceslao Lada Vice President Worldwide Alliances di Commvault

Wenceslao Lada, Vice President Worldwide Alliances, CommvaultCommvault ha nominato Wenceslao Lada Vice President Worldwide Alliances.

Lada, grazie alla sua consolidata esperienza, entra in Commvault con la responsabilità di rafforzare le partnership esistenti e stringere nuove alleanze con cloud provider e aziende tecnologiche leader di settore. Inoltre, grazie alle sue competenze, Lada supporterà lo sviluppo di nuove opportunità di business e l’ampliamento del market share di Commvault e dei suoi partner globali.

Lada ha più di 20 anni di esperienza nello sviluppo e realizzazione di strategie di canale e OEM per aziende leader IT. Prima del suo ingresso in Commvault, è stato Vice President, Worldwide Global Customer Success Sales di Cisco e, in precedenza, Vice President and General Regional manager for Americas and EMEA di Hewlett-Packard.

Lada, che risponde a Taraniuk, sarà responsabile del nuovo team Worldwide Alliances, che unisce le divisioni attuali OEM e Alliances.

Un’unica piattaforma per il backup e recovery riducono il downtime del 55%

Vincenzo Costantino, Director, EMEA South Technical Services, Commvault
Vincenzo Costantino, Director, EMEA South Technical Services, Commvault

Secondo stime di Gartner il costo medio di un downtime parte da una base di 5.600 dollari al minuto. Nonostante questo, molte aziende non hanno ancora definito una strategia di “High Availability” (HA) o Alta Disponibilità.

Quali sono le principali cause di downtime?
I downtime non pianificati sono un rischio spesso aggravato da approcci multi-prodotto e multi-vendor che limitano l’agilità e la disponibilità all’interno dell’architettura di backup e recovery di un’azienda. Implementare un’unica piattaforma completa di gestione dei dati può contrastare il rischio di downtime causato proprio dall’uso di un numero eccessivo di prodotti.
Un’indagine di IDC realizzata nel 2018 ‘Quantifying the Business Value of Commvault Software: Worldwide Customer Survey Analysis’, indica che le aziende che utilizzano un’unica piattaforma per il backup e recovery hanno ridotto il downtime del 55%.
Una singola soluzione può inoltre incrementare la produttività IT e ridurre i costi annuali, garantendo operazioni di backup e recovery più affidabili e veloci. Queste capacità sono in grado di migliorare i risultati di business e di rispondendo alle diverse esigenze, allontanando il rischio di downtime non pianificati.

Come impostare una corretta strategia di High Availability?
Una strategia di HA dovrà tenere in considerazione l’esigenza crescente di protezione dei dati in ambienti IT multi-cloud e ibridi in rapida crescita che richiedono flessibilità e sicurezza per fornire agilità di business. Backup e protezione dei dati sono fondamentali per l’alta disponibilità, insieme alla flessibilità con funzionalità versatili come la deduplica in ambienti cloud e policy di licenza per infrastrutture virtuali.
I clienti aziendali hanno bisogno di flessibilità per garantire alta disponibilità e una riduzione dei rischi all’infrastruttura dati, con la necessità di adattabilità integrata e una vasta gamma di opzioni di cloud storage per soddisfare questi requisiti. Da aggiungere anche le normative di protezione dei dati (ad esempio GDPR) e di diritto all’oblio e funzionalità richieste per la protezione by design, la notifica di violazione entro 72 ore, principi di minimizzazione dei dati, trasferimento e portabilità delle informazioni.
I cyberattacchi stanno diventando una delle principali cause di downtime.

Come inserire la sicurezza informatica in una strategia di HA?
Quando un attacco cyber supera le difese di sicurezza, le tecnologie di rilevazione delle minacce che ogni azienda dovrebbe possedere indicheranno anomalie rispetto ai modelli di comportamento e operativi standard. Le aziende sono responsabili non solo dei propri dati, ma anche di quelli dei clienti e devono garantire processi appropriati di backup e di ripristino su richiesta. Per ottimizzare la sicurezza dei dati in una strategia di HA, le aziende dovrebbero considerare disaster recovery e business continuity, attività monitorate in modo completo che possono offrire anche crittografia dei dati archiviati e di quelli in transito.
Gli attacchi dei ransomware WannaCry, Petya e NotPetya hanno colpito più di 150 paesi nel 2017, le aziende possono adottare un approccio con singola piattaforma per realizzare il backup dei dati in modo semplice, automatico e sicuro, riducendo il rischio di perdita dei dati a seguito di violazioni e garantendo livelli elevati di disponibilità delle informazioni.

Qual è l’impatto del cloud sulla disponibilità delle applicazioni?
Quando si considera l’impatto del cloud sulla disponibilità, è necessario un approccio appropriato, soprattutto per quanto riguarda l’integrazione. L’unione di molteplici applicazioni e soluzioni di disaster recovery in silo spesso crea problemi e può ostacolare l’efficacia dell’intera infrastruttura di dati. Le aziende dovrebbero quindi scegliere una piattaforma che operi con differenti soluzioni cloud e agevoli e semplifichi la disponibilità dei dati nel cloud.
Soluzioni hyperscale e multi-cloud garantiscono benefici significativi nella capacità di adattare i sistemi alle condizioni in evoluzione e rendere i dati disponibili indipendentemente da variabili di tempo e luogo (anche virtuale).
La disponibilità può essere a rischio anche nel caso in cui un cloud service provider subisse interruzioni di attività o di connessione per un lungo periodo. La migrazione al cloud è un’opzione interessante per la sua relativa facilità e accessibilità, ma ci sono difficoltà potenziali da affrontare nel ripristino dei dati e nell’assicurarne la disponibilità.

I risultati della ricerca sottolineano che un terzo delle aziende non ha un sito di disaster recovery. Quali sono i rischi correlati all’High Availability?
Nonostante la consapevolezza dell’importanza dei dati aziendali, oltre il 60% delle imprese non ha implementato un piano di disaster recovery documentato in caso di eventi disastrosi, sia naturali che dolosi.
Tra le best practice da includere in un piano di disaster recovery: ripristino dei dati off-site in una location secondaria, collaborare con partner di fiducia o avere un tema dedicato al DR. È importante che le aziende aggiornino in modo costante il loro piano di DR e effettuino test regolari applicando differenti situazioni.
I piani di disaster recovery richiedono una forte collaborazione tra molte figure, che includono tutte le linee di business. Per una strategia di HA efficace, è fondamentale realizzare test e prove in modo continuo e adattare e far evolvere gli strumenti utilizzati.

Come gli snapshot consentono di migliorare il backup

Roy Child, product specialist di Commvault

I punti di vista su snapshot e backup sono diversi. Alcuni sostengono che gli snapshot non possano avere da soli il ruolo del backup, e abbiano bisogno di integrarsi con il backup per assicurare il ripristino. Molte aziende hanno capito di aver bisogno di snapshot per risolvere le sfide di backup e ripristino dei dati critici, ma senza dotarsi di uno strumento di integrazione degli snapshot all’interno del ciclo di vita dei dati, si finisce per creare nuovi problemi invece di risolverli. In realtà, gli snapshot possono davvero migliorare il backup.

Riservare i server di produzione alla produzione effettiva
Gli snapshot apportano numerosi benefici. Sono in grado di eliminare i carichi di backup dai sistemi di produzione. Si effettuano in pochi secondi, in modo che le applicazioni di produzione principali non debbano sopportare per ore carichi di lavoro significativi. Carichi che possono essere trasferiti su un server proxy separato, che esegue il backup per conto della produzione. È possibile consolidare i backup di più server di produzione attraverso lo stesso proxy per incrementare l’efficienza.

Anche l’offload del backup crea nuove sfide  
È più semplice dirlo che farlo. Utilizzare strumenti separati per snapshot e backup conduce a una possibile disconnessione nell’ambiente di backup che porta con sé gravi implicazioni per la gestione e il ripristino. Se i backup avvengono sul server proxy, lo strumento di backup è a conoscenza solo di quello che succede sul proxy. Il server proxy, e quindi il tool di backup, non sono al corrente di quanto fanno i server di produzione, che conservano file importanti, e nemmeno di database o applicazioni che potrebbero esservi in esecuzione.
Perché questo è importante? Bisogna tenere in considerazione queste differenze. L’ambiente di produzione cambia e cresce, ed è quindi necessario mantenere aggiornati snapshot e backup. Quando si devono ripristinare i dati, si presentano alcune sfide aggiuntive. In primo luogo, bisogna sapere esattamente quali file recuperare per ogni database. È necessaria inoltre la presenza di un amministratore di database che lo ripristini e lo riporti in un determinato punto nel tempo, perché non è possibile utilizzare la funzionalità acquistata nel tool di backup.
Inoltre, per essere certi di effettuare il restore dei file corretti nella posizione giusta, serve conoscere esattamente l’origine di provenienza dei dati, tenendo in considerazione che il tool di backup non ha informazioni sulla produzione. Il monitoraggio diventerà quindi fondamentale all’interno della strategia di ripristino.
È un processo molto rapido. Ogni database, disco, VM, file system, server, sistemi storage e proxy che viene aggiunto allo snap rende la lista più lunga e la ricerca più difficile. Inoltre, è importante ricordare che bisogna aggiornare il monitoraggio dei dati ogni volta che l’ambiente cambia. In caso di ripristino su larga scala, sbloccare tutte le relazioni per realizzare il ripristino potrebbe aggiungere ore al tempo di inattività generale.
Un altro elemento che spesso si considera solo all’ultimo momento è la visibilità, specialmente quando si parla di soluzioni scripted. Lo strumento di backup fornisce report e alert per avvisare quando la situazione non sta funzionando in modo adeguato, ma è altrettanto importante che avvisi quando tutto funziona correttamente. La soluzione di gestione degli snapshot deve fare lo stesso.
Si tratta di problematiche dovute al mancato collegamento tra gli strumenti, indipendentemente dalla buona qualità di snapshot e backup. E sono problematiche che vanno affrontate.

Uno strumento unico per gestire snapshot e backup
Quando lo strumento di backup gestisce anche gli snapshot, tutta questa complessità svanisce. Il tool registra tutte le informazioni proxy, gestisce gli elementi di integrazione – OS, hypervisor, database – per assicurare il ripristino e consentire di recuperare un database sotto forma di database, anche in uno specifico momento nel tempo, senza necessità di un amministratore di database. È possibile standardizzare un processo di recovery per snapshot e backup e ottenere la visibilità operativa necessaria senza duplicare report o dover apprendere nuove capacità.
È importante notare che anche se il tool di backup gestisce gli snapshot, potrebbe comunque avere problemi nel backup se la soluzione non supporta tutte le applicazioni o lo storage. Bisognerà utilizzare script e processi manuali per risolvere ogni gap, con tutti i problemi descritti in precedenza.

Lo scripting non è la risposta
Si tratta di una situazione che ho vissuto in prima persona. Quando lavoravo come ingegnere IT, avevamo un’applicazione che doveva effettuare backup coordinati e coerenti su una coppia di server. I dati erano troppi e troppo complessi per poter eseguire i backup in produzione e restare nei tempi previsti. Avremmo avuto bisogno di snapshot, ma a quei tempi non esistevano soluzioni di gestione degli snapshot per il nostro storage. Ho dovuto fare lo script.
La soluzione scripted lavorava molto come ho descritto. Il backup degli snapshot avveniva attraverso un server proxy, senza consapevolezza dei database SQL o dei server di origine. Il ripristino è sempre stato un grosso problema, perché oltre a controllare le relazioni per essere certi che stessero recuperando i dati, l’amministratore doveva ripristinare il database e i file su entrambi i server nello stesso momento nel tempo.
Abbiamo dovuto lavorare con questo processo per molti anni, ed è stato complicato. Dovevamo aggiornare spesso i file di configurazione quando il team applicativo aggiungeva dischi e in più occasioni qualcuno dimenticava un aggiornamento e interrompeva il backup. Senza considerare migrazioni di server e storage che richiedevano modifiche di configurazione ancora più grandi e fasi di test impegnative. Cambiando soluzioni di backup, abbiamo dovuto rielaborare completamente il processo.
A causa della complessità, abbiamo sempre utilizzato la soluzione solo su due di queste coppie di server, e anche se l’ambiente era contenuto nelle dimensioni, il tempo necessario per la manutenzione e la risoluzione dei problemi del processo era tanto. Onestamente, non ce ne saremmo nemmeno preoccupati se non avessimo potuto trovare le finestre di backup in altro modo.
Se avessi potuto realizzare questo processo con una soluzione performante, non avrei dovuto scrivere script, né gestire file di configurazione, né avere conoscenza SQL e componenti da monitorare. La reportistica e gli alert avrebbero incluso backup e snapshot. Il ripristino sarebbe stato semplice e le migrazioni storage sarebbe state virtualmente un non-evento.
In breve, gli snapshot sarebbero stati così integrati con il backup da non accorgersi neanche della loro presenza, oltre a non appesantire ulteriormente l’ambiente di produzione. E questo livello di integrazione rappresenta il modo in cui gli snapshot migliorano il backup. In questa era di singole soluzioni “abbastanza efficaci”, è facile trascurare i costi nascosti e le sfide che da essi derivano, fino al momento in cui non ci si trova ad affrontarli, di solito nella peggiore occasione possibile.