Principale > La storia di Bacula Systems > Glossario > Piano di ripristino di emergenza SAP

Piano di ripristino di emergenza SAP

Aggiornato 9th Dicembre 2022, Rob Morrison

Poiché SAP costituisce spesso uno dei componenti più importanti del flusso di dati all’interno di un’organizzazione, il piano di ripristino d’emergenza SAP è sempre stato al centro dell’attenzione di tutti gli stakeholder. Esiste una grande varietà di disastri diversi che possono verificarsi all’improvviso e, se non siete pronti, vi costerà molto caro; da danni irreparabili ai vostri dati fino alla perdita completa dell’attività. Quasi ogni minuto di inattività è un disastro per un’azienda, e ogni ora in più può comportare migliaia di dollari – e oltre – di costi aggiuntivi.

Ecco perché le aziende devono essere sempre pronte e in grado di minimizzare il più possibile i possibili tempi di inattività. Ci sono alcuni termini importanti per questo, come RTO e RPO.

RTO è l’acronimo di ‘recovery time objective’. Rappresenta la quantità di tempo in cui può permettersi che i sistemi SAP della sua azienda siano offline. Non dovrebbe essere importante il tipo esatto di disastro che si è verificato: un guasto alla rete, un’interruzione di corrente, un uragano, e chi più ne ha più ne metta – lei vorrà che il suo database SAP o HANA torni operativo entro il periodo di tempo ‘consentito’ – e questo è esattamente il significato di RTO.

Ora, ci sono molti asset e/o servizi diversi che possono essere coinvolti o colpiti da un disastro, e ognuno di essi ha un RTO diverso. Ad esempio, i sistemi bancari o i negozi online ad alta richiesta misurano il loro RTO in secondi effettivi, mentre l’RTO di un’azienda meno rilevante dal punto di vista temporale potrebbe arrivare a diversi giorni. Naturalmente, tra questi esempi ci sono anche molti casi diversi.

sap disaster recovery

 

L’RPO è un obiettivo di punto di recupero e probabilmente sarà anche un fattore importante del suo piano di disaster recovery SAP. L’RPO rappresenta la quantità massima di dati (misurata in termini di età dei dati) che può o non può essere persa in caso di disastro. Fondamentalmente, una sorta di perdita di dati è quasi inevitabile, a meno che non esegua il mirroring dell’intero database in ogni momento. È qui che conta l’RPO. Che cosa è tollerabile per la sua azienda? Proprio come l’RTO, l’RPO varia molto in base alla natura della sua attività. Ad esempio, le transazioni azionarie possono avere un RPO estremamente sensibile, mentre altre aziende possono permettersi un RPO molto più ampio.

Esistono diverse opzioni disponibili per quanto riguarda il disaster recovery di SAP. Alcune sono basate sul cloud e sono relativamente nuove, mentre altre soluzioni sono un po’ più vecchie e utilizzano un approccio diverso. La scelta di piani di disaster recovery SAP, in generale, rende l’intero processo molto più flessibile, in quanto può trovare più facilmente una soluzione che si adatti meglio alle sue specifiche esigenze aziendali, tra cui RPO e RTO accessibili, prezzi convenienti, svantaggi accettabili di un metodo specifico, ecc.

È possibile trovare vari servizi che offrono diversi piani di disaster recovery SAP, ognuno con i propri vantaggi e difetti. Quando sceglie una soluzione SAP DR per sé, ci sono alcune domande che deve tenere a mente:

  • Quali sono i limiti di scalabilità del fornitore?
  • Quali sono gli RTO e gli RPO più rapidi che possono offrire e soddisfano i suoi requisiti?
  • Questo fornitore – e la sua soluzione – sono facili da usare e adattabili alle esigenze uniche della sua azienda?
  • Quanto può spingersi il fornitore in termini di personalizzazione, quando fornisce un servizio di disaster recovery SAP?

In genere ci sono due modi possibili per implementare il piano di disaster recovery di SAP:

  1. Sincrono. Come suggerisce il nome, l’implementazione sincrona di un piano di disaster recovery significa che non ci saranno modifiche al database “principale” fino a quando non riceverà un segnale da un sito di disaster recovery che indica che il database è in fase di aggiornamento.
  2. Asincrono. Questo è diverso, in quanto il database “di riserva” non viene aggiornato ogni volta che si verifica una modifica nel database “principale”. Invece, il database di ripristino d’emergenza viene aggiornato in un secondo momento, molto probabilmente entro un tempo prestabilito. Ciò significa che è possibile che vengano persi più dati in caso di disastro, ma allo stesso tempo riduce l’onere di aggiornare l’intero database ad ogni modifica, per quanto piccola essa sia.

Parlando di piani di ripristino d’emergenza, ne esistono diversi tipi, ognuno con le proprie caratteristiche e i propri difetti:

  • Metodo di recupero dati tradizionale. Il nome stesso implica che si tratta probabilmente del metodo più antico che esista: due server identici, quello “principale” e quello “di riserva”. I registri del database vengono raccolti dal database “principale” e inviati a quello “di riserva”. Questo metodo presenta molti svantaggi, il principale dei quali è la velocità di uptime e il costo complessivo di proprietà. Tuttavia, molte aziende lo utilizzano ancora come opzione principale.
  • Utilizzare i servizi cloud per il backup e il ripristino dei dati. Questa opzione potrebbe anche essere definita ‘economica’, in quanto il costo complessivo dell’utilizzo di Amazon Web Services o simili non è così elevato e può essere gestito dalle aziende più piccole. I servizi cloud sono utilizzati soprattutto dalle aziende che non hanno molte modifiche frequenti all’interno del loro database, e i dati stessi vengono sottoposti a backup di tanto in tanto. Può essere una buona opzione per le imprese in fase di avviamento, ma i problemi di sicurezza generale la rendono una scelta difficile per le aziende più grandi con dati più sensibili.
  • Ripristino da disastri con Bacula. Il modulo Bacula Enterprise SAP implementa l’interfaccia ufficiale SAP BACKINT, che semplifica il backup e il ripristino di SAP, utilizzando gli strumenti tradizionali del database SAP. Il modulo SAP utilizza varie tecniche e strategie per eseguire il backup di SAP e può essere combinato con il plugin Oracle SBT di Bacula Enterprise per consentire il trasferimento diretto dei dati tra Oracle RMAN e Bacula Enterprise. Una volta installato, il modulo SAP esegue backup e ripristini simultaneamente e funziona in modo trasparente in background. L’amministratore del backup può beneficiare delle funzioni di multiplexing dell’edizione di Bacula Enterprise per eseguire backup e ripristini in parallelo.

Per quanto riguarda i fornitori specifici di disaster recovery SAP, può trovare le risposte a queste e altre domande su Bacula Systems leggendo questo whitepaper e questo articolo. C’è anche un modello gratuito di piano di recupero d’emergenza SAP, disponibile qui.

Informazioni sull'autore
Rob Morrison
Rob Morrison è il direttore marketing di Bacula Systems. Ha iniziato la sua carriera nel marketing IT con Silicon Graphics in Svizzera, ottenendo ottimi risultati in vari ruoli di gestione del marketing per quasi 10 anni. Nei 10 anni successivi, Rob ha ricoperto anche diverse posizioni di gestione del marketing in JBoss, Red Hat e Pentaho, assicurando la crescita della quota di mercato di queste note aziende. Si è laureato all'Università di Plymouth e ha conseguito una laurea ad honorem in Digital Media and Communications e ha completato un programma di studi all'estero.