Domande frequenti - Backup di database SAP HANA in VM di Azure

È possibile pianificare il backup completo e più backup su richiesta in un giorno.

Attualmente, i processi di backup riusciti non generano avvisi. Gli avvisi vengono generati solo per i processi di backup che hanno esito negativo. Informazioni su come usare il portale di Azure per visualizzare gli avvisi di backup.

È possibile controllare lo stato dei backup (pianificati/su richiesta) da una delle posizioni seguenti:

1. Processi di backup: Backup di Azure mostra tutti i processi attivati manualmente nella sezione Processi di backup nella portale di Azure.
   
   I processi visualizzati nella portale di Azure includono l'individuazione e la registrazione delle operazioni di database e le operazioni di backup e ripristino. I processi pianificati, inclusi i backup del log, non sono illustrati in questa sezione. I backup attivati manualmente dai client nativi SAP HANA (Studio/Cockpit/DBA Cockpit) non vengono visualizzati qui.

   

   

2. Avvisi di backup: gli avvisi consentono di monitorare i backup dei database SAP HANA. Questi consentono di concentrarsi sugli eventi necessari, eliminando così lo sforzo di controllare frequentemente una moltitudine di eventi generati da un backup. Per altri dettagli, vedere Visualizzare gli avvisi di backup.

3. Report di backup: i report sono un altro modo per visualizzare lo stato dei processi di backup. I report saranno i seguenti:

   

   

   Informazioni su come configurare Backup di Azure report.

4. Client nativi SAP HANA: se si è un cliente SAP HANA, è anche possibile usare HANA Studio, uno dei client HANA più comuni. In questo client passare a Console di backup -> Catalogo di backup per visualizzare lo stato del backup.

   

Il menu Processo di backup mostrerà solo i processi di backup su richiesta che sono in corso, hanno avuto esito positivo o negativo. Per i processi pianificati, usare Monitoraggio di Azure.

Backup di Azure non imposta un periodo di conservazione esplicito nei backup completi di correzione automatica. Questo backup viene conservato fino al momento in cui si conservano i backup differenziali o incrementali dipendenti e i backup del log. Dopo aver eliminato l'ultimo backup dipendente in questo backup di correzione automatica, viene eliminato anche il backup di correzione automatica.

Sì, un backup completo e un backup del log possono essere eseguiti contemporaneamente. Questa istanza si verifica in uno dei modi seguenti:

• Il backup completo è in corso e viene attivato un backup del log: il backup del log deve avere esito positivo indipendentemente da un backup completo in corso. A meno che il backup completo attivato non sia stato un aggiornamento completo per gestire qualsiasi interruzione di catena LSN.
• Il backup del log è in corso e viene attivato un backup completo: entrambi i backup devono essere eseguiti contemporaneamente e con esito positivo.

No, questo non è attualmente supportato.

Se un database viene eliminato da un'istanza SAP HANA, l'esecuzione dei backup del database viene comunque tentata. Ciò implica che il database eliminato inizia a essere visualizzato come non integro in Elementi di backup e viene ancora protetto. Il modo corretto per interrompere la protezione di questo database consiste nell'eseguire Stop Backup with delete data (Interrompi backup con eliminazione dati) per il database.

Un database rinominato viene considerato come nuovo database. Di conseguenza, il servizio considererà questa situazione come se il database non fosse stato trovato e non riuscirà i backup. Il database rinominato verrà visualizzato come nuovo database e dovrà essere configurato per la protezione.

Vedere l'esercitazione per una guida dettagliata per iniziare a usare Backup di Azure per i database SAP HANA. È anche possibile usare l'interfaccia della riga di comando per configurare e gestire i backup.

Vedere i prerequisiti per l'uso di Backup di Azure con SAP HANA.

Vedere questa sezione della Guida alla risoluzione dei problemi.

Fare riferimento a questa sezione nella guida alla risoluzione dei problemi.

Attualmente non è possibile configurare la soluzione su un INDIRIZZO IP virtuale o un proxy. Per eseguire la soluzione è necessaria una macchina virtuale.

È possibile attivare un backup su richiesta usando client nativi SAP HANA nel file system locale anziché backint. Altre informazioni su come gestire le operazioni usando client nativi SAP.

È possibile eliminare il catalogo HANA usando i metodi consigliati di SAP, ad esempio istruzioni BACKUP CATALOG DELETE o HANA Studio/Cockpit. Altre informazioni su come gestire le operazioni usando client nativi SAP.

Attualmente, Backup di Azure non ha la possibilità di comprendere la configurazione di un modulo di protezione hardware. Ciò significa che i nodi primari e secondari del modulo di protezione hardware verranno considerati come due singole macchine virtuali non correlate. È prima necessario configurare il backup nel nodo primario. Quando si verifica un failover, è necessario configurare il backup nel nodo secondario (che ora diventa il nodo primario). Non è presente alcun failover automatico del backup nell'altro nodo.

Per eseguire il backup dei dati dal nodo attivo (primario) in qualsiasi momento specifico, è possibile passare la protezione al nodo secondario che ora è diventato primario dopo il failover.

Per eseguire questa protezione switch, seguire questa procedura:

• Arrestare la protezione (con conservare i dati) nel database primario
• Eseguire lo script di pre-registrazione nel nodo secondario
• Individuare i database nel nodo secondario e configurare i backup su di essi

Questi passaggi devono essere eseguiti manualmente dopo ogni failover. È possibile eseguire questi passaggi tramite la riga di comando/HTTP REST oltre alla portale di Azure. Per automatizzare questi passaggi, è possibile usare un runbook di Azure.

Ecco un esempio dettagliato di come deve essere eseguita la protezione del commutatore:

In questo esempio sono presenti due nodi: Nodo 1 (primario) e Nodo 2 (secondario) nella configurazione HSR. I backup vengono configurati nel nodo 1. Come accennato in precedenza, non tentare ancora di configurare i backup nel nodo 2.

Quando si verifica il primo failover, il nodo 2 diventa primario. Con questi presupposti,

1. Arrestare la protezione del nodo 1 (primario precedente) con l'opzione mantieni i dati.
2. Eseguire lo script di pre-registrazione nel nodo 2 (che è ora il database primario).
3. Individuare i database nel nodo 2, assegnare i criteri di backup e configurare i backup.

Viene quindi attivato un primo backup completo nel nodo 2 e dopo il completamento, vengono avviati i backup del log.

Quando si verifica il failover successivo, il nodo 1 diventa di nuovo primario e il nodo 2 diventa secondario. Ripetere ora il processo:

1. Arrestare la protezione del nodo 2 con l'opzione di conservazione dei dati.
2. Eseguire lo script di pre-registrazione nel nodo 1 (che è diventato di nuovo primario)
3. Riprendere quindi il backup nel nodo 1 con i criteri necessari , perché i backup sono stati arrestati in precedenza nel nodo 1.

Il backup completo verrà quindi attivato di nuovo nel nodo 1 e dopo il completamento, i backup del log vengono avviati.

1. Per la replica di sistema HANA (HSR), il nodo secondario non accetta alcuna connessione. Dopo aver configurato il backup, il servizio Backup di Azure esegue periodicamente il ping e non riesce. In alcuni casi, questi tentativi non riusciti riflettono sul nodo primario. Dopo più errori, l'utente viene bloccato e il nodo primario inizia a non riuscire con ODBC Connessione ionError.
   
   È stato osservato che tutti gli utenti non riscontrano questo problema. È consigliabile esaminare la causa del blocco degli utenti nel nodo primario quando la connessione utente non riesce nel nodo secondario.

2. Dopo aver eseguito lo script di pre-registrazione, le informazioni utente vengono aggiornate con la nuova password nel nodo primario. Verrà quindi ristabilita la connessione per tentare il backup. Tuttavia, potrebbe verificarsi di nuovo lo stesso scenario.

3. Inoltre, i backup (backup completi) che hanno esito negativo nel nodo secondario creano avvisi.

Per evitare i problemi precedenti, è consigliabile arrestare la protezione per un nodo dopo che diventa secondaria (in modo che le connessioni non vengano tentate e l'utente non sia bloccato) e riprendere la protezione su di essa, una volta che diventa primaria. Se non si riscontra questa situazione di blocco nelle configurazioni HSR e si ha familiarità con gli avvisi generati, è possibile configurare i backup in entrambi i nodi in modo che il servizio gestisca il take-over e il failback.

Fare riferimento alle prestazioni di velocità effettiva di backup e ripristino fornite Backup di Azure per i carichi di lavoro HANA.

Per configurare il sistema HANA per sfruttare le prestazioni migliorate, usare le risorse seguenti:

• Selezionare un tipo di disco per le macchine virtuali IaaS di Azure - Dischi gestiti
• Livelli di prestazioni per Managed Disks di Azure
• Serie M
• Configurazioni dell'archiviazione di macchine virtuali di Azure in SAP HANA

Attualmente, Backup di Azure per SAP HANA accetta 1 come valore della proprietà parallel_backup_using_backint. Tuttavia, Backup di Azure suddivide il singolo flusso in più flussi per ottenere prestazioni migliori.

Attualmente sono supportati solo i backup basati su Backint per HSR. Gli snapshot non sono ancora.

È necessario eseguire il nuovo rilevamento dell'istanza nel server contrassegnato come "Non pronto" per aggiornarne lo stato.

È possibile eseguire un massimo di 10 ripristini per ogni istanza o sistema HANA in un giorno. Si noti che se un ripristino viene annullato o ha esito negativo, viene considerato anche come un tentativo di ripristino.

Verificare che siano soddisfatti tutti i prerequisiti per il ripristino nell'istanza SAP HANA di destinazione. Per altre informazioni, vedere Prerequisiti - Ripristinare database SAP HANA in VM di Azure.

Assicurarsi che l'opzione Forza sovrascrittura sia selezionata durante il ripristino.

Per informazioni sui tipi di ripristino attualmente supportati, vedere la nota SAP HANA 1642148.

Sì, è possibile usare i backup di streaming attivati in un database HANA in esecuzione in SLES per ripristinarlo in un sistema RHEL HANA e viceversa. Ovvero, il ripristino tra sistemi operativi è possibile usando i backup di streaming. Tuttavia, è necessario assicurarsi che il sistema HANA in cui si vuole eseguire il ripristino e il sistema HANA usato per il ripristino siano entrambi compatibili per il ripristino in base a SAP. Fare riferimento alla Nota SAP HANA 1642148 per vedere quali tipi di ripristino sono compatibili.

Sì, è possibile scaricare i file parzialmente come documentato qui.

Sì, è necessario disabilitare la replica di sistema HANA (HSR) nel sistema di destinazione e quindi eseguire il ripristino. Non è possibile ripristinare un sistema abilitato per HSR, in base a SAP.

Prima di creare un criterio, è necessario essere chiari sui requisiti di RPO e RTO e sulle implicazioni relative ai costi.

RPO (Obiettivo punto di ripristino) indica la quantità di perdita di dati accettabile per l'utente/cliente. Ciò è determinato dalla frequenza di backup del log. I backup del log più frequenti indicano un RPO inferiore e il valore minimo supportato dal servizio Backup di Azure è di 15 minuti. Pertanto, la frequenza di backup del log può essere di 15 minuti o superiore.

RTO (Obiettivo tempo di ripristino) indica la velocità con cui i dati devono essere ripristinati nell'ultimo punto nel tempo disponibile dopo uno scenario di perdita di dati. Ciò dipende dalla strategia di ripristino usata da HANA, che in genere dipende dal numero di file necessari per il ripristino. Ciò comporta implicazioni anche sui costi e la tabella seguente dovrebbe essere utile per comprendere tutti gli scenari e le relative implicazioni.

È quindi possibile selezionare la variante dei criteri in base agli obiettivi RPO e RTO e alle considerazioni sui costi.

Quando si determina l'impatto del passaggio dei criteri di un elemento di backup dal criterio 1 (P1) al criterio 2 (P2) o alla modifica dei criteri 1 (P1) è necessario tenere presente alcuni principi.

• Tutte le modifiche vengono applicate retroattivamente. I criteri di backup più recenti vengono applicati anche ai punti di ripristino eseguiti in precedenza. Si supponga, ad esempio, che la conservazione completa giornaliera sia di 30 giorni e che siano stati eseguiti 10 punti di ripristino in base ai criteri attualmente attivi. Se la conservazione giornaliera completa viene modificata in 10 giorni, anche l'ora di scadenza del punto precedente viene ricalcolata come ora di inizio + 10 giorni ed eliminata se sono scadute.
• L'ambito della modifica include anche il giorno del backup, il tipo di backup insieme alla conservazione. Ad esempio: se un criterio viene modificato da giornaliero pieno a settimanale pieno domenicale, tutti gli interi precedenti che non sono domenicali verranno contrassegnati per l'eliminazione.
• Un elemento padre non viene eliminato fino a quando l'elemento figlio è attivo o non scaduto. Ogni tipo di backup ha una scadenza in base ai criteri attualmente attivi. Tuttavia, un tipo di backup completo è considerato padre per i successivi "differenziali", "incrementali" e "logs". Un "differenziale" e un "log" non sono genitori di altri. Un elemento "incrementale" può essere un elemento padre del successivo 'incrementale'. Anche se un 'padre' è contrassegnato per l'eliminazione, non viene effettivamente eliminato se i 'differenziali' figlio o 'logs' non sono scaduti. Ad esempio, se un criterio viene modificato da giornaliero completo a settimanale pieno domenicale, tutti gli interi precedenti che non sono domenicali verranno contrassegnati per l'eliminazione. Ma non vengono effettivamente eliminati fino alla scadenza dei log acquisiti ogni giorno prima. In altre parole, vengono mantenuti in base alla durata del log più recente. Una volta scaduti i log, verranno eliminati sia i log che questi completi.

Con questi principi, è possibile leggere la tabella seguente per comprendere le implicazioni di una modifica dei criteri.

È possibile gestire lo spazio nella cartella radice usando una delle opzioni seguenti:

• Creare una propria LV per /opt/msawb.
• Creare un collegamento/simbolico a un altro percorso/cartella nello stesso disco o in un altro disco diverso.
• Aumentare lo spazio nella partizione radice.

Passaggi successivi

• Informazioni su come eseguire il backup di database SAP HANA in esecuzione in VM di Azure.
• Informazioni su come risolvere i problemi relativi al backup del database SAP HANA.