Esistono diversi scenari in cui i dati di un sistema di origine devono essere resi disponibili a un sistema di destinazione per scopi di test o formazione. Questi sistemi di test e formazione devono essere aggiornati regolarmente con i dati del sistema di origine per assicurarsi che i test e la formazione vengano eseguiti con il set di dati corrente. Queste operazioni di refresh del sistema consistono in più attività a livello di infrastruttura, database e applicazioni, che possono richiedere più giorni a seconda del livello di automazione.

I workflow di cloning di SnapCenter possono essere utilizzati per accelerare e automatizzare i task richiesti a livello dell'infrastruttura e del database. Invece di ripristinare un backup dal sistema di origine al sistema di destinazione, SnapCenter utilizza la copia Snapshot di NetApp e la tecnologia NetApp FlexClone, per consentire di eseguire le attività necessarie fino a un database SAP HANA avviato in pochi minuti e non più in ore. Il tempo necessario per il processo di cloning è indipendente dalle dimensioni del database, pertanto è possibile creare anche sistemi molto grandi in un paio di minuti. Il tempo di avvio dipende solo dalle dimensioni del database e dalla connettività tra il server database e il sistema di archiviazione.

Il flusso di lavoro per le operazioni di refresh del sistema è descritto nella sezione ""Aggiornamento del sistema SAP HANA con SnapCenter"."

La corruzione logica può essere causata da errori software, errori umani o sabotaggio. Purtroppo, spesso la corruzione logica non può essere affrontata con soluzioni standard di alta disponibilità e disaster recovery. Di conseguenza, a seconda del livello, dell'applicazione, del file system o dello storage in cui si è verificato il danneggiamento logico, i requisiti minimi di downtime e di perdita massima dei dati possono talvolta non essere soddisfatti.

Il caso peggiore è la corruzione logica in un'applicazione SAP. Le applicazioni SAP spesso operano in un ambiente in cui diverse applicazioni comunicano tra loro e scambiano dati. Pertanto, il ripristino e il ripristino di un sistema SAP in cui si è verificato un danneggiamento logico non è l'approccio consigliato. Il ripristino del sistema a un punto temporale prima che si verificasse il danneggiamento comporta la perdita di dati. Inoltre, il panorama SAP non sarebbe più sincronizzato e richiederebbe un'ulteriore post-elaborazione.

Invece di ripristinare il sistema SAP, l'approccio migliore consiste nel cercare di correggere l'errore logico all'interno del sistema analizzando il problema in un sistema di riparazione separato. L'analisi della causa principale richiede il coinvolgimento del processo di business e del proprietario dell'applicazione. Per questo scenario, si crea un sistema di riparazione (un clone del sistema di produzione) basato sui dati memorizzati prima che si verificasse il danneggiamento logico. All'interno del sistema di riparazione, i dati richiesti possono essere esportati e importati nel sistema di produzione. Con questo approccio, non è necessario arrestare il sistema di produzione e, nel migliore dei casi, non vengono persi dati o solo una piccola parte di dati.

Quando si configura il sistema di riparazione, la flessibilità e l'agilità sono fondamentali. Quando si utilizzano i backup Snapshot basati su storage NetApp, sono disponibili più immagini di database coerenti per creare un clone del sistema di produzione utilizzando la tecnologia FlexClone di NetApp. I volumi FlexClone possono essere creati in pochi secondi anziché in più ore se per configurare il sistema di riparazione viene utilizzato un ripristino reindirizzato da un backup basato su file.

Il flusso di lavoro per la creazione del sistema di riparazione è descritto nella sezione ""Clone del sistema SAP con SnapCenter"."

Una strategia di disaster recovery efficace richiede il test del flusso di lavoro richiesto. I test dimostrano se la strategia funziona e se la documentazione interna è sufficiente. Consente inoltre agli amministratori di addestrare le procedure richieste.

La replica dello storage con SnapMirror consente di eseguire test di disaster recovery senza mettere a rischio RTO e RPO. I test di disaster recovery possono essere eseguiti senza interrompere la replica dei dati.

I test di disaster recovery per SnapMirror asincrono e sincrono utilizzano i backup Snapshot e i volumi FlexClone alla destinazione del disaster recovery.

Nei rapporti tecnici è disponibile una descrizione dettagliata

"TR-4646: Disaster recovery SAP HANA con replica storage (netapp.com)"

"TR-4891: Disaster recovery SAP HANA con Azure NetApp Files"